dynamically allocate array variable of type LPWSTR

[blargg]

Re: dynamically allocate array variable of type LPWSTR

In article <ln63n5xo05.fsf @nuthaus.mib.or g>, Keith Thompson
<kst-u@mib.orgwrote:

blargg.h4g@gish puppy.com (blargg) writes:
[...]

And while we're on the topic, using a cast is actually a GOOD idea if one
is naming the type in sizeof, since it will catch the error of the
destination type being different than you expect:

long* p = malloc( n * sizeof (int) ); // oops, but no error
long* p = (int*) malloc( n * sizeof (int) ); // compiler catches it

>
long *p = malloc(n * sizeof *p); // no error for the compiler to catch

You snipped the context. This is going in circles now :)

My point was that if the expression being assigned to is more unweildy
than the type name itself, one might choose to use sizeof(type) rather
than sizeof *expr_being_ass igned_to. In that case, casting the result of
malloc to type* ensures that the type being assigned to is compatible with
the type you're allocating for. Thus, if you had

foo [i]->bar->baz [j]->boo [k]->blarg =
malloc( n * sizeof *foo [i]->bar->baz [j]->boo [k]->blarg );

you might prefer to just name the type of blarg, let's say int* here

foo [i]->bar->baz [j]->boo [k]->blarg = malloc( n * sizeof (int) );

but if it really was long* , you'd have an undiagnosed error. But if you
also cast the result

foo [i]->bar->baz [j]->boo [k]->blarg = (int*) malloc( n * sizeof (int) );

you'd get a compile error if it wasn't an int*. Yes, you could mistakenly
cast it to a long* and use sizeof(int), introducing an error anyway, but
the lesser distance between the inconsistencies is such that it can be
easier to track down. It's only a few characters, while the distance
between a mismatch in the second example that lacks the cast might be
hundreds of lines, or span files.

[Chris Dollin]

Re: dynamically allocate array variable of type LPWSTR

blargg wrote:

In article <ln63n5xo05.fsf @nuthaus.mib.or g>, Keith Thompson
<kst-u@mib.orgwrote:
>

>blargg.h4g@gish puppy.com (blargg) writes:
>[...]

And while we're on the topic, using a cast is actually a GOOD idea if one
is naming the type in sizeof, since it will catch the error of the
destination type being different than you expect:
>
long* p = malloc( n * sizeof (int) ); // oops, but no error
long* p = (int*) malloc( n * sizeof (int) ); // compiler catches it

>>
>long *p = malloc(n * sizeof *p); // no error for the compiler to catch

>
You snipped the context. This is going in circles now :)
>
My point was that if the expression being assigned to is more unweildy
than the type name itself, one might choose

.... to fix the unweildy expression.

For what it's worth [1], I've never had an "unweildy" expression as the
target of a mallocation, probably because most of my mallocations end up
in create-me-this-heap-object functions.

[1] Auction!

--
'Don't be afraid: /Electra City/
there will be minimal destruction.' - Panic Room

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

[vippstar@gmail.com]

Re: dynamically allocate array variable of type LPWSTR

On Nov 3, 1:17 pm, blargg....@gish puppy.com (blargg) wrote:

In article <ln63n5xo05.... @nuthaus.mib.or g>, Keith Thompson
>
<ks...@mib.orgw rote:

blargg....@gish puppy.com (blargg) writes:
[...]

And while we're on the topic, using a cast is actually a GOOD idea if one
is naming the type in sizeof, since it will catch the error of the
destination type being different than you expect:

>

long* p = malloc( n * sizeof (int) ); // oops, but no error
long* p = (int*) malloc( n * sizeof (int) ); // compiler catches it

What about long *p = (long *)malloc(n * sizeof (int)); ?
Your method is not offering anything.

long *p = malloc(n * sizeof *p); // no error for the compiler to catch

