«

Am 29.08.2012 21:09, schrieb Leigh Johnston:
> On 29/08/2012 19:49, Jens Gustedt wrote:
>> Am 29.08.2012 20:16, schrieb Leigh Johnston:
>>> this has not changed from C to C++. The lack of
>>> implicit conversion *from* void* does not change the utility of void*.
>>
>> For C programmers it does make "void*" useless.
>
> So malloc is useless?

not in C, where implicit conversion from "void*" works without
problems

or where you refering to C++? using malloc? doesn't that give you
objects for which the constructor isn't called

>> Do you often see a "void*" in a veritable C++ interface, I mean in one
>> that could not be defined with 'extern "C"' and then entirely
>> implemented in C?
>>
>> (and I don't mean it to be provocative, I really want to know)
>
> Use void* when you need an untyped pointer; such needs exist in both C
> and C++.

you don't answer my question, still no example for a real use case in
C++, could you be more concrete?

Jens

Am 29.08.2012 22:43, schrieb Leigh Johnston:
> On 29/08/2012 21:33, Jens Gustedt wrote:
>> Am 29.08.2012 21:09, schrieb Leigh Johnston:
>>> On 29/08/2012 19:49, Jens Gustedt wrote:
>>>> Am 29.08.2012 20:16, schrieb Leigh Johnston:
>>>>> this has not changed from C to C++. The lack of
>>>>> implicit conversion *from* void* does not change the utility of void*.
>>>>
>>>> For C programmers it does make "void*" useless.
>>>
>>> So malloc is useless?
>>
>> not in C, where implicit conversion from "void*" works without
>> problems
>
> Ergo void* is not useless in C.

Where did you read that? I didn't say that. I am just, almost
desperately seeking someone who wants to present me with a real use
case in C++.

It has a lot of good use cases in C. It would lose most of its use in
C, if it wouldn't implicitly convert to any other pointer to object
type.

>> or where you refering to C++? using malloc? doesn't that give you
>> objects for which the constructor isn't called
>
> I never use malloc in a C++ program.

see

>> you don't answer my question, still no example for a real use case in
>> C++, could you be more concrete?
>
> Example: a pointer to an object associated with in an item in a GUI list
> box widget. In the GUI library I am currently creating the list box
> widget is actually a template however the item data type defaults to
> void* as both a convenience and a way to reduce template bloat; however
> lots of GUI libraries solely use void* for such things (e.g. Microsoft
> Win32 API).

Then they are no good C++. These things can be done in C++ without any
loss of performance and with much more type safety by using templates,
inheritance, all that machinery.

So you gave me an example where "void*" encourages bad design, is
that?

My claim would be that *if* you want to play such "dirty tricks"
create a proper interface and then program the beast itself in C.

> Another example: an object pointer passed to /pthread_create/.

That doesn't count, pthread_create (or better the new and shiny
thrd_create) are C interfaces. They are designed as such. That is not
a proper use case for C++.

Jens

On 2012-08-29 16:23, Jens Gustedt wrote:
> That doesn't count, pthread_create (or better the new and shiny
> thrd_create) are C interfaces. They are designed as such. That is not
> a proper use case for C++.

Ok, how should I pass data through pthread_create in C++ if you won't
allow me to use void*?

This discussion seems to be pointless when we give examples of use cases
for void* in C++ and you respond with "that doesn't count." Perhaps you
could better explain your criteria for what a valid use might be?

Jens Gustedt <> writes:
[...]
> No, this is not an "unwritten rule" for C. C99 originally had a
> wording that could be interpreted as you state. A corrigendum has made
> it clear that it is not intended. Type-punning in C works as long as
> the value that you are reading is valid for the type through which you
> are doing so.
>
> A footnote in the C standard clarifies that:
>
> 95) If the member used to read the contents of a union object is not
> the same as the member last used to store a value in the object, the
> appropriate part of the object representation of the value is
> reinterpreted as an object representation in the new type as described
> in 6.2.6 (a process sometimes called ‘‘type punning’’). This might be
> a trap representation.

Yes. That footnote was added by Technical Corrigendum 3. It appears
in N1256 (though oddly without a change bar), and of course in C11
(or at least N1570).

[...]

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 30/08/2012 00:21, Leigh Johnston wrote:
> On 29/08/2012 22:23, Jens Gustedt wrote:
>> So you gave me an example where "void*" encourages bad design, is
>> that?
>>
>> My claim would be that *if* you want to play such "dirty tricks"
>> create a proper interface and then program the beast itself in C.
>
> Nonsense; you must have skipped where I used the words "template bloat";
> even Stroustrup advocates this method (see TC++PL 13.5 Specialization).

That is a valid use of void*, although some modern compilers are smart
enough to avoid code bloat without that kind of help.

James Kuyper <> writes:
> On 08/29/2012 02:16 PM, Leigh Johnston wrote:
> ...
>> ... The lack of
>> implicit conversion *from* void* does not change the utility of void*.
>
> In C, implicit conversion to and from void* is the only feature that
> void* has that justifies using it instead unsigned char*. In C++, half
> of those implicit conversions are missing, and no compensating advantage
> has been added to void*. How could it NOT change the utility?

Another feature of void* is that it prevents you from dereferencing
it or performing pointer arithmetic on it. (Unless you're using
gcc without one of the "-std=..." or "-ansi" options.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 2012-08-29, David Brown <> wrote:

> x = f;
> y = * (reinterpret_cast <unsigned int*> &x);

My C++ casting-fu is weak, but I would have thought

y = reinterpret_cast<unsigned int>(f)

would do the job, because reinterpret_cast is explicitly about
preserving the bit pattern anyway, there is no need to play around with
memory addresses. Of course the C style cast (unsigned int)f is totally
different.

On 2012-08-29 23:44, Adrian Ratnapala wrote:
> On 2012-08-29, David Brown <> wrote:
>
>> x = f;
>> y = * (reinterpret_cast <unsigned int*> &x);
>
> My C++ casting-fu is weak, but I would have thought
>
> y = reinterpret_cast<unsigned int>(f)
>
> would do the job, because reinterpret_cast is explicitly about
> preserving the bit pattern anyway, there is no need to play around with
> memory addresses. Of course the C style cast (unsigned int)f is totally
> different.
>

Casting from floating point to integral type is not within the purview
of reinterpret_cast. From C++11 5.2.10, the possible conversions are
* pointer to integral
* integral to pointer
* function pointer to different function pointer
* object pointer to different object pointer
* function pointer to object pointer (and vice versa) with
implementation-defined semantics
* pointer to member-function to different pointer to member-function
* pointer to data member to different pointer to data member
* reference to different reference where the pointer conversion is
defined (i.e., reinterpret_cast<T&>(u) is defined to be the same as
*reinterpret_cast<T*>(&u)) [footnote actually refers to this as type
punning]

The type pun from the OP is then simply:

unsigned int foo(float f) {
return reinterpret_cast<unsigned int&>(f);
}

or - since I'm a C++ programmer and I like to overcomplicate things:

template <typename Target, typename Source>
Target& pun_as(Source& s) {
return reinterpret_cast<Target&>(s);
}

so I can simply write

pun_as<unsigned int>(some_float) = 21369U;

Am 30.08.2012 00:21, schrieb Leigh Johnston:
> On 29/08/2012 22:23, Jens Gustedt wrote:
>> Am 29.08.2012 22:43, schrieb Leigh Johnston:
>>> On 29/08/2012 21:33, Jens Gustedt wrote:
>>>> Am 29.08.2012 21:09, schrieb Leigh Johnston:
>>>>> On 29/08/2012 19:49, Jens Gustedt wrote:
>>>>>> Am 29.08.2012 20:16, schrieb Leigh Johnston:
>>>>>>> this has not changed from C to C++. The lack of
>>>>>>> implicit conversion *from* void* does not change the utility of
>>>>>>> void*.
>>>>>>
>>>>>> For C programmers it does make "void*" useless.
>>>>>
>>>>> So malloc is useless?
>>>>
>>>> not in C, where implicit conversion from "void*" works without
>>>> problems
>>>
>>> Ergo void* is not useless in C.
>>
>> Where did you read that? I didn't say that. I am just, almost
>> desperately seeking someone who wants to present me with a real use
>> case in C++.
>
> You said "For C programmers it does make "void*" useless.". malloc uses
> void* and malloc is used by C programmers ergo void* is not useless to C
> programmers.
>
>>
>> It has a lot of good use cases in C. It would lose most of its use in
>> C, if it wouldn't implicitly convert to any other pointer to object
>> type.
>
> Correct; perhaps this is what you meant.

Yes, this is what I said.

>>
>>>> or where you refering to C++? using malloc? doesn't that give you
>>>> objects for which the constructor isn't called
>>>
>>> I never use malloc in a C++ program.
>>
>> see
>
> See what? I don't use malloc because new is superior and idiomatic.

Sure. So you don't need to operate on "void*" in C++.

>>
>>>> you don't answer my question, still no example for a real use case in
>>>> C++, could you be more concrete?
>>>
>>> Example: a pointer to an object associated with in an item in a GUI list
>>> box widget. In the GUI library I am currently creating the list box
>>> widget is actually a template however the item data type defaults to
>>> void* as both a convenience and a way to reduce template bloat; however
>>> lots of GUI libraries solely use void* for such things (e.g. Microsoft
>>> Win32 API).
>>
>> Then they are no good C++. These things can be done in C++ without any
>> loss of performance and with much more type safety by using templates,
>> inheritance, all that machinery.
>>
>> So you gave me an example where "void*" encourages bad design, is
>> that?
>>
>> My claim would be that *if* you want to play such "dirty tricks"
>> create a proper interface and then program the beast itself in C.
>
> Nonsense; you must have skipped where I used the words "template bloat";
> even Stroustrup advocates this method (see TC++PL 13.5 Specialization).

so if you have Stroustrup's blessing, bad design is ok?

>>> Another example: an object pointer passed to /pthread_create/.
>>
>> That doesn't count, pthread_create (or better the new and shiny
>> thrd_create) are C interfaces. They are designed as such. That is not
>> a proper use case for C++.
>
> Of course it is a proper use case for C++; /pthread_create/ is callable
> from C++.

You seem to have extreme difficulties or lack of willingless to read
what I say.

I said that "void*" is there for interface compatibility with C. So
sure, you might call a C function that has a "void*" parameter. This
is using "void*" as a data sink, you should (almost) never be tempted
to convert it back.

So again give me a proper use case in C++ that isn't just for calling
a C interface.

Jens

Am 30.08.2012 00:21, schrieb Casey Carter:
> On 2012-08-29 16:23, Jens Gustedt wrote:
>> That doesn't count, pthread_create (or better the new and shiny
>> thrd_create) are C interfaces. They are designed as such. That is not
>> a proper use case for C++.
>
> Ok, how should I pass data through pthread_create in C++ if you won't
> allow me to use void*?

This is not what I said and what the discussion was about. The
starting point was to seek proper use cases of "void*" for C++ that
are not just interfacing to C. Sure that you should be able to call C
functions, so you need "void*" there. Please give me *other* valid use
cases.

For the moment I only have been given

- calling C interfaces
- cases where "template bloat" (not my wording) made template
solutions impractical

Jens