>
You snipped the context. This is going in circles now :)
>
My point was that if the expression being assigned to is more unweildy
than the type name itself, one might choose to use sizeof(type) rather
than sizeof *expr_being_ass igned_to. In that case, casting the result of
malloc to type* ensures that the type being assigned to is compatible with
the type you're allocating for. Thus, if you had
>
foo [i]->bar->baz [j]->boo [k]->blarg =
malloc( n * sizeof *foo [i]->bar->baz [j]->boo [k]->blarg );
>
you might prefer to just name the type of blarg, let's say int* here
>
foo [i]->bar->baz [j]->boo [k]->blarg = malloc( n * sizeof (int) );
>
but if it really was long* , you'd have an undiagnosed error. But if you
also cast the result
>
foo [i]->bar->baz [j]->boo [k]->blarg = (int*) malloc( n * sizeof (int) );
>
you'd get a compile error if it wasn't an int*. Yes, you could mistakenly
cast it to a long* and use sizeof(int), introducing an error anyway, but
the lesser distance between the inconsistencies is such that it can be
easier to track down. It's only a few characters, while the distance
between a mismatch in the second example that lacks the cast might be
hundreds of lines, or span files.

If you're dealing with that many levels of dereferencing, it's quite
possible that your code needs rewriting.

[Keith Thompson]

Re: dynamically allocate array variable of type LPWSTR

blargg.h4g@gish puppy.com (blargg) writes:

In article <ln63n5xo05.fsf @nuthaus.mib.or g>, Keith Thompson
<kst-u@mib.orgwrote:
>

>blargg.h4g@gish puppy.com (blargg) writes:
>[...]

And while we're on the topic, using a cast is actually a GOOD idea if one
is naming the type in sizeof, since it will catch the error of the
destination type being different than you expect:
>
long* p = malloc( n * sizeof (int) ); // oops, but no error
long* p = (int*) malloc( n * sizeof (int) ); // compiler catches it

>>
>long *p = malloc(n * sizeof *p); // no error for the compiler to catch

>
You snipped the context. This is going in circles now :)
>
My point was that if the expression being assigned to is more unweildy
than the type name itself, one might choose to use sizeof(type) rather
than sizeof *expr_being_ass igned_to. In that case, casting the result of
malloc to type* ensures that the type being assigned to is compatible with
the type you're allocating for.

[...]

And *my* point is that, even if the expression is unwieldy, using the
type name is not the answer. Either go ahead and use the expression
anyway, or use a simpler expression.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ben Bacarisse]

Re: dynamically allocate array variable of type LPWSTR

blargg.h4g@gish puppy.com (blargg) writes:

In article <ln63n5xo05.fsf @nuthaus.mib.or g>, Keith Thompson
<kst-u@mib.orgwrote:
>

>blargg.h4g@gish puppy.com (blargg) writes:
>[...]

And while we're on the topic, using a cast is actually a GOOD idea if one
is naming the type in sizeof, since it will catch the error of the
destination type being different than you expect:
>
long* p = malloc( n * sizeof (int) ); // oops, but no error
long* p = (int*) malloc( n * sizeof (int) ); // compiler catches it

>>
>long *p = malloc(n * sizeof *p); // no error for the compiler to catch

>
You snipped the context. This is going in circles now :)

I'd like to unwind some of them! I think there are two problems here
and they should be separated. The first is allocating the right
sized memory using malloc (et al.) and the second is an odd problem of
having the wrong declaration for a pointer variable.

For the first, the c.l.c idiom is unequivocally the best solution and
having an unwieldy expression in the assignment simply suggest that
other simplification is required -- not that the idiom is at fault.

For the second, a cast on malloc might catch one instance but surely
there will be others if the declaration is wrong? If you find that
your code (or any code base) seems to have this sort of error in it
then you need another solution. One possibility would be use a type
assertion which can be put anywhere, though of course, it could be
combined with a malloc call:

#define PTR_TYPE_ASSERT (type, var) do { type (*t_) = (var); } while (0)

p = malloc(n * sizeof *p);
PTR_TYPE_ASSERT (long, p);

--
Ben.

[blargg]

Re: dynamically allocate array variable of type LPWSTR

In article <W_OdnQWgLIdaFJ PUnZ2dnUVZ8jGdn Z2d@bt.com>,
Richard Heathfield <rjh@see.sig.in validwrote:

blargg said:
>
<snip>
>

And while we're on the topic, using a cast is actually a GOOD idea if one
is naming the type in sizeof, since it will catch the error of the
destination type being different than you expect:

>
If you're using a pointer type other than the one you intended to use,
presumably there'll be plenty of cases elsewhere in the code where you use
the type you *did* intend to use, in which case there should be no
shortage of diagnostic messages. And assuming that, by adding a cast, you
can catch a type error for a call to a function returning void *, is a
poor strategy...
>

long* p = malloc( n * sizeof (int) ); // oops, but no error
long* p = (int*) malloc( n * sizeof (int) ); // compiler catches it

>
long *p = (long *)malloc(n * sizeof (int)); /* oops, no error */

Below is the essence of the issue raised in the thread, where the
expression being assigned to is complex and one would rather not repeat
it within the malloc, so ignore the fact that one would much prefer
malloc(sizeof *p) if this were the actual code.

Of the two, which error is more likely to be caught by the programmer?

long* p;

// way later in file
p = malloc( sizeof (int) ); // 1
p = (long*) malloc( sizeof (int) ); // 2

I'd say that 2 is more likely to be caught by the programmer. That was
my only point; if it's a choice between these two, I'd prefer the
second, because the programmer can more easily verify that he did the
cast correctly, and the compiler can then verify the assignment. In the
first, the compiler can't catch anything, and the programmer has to
compare the type of p, wherever it's defined, to the type in malloc. And
as a reminder, see the disclaimer in the previous paragraph.

[Richard Heathfield]

Re: dynamically allocate array variable of type LPWSTR

blargg said:

<snip>

Below is the essence of the issue raised in the thread, where the
expression being assigned to is complex and one would rather not repeat
it within the malloc, so ignore the fact that one would much prefer
malloc(sizeof *p) if this were the actual code.

Sorry, but I find it impossible to ignore the significantly superior
solution in favour of a couple of broken ones.

Of the two, which error is more likely to be caught by the programmer?
>
long* p;
>
// way later in file
p = malloc( sizeof (int) ); // 1
p = (long*) malloc( sizeof (int) ); // 2

You've provided two inferior idioms, and asked which is better (for a
certain value of "better", which you rightly define). My answer is: forget
them both, and use the *best* idiom.

I'd say that 2 is more likely to be caught by the programmer. That was
my only point; if it's a choice between these two, I'd prefer the
second,

But that's a false dichotomy. There is another choice, and it's a better
one than either of those (which, incidentally, appear equally broken to
me).

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Joachim Schmitz]

Re: dynamically allocate array variable of type LPWSTR

blargg wrote:

In article <W_OdnQWgLIdaFJ PUnZ2dnUVZ8jGdn Z2d@bt.com>,
Richard Heathfield <rjh@see.sig.in validwrote:
>

>blargg said:
>>
><snip>
>>

>>And while we're on the topic, using a cast is actually a GOOD idea
>>if one is naming the type in sizeof, since it will catch the error
>>of the destination type being different than you expect:

>>
>If you're using a pointer type other than the one you intended to
>use, presumably there'll be plenty of cases elsewhere in the code
>where you use the type you *did* intend to use, in which case there
>should be no shortage of diagnostic messages. And assuming that, by
>adding a cast, you can catch a type error for a call to a function
>returning void *, is a poor strategy...
>>

>>>
>> long* p = malloc( n * sizeof (int) ); // oops, but no error
>> long* p = (int*) malloc( n * sizeof (int) ); // compiler
>>catches it

>>
>long *p = (long *)malloc(n * sizeof (int)); /* oops, no error */

>
Below is the essence of the issue raised in the thread, where the
expression being assigned to is complex and one would rather not
repeat it within the malloc, so ignore the fact that one would much
prefer malloc(sizeof *p) if this were the actual code.
>
Of the two, which error is more likely to be caught by the programmer?
>
long* p;
>
// way later in file
p = malloc( sizeof (int) ); // 1
p = (long*) malloc( sizeof (int) ); // 2
>
I'd say that 2 is more likely to be caught by the programmer. That was
my only point; if it's a choice between these two, I'd prefer the
second, because the programmer can more easily verify that he did the
cast correctly, and the compiler can then verify the assignment. In
the first, the compiler can't catch anything, and the programmer has
to compare the type of p, wherever it's defined, to the type in
malloc. And as a reminder, see the disclaimer in the previous
paragraph.

What if, instead of your 'better' version, some programmer writes
p = (int*) malloc( sizeof (int) ); // 3
Leaves him/her in the false assumption that everything is fine, right?

What if that programmer forgot to provide a prototype for malloc()?
The compiler won't be able to warn him/her about it.

What if int was the right choce at one time, but later got changed to long?

So your solution does cause more harm than it has benefits. A plain and
simple
p = malloc( sizeof *p ); // 4
doesn't have any of these problems. The only problem that it does have, is
that you can't use a C++ Compiler on it. But then again in C++ you should be
using C++ means of allocation memore, i.e. 'new' rather that C methods, so
even that problen is not a problem but a chance to modify the code to do it
right rather than to carry over some legacy code.

Bye, Jojo

[Eric Sosman]

Re: dynamically allocate array variable of type LPWSTR

Joachim Schmitz wrote:

blargg wrote:

>[...]
>Of the two, which error is more likely to be caught by the programmer?
>>
> long* p;
>>
> // way later in file
> p = malloc( sizeof (int) ); // 1
> p = (long*) malloc( sizeof (int) ); // 2
>>
>I'd say that 2 is more likely to be caught by the programmer. That was
>my only point; if it's a choice between these two, I'd prefer the
>second, because the programmer can more easily verify that he did the
>cast correctly, and the compiler can then verify the assignment. [...]

>
What if, instead of your 'better' version, some programmer writes
p = (int*) malloc( sizeof (int) ); // 3
Leaves him/her in the false assumption that everything is fine, right?

Not after the compiler issues the mandatory diagnostic message ...

What if that programmer forgot to provide a prototype for malloc()?
The compiler won't be able to warn him/her about it.

Many C90 compilers will; all C99 compilers must.

What if int was the right choce at one time, but later got changed to long?
>
So your solution does cause more harm than it has benefits. A plain and
simple
p = malloc( sizeof *p ); // 4
doesn't have any of these problems. The only problem that it does have, is
that you can't use a C++ Compiler on it. [...]

blargg explicitly acknowledges this form as superior to both
his alternatives, but points out that it does in fact have a problem:
What, he askes, if `p' is more complicated?

findRoot(muggle ,buggle)->branch[sublevel++].
recorded_maxima->thresholds
= malloc(sizeof *findRoot(muggl e,buggle)->
branch[sublevel++].recorded_maxim a->thresholds);

Yes, you can pretty easily copy-and-paste to get the thing right in
the first place, but you wind up with a mess that a future programmer
will have trouble reading and verifying. Plus, you've got that scary-
looking side-effect that seems to occur twice ...

Personally, I don't find blargg's problem all that troublesome.
Maybe it's just style, but the left-hand sides of my mallocations
don't tend to be quite that involved; I'd be tempted to decompose
them anyhow, as in

Root root = findRoot(muggle ,buggle);
Maxima maxima = root->branch[sublevel++].recorded_maxim a;
maxima->thresholds = malloc(sizeof *maxima->thresholds);

.... on the grounds that this would improve readability even if the
mallocation were a printf or some such.

--
Eric.Sosman@sun .com

[CBFalconer]

Re: dynamically allocate array variable of type LPWSTR

blargg wrote:

>

.... snip ...

>
Below is the essence of the issue raised in the thread, where the
expression being assigned to is complex and one would rather not
repeat it within the malloc, so ignore the fact that one would
much prefer malloc(sizeof *p) if this were the actual code.
>
Of the two, which error is more likely to be caught by the
programmer?
>
long* p;
>
// way later in file
p = malloc( sizeof (int) ); // 1
p = (long*) malloc( sizeof (int) ); // 2
>
I'd say that 2 is more likely to be caught by the programmer.
That was my only point; if it's a choice between these two, I'd
prefer the second, because the programmer can more easily verify
that he did the cast correctly, and the compiler can then verify
the assignment. In the first, the compiler can't catch anything,
and the programmer has to compare the type of p, wherever it's
defined, to the type in malloc. And as a reminder, see the
disclaimer in the previous paragraph.

However, using the generally approved technique:

long *p;
...
/* anywhere later in file */
p = malloc(N * sizeof *p);

(and you can replace "N *" with nothing for N == 1) is proof
against errors anywhere. Why use anything poorer?

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[blargg]

Re: dynamically allocate array variable of type LPWSTR

In article <1225737875.108 099@news1nwk>, Eric Sosman <Eric.Sosman@su n.com>
wrote:

Joachim Schmitz wrote:

blargg wrote:

[...]
Of the two, which error is more likely to be caught by the programmer?

^^^^^^^^^^
Easy to miss this part, or disregard it, I guess. :(

long* p;
>
// way later in file
p = malloc( sizeof (int) ); // 1
p = (long*) malloc( sizeof (int) ); // 2
>
I'd say that 2 is more likely to be caught by the programmer. That was
my only point; if it's a choice between these two, I'd prefer the
second, because the programmer can more easily verify that he did the
cast correctly, and the compiler can then verify the assignment. [...]

What if, instead of your 'better' version, some programmer writes
p = (int*) malloc( sizeof (int) ); // 3
Leaves him/her in the false assumption that everything is fine, right?

>
Not after the compiler issues the mandatory diagnostic message ...
>

What if that programmer forgot to provide a prototype for malloc()?
The compiler won't be able to warn him/her about it.

>
Many C90 compilers will; all C99 compilers must.
>

What if int was the right choce at one time, but later got changed to long?

So your solution does cause more harm than it has benefits. A plain and
simple
p = malloc( sizeof *p ); // 4
doesn't have any of these problems. The only problem that it does have, is
that you can't use a C++ Compiler on it. [...]

>
blargg explicitly acknowledges this form as superior to both
his alternatives, but points out that it does in fact have a problem:
What, he askes, if `p' is more complicated?

Thank you. At least someone is reading my entire posts before responding. :)

[...]

Personally, I don't find blargg's problem all that troublesome.

Yes, it's not common for it to be complex, but someone brought it up so I
figured I'd try to address it. Personally, my solution is to use C++.

findRoot(muggle ,buggle)->branch[sublevel++].
recorded_maxima->thresholds
= malloc(sizeof *findRoot(muggl e,buggle)->
branch[sublevel++].recorded_maxim a->thresholds);

Last comment on this subject from me. I suppose one could write a macro to
encapsulate it:

#define SMART_MALLOC( out, n ) \
out = malloc( (n) * sizeof *(out) )

SMART_MALLOC( findRoot(muggle ,buggle)->branch[sublevel++].
recorded_maxima->thresholds, 1 );

[blargg]

Re: dynamically allocate array variable of type LPWSTR

Richard Heathfield wrote:

blargg said:
<snip>

Below is the essence of the issue raised in the thread, where the
expression being assigned to is complex and one would rather not repeat
it within the malloc, so ignore the fact that one would much prefer
malloc(sizeof *p) if this were the actual code.

>
Sorry, but I find it impossible to ignore the significantly superior
solution in favour of a couple of broken ones.

Too bad; I find value in sometimes exploring and analyzing things without
regard to their immediate value. I also find that separating things into
absolute good/bad is very limiting, because there are always situations
where the "good" is worse than the "bad". I prefer to let the situation
determine the relative value of different approaches, and choose the best
approach for each particular situation. In this situation, as I described
at the start, the only question was which was better of the two shown. I
completely disregarded the merit of either as compared to other
alternatives. I guess it's a sort of modularity-of-analysis, rather than
trying to do everything at once.

Of the two, which error is more likely to be caught by the programmer?

long* p;

// way later in file
p = malloc( sizeof (int) ); // 1
p = (long*) malloc( sizeof (int) ); // 2
I'd say that 2 is more likely to be caught by the programmer. That was
my only point; if it's a choice between these two, I'd prefer the
second,

>
But that's a false dichotomy. There is another choice, and it's a better
one than either of those (which, incidentally, appear equally broken to
me).

I never said those were the only choices; I simply wanted to show that
among those, one was better. The reasoning behind it was the key point.

[Nick Keighley]

Re: dynamically allocate array variable of type LPWSTR

On 4 Nov, 04:14, blargg....@gish puppy.com (blargg) wrote:

In article <1225737875.108 099@news1nwk>, Eric Sosman <Eric.Sos...@su n.com>

Joachim Schmitz wrote:

blargg wrote:

>Of the two, which error is more likely to be caught by the programmer?

>
     ^^^^^^^^^^
Easy to miss this part, or disregard it, I guess. :(

upu are asking "which of two bad solutions should I pick instead of
using the good solution". Or "is it better to play russian roulette
with one bullet or two?".

>   long* p;

>

>   // way later in file

design problem 1. Why are the two a long way apart?

>   p = malloc( sizeof (int) ); // 1
>   p = (long*) malloc( sizeof (int) ); // 2

design problem 2. Simply use the clc recomended idiom.

p = malloc (sizeof *p);

it's even shorter in this case

>I'd say that 2 is more likely to be caught by the programmer. That was
>my only point; if it's a choice between these two, I'd prefer the
>second, because the programmer can more easily verify that he did the
>cast correctly, and the compiler can then verify the assignment.  [...]

<snip>

     blargg explicitly acknowledges this form as superior to both
his alternatives, but points out that it does in fact have a problem:
What, he askes, if `p' is more complicated?

use a variable

Thank you. At least someone is reading my entire posts before responding.:)
>

     Personally, I don't find blargg's problem all that troublesome.

I think he's straining at gnats

Yes, it's not common for it to be complex, but someone brought it up so I
figured I'd try to address it. Personally, my solution is to use C++.

I wouldn't be using malloc() with C++

        findRoot(muggle ,buggle)->branch[sublevel++].
            recorded_maxima->thresholds
            = malloc(sizeof *findRoot(muggl e,buggle)->
                  branch[sublevel++].recorded_maxim a->thresholds);

long *thesholds;
thresholds = malloc (sizeof *thresholds);
findRoot (muggle, buggle)->branch [sublevel++].recorded_maxim a-

>thresholds

= thresholds;

Last comment on this subject from me. I suppose one could write a macro to
encapsulate it:

yuk! (and that's before I read the macro)

>
    #define SMART_MALLOC( out, n ) \
        out = malloc( (n) * sizeof *(out) )

yup. I've written this macro. It's a bad idea.

    SMART_MALLOC( findRoot(muggle ,buggle)->branch[sublevel++].
            recorded_maxima->thresholds, 1 )

[oops, possible over-keen snipping by me]

but still, yuk!


--
Nick Keighley

"That's right!" shouted Vroomfondel "we demand rigidly defined
areas of doubt and uncertainty!"

[Richard Heathfield]

Re: dynamically allocate array variable of type LPWSTR

blargg said:

Richard Heathfield wrote:

>blargg said:
><snip>

Below is the essence of the issue raised in the thread, where the
expression being assigned to is complex and one would rather not
repeat it within the malloc, so ignore the fact that one would much
prefer malloc(sizeof *p) if this were the actual code.

>>
>Sorry, but I find it impossible to ignore the significantly superior
>solution in favour of a couple of broken ones.

>
Too bad; I find value in sometimes exploring and analyzing things without
regard to their immediate value.

"What use is a new-born baby?" and all that. That's often a compelling
argument, but I don't think it really works here.

I also find that separating things into
absolute good/bad is very limiting, because there are always situations
where the "good" is worse than the "bad".

A pragmatic attitude - "whatever works!" - is good. But a pragmatic
attitude will, all else being equal, tend to favour a good solution over a
bad one, simply because it works better.

I prefer to let the situation
determine the relative value of different approaches, and choose the best
approach for each particular situation. In this situation, as I described
at the start, the only question was which was better of the two shown.

Then it was the wrong question. :-)

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999