Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #21648 > unrolled thread

Q: Local variables initialization shortcut.

Back to article view | Back to comp.lang.c

Contents

  Q: Local variables initialization shortcut. Jean-Christophe <5.d@free.fr> - 2012-06-02 02:49 -0700
    Re: Q: Local variables initialization shortcut. China Blue Max <chine.bleu@yahoo.com> - 2012-06-02 03:03 -0700
      Re: Q: Local variables initialization shortcut. Jean-Christophe <5.d@free.fr> - 2012-06-02 03:17 -0700
    Re: Q: Local variables initialization shortcut. jacob navia <jacob@spamsink.net> - 2012-06-02 12:06 +0200
      Re: Q: Local variables initialization shortcut. Jean-Christophe <5.d@free.fr> - 2012-06-02 03:25 -0700
        Re: Q: Local variables initialization shortcut. James Kuyper <jameskuyper@verizon.net> - 2012-06-02 10:59 -0400
          Re: Q: Local variables initialization shortcut. Jean-Christophe <5.d@free.fr> - 2012-06-02 13:02 -0700
            Re: Q: Local variables initialization shortcut. Keith Thompson <kst-u@mib.org> - 2012-06-02 14:51 -0700
    Re: Q: Local variables initialization shortcut. Ian Collins <ian-news@hotmail.com> - 2012-06-02 22:10 +1200
    Re: Q: Local variables initialization shortcut. jt@toerring.de (Jens Thoms Toerring) - 2012-06-02 10:31 +0000
      Re: Q: Local variables initialization shortcut. Jean-Christophe <5.d@free.fr> - 2012-06-02 03:59 -0700
        Re: Q: Local variables initialization shortcut. jt@toerring.de (Jens Thoms Toerring) - 2012-06-02 11:55 +0000
          Re: Q: Local variables initialization shortcut. pete <pfiland@mindspring.com> - 2012-06-02 08:15 -0400
          Re: Q: Local variables initialization shortcut. Jean-Christophe <5.d@free.fr> - 2012-06-02 05:37 -0700
            Re: Q: Local variables initialization shortcut. jt@toerring.de (Jens Thoms Toerring) - 2012-06-02 13:35 +0000
              Re: Q: Local variables initialization shortcut. Jean-Christophe <5.d@free.fr> - 2012-06-02 06:47 -0700
                Re: Q: Local variables initialization shortcut. "BartC" <bc@freeuk.com> - 2012-06-02 15:08 +0100
                  Re: Q: Local variables initialization shortcut. Jean-Christophe <5.d@free.fr> - 2012-06-02 07:37 -0700
                    Re: Q: Local variables initialization shortcut. "BartC" <bc@freeuk.com> - 2012-06-02 16:17 +0100
                      Re: Q: Local variables initialization shortcut. "BartC" <bc@freeuk.com> - 2012-06-02 19:02 +0100
                Re: Q: Local variables initialization shortcut. jt@toerring.de (Jens Thoms Toerring) - 2012-06-02 17:39 +0000
                  Re: Q: Local variables initialization shortcut. Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-02 15:27 -0400
                    Re: Q: Local variables initialization shortcut. Jean-Christophe <5.d@free.fr> - 2012-06-02 12:58 -0700
                      Re: Q: Local variables initialization shortcut. Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-02 16:15 -0400
                    Re: Q: Local variables initialization shortcut. David Brown <david.brown@hesbynett.no> - 2012-06-03 15:27 -0500
                      Re: Q: Local variables initialization shortcut. Noob <root@localhost> - 2012-06-05 09:12 +0200
                        Re: Q: Local variables initialization shortcut. David Brown <david@westcontrol.removethisbit.com> - 2012-06-05 09:21 +0200
                  Re: Q: Local variables initialization shortcut. Jean-Christophe <5.d@free.fr> - 2012-06-02 12:53 -0700
                    Re: Q: Local variables initialization shortcut. "BartC" <bc@freeuk.com> - 2012-06-02 21:16 +0100
                    Re: Q: Local variables initialization shortcut. jt@toerring.de (Jens Thoms Toerring) - 2012-06-02 21:18 +0000
                      Re: Q: Local variables initialization shortcut. Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-02 17:38 -0400
                        Re: Q: Local variables initialization shortcut. jt@toerring.de (Jens Thoms Toerring) - 2012-06-02 22:15 +0000
                        Re: Q: Local variables initialization shortcut. Jean-Christophe <5.d@free.fr> - 2012-06-03 00:51 -0700
                        Re: Q: Local variables initialization shortcut. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-03 11:46 -0700
                      Re: Q: Local variables initialization shortcut. Jean-Christophe <5.d@free.fr> - 2012-06-03 00:13 -0700
                    Re: Q: Local variables initialization shortcut. Keith Thompson <kst-u@mib.org> - 2012-06-02 14:50 -0700
                    Re: Q: Local variables initialization shortcut. David Brown <david.brown@hesbynett.no> - 2012-06-03 15:34 -0500
            Re: Q: Local variables initialization shortcut. David Brown <david.brown@hesbynett.no> - 2012-06-03 15:25 -0500
          Re: Q: Local variables initialization shortcut. Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-02 08:46 -0400
          Re: Q: Local variables initialization shortcut. Jean-Christophe <5.d@free.fr> - 2012-06-02 05:46 -0700
            Re: Q: Local variables initialization shortcut. Jean-Christophe <5.d@free.fr> - 2012-06-02 05:53 -0700
              Re: Q: Local variables initialization shortcut. Ike Naar <ike@sverige.freeshell.org> - 2012-06-02 17:08 +0000
              Re: Q: Local variables initialization shortcut. "io_x" <a@b.c.invalid> - 2012-06-03 10:33 +0200
                Re: Q: Local variables initialization shortcut. "io_x" <a@b.c.invalid> - 2012-06-03 11:32 +0200
        Re: Q: Local variables initialization shortcut. pete <pfiland@mindspring.com> - 2012-06-02 08:03 -0400
          Re: Q: Local variables initialization shortcut. Jean-Christophe <5.d@free.fr> - 2012-06-02 05:18 -0700
      Re: Q: Local variables initialization shortcut. "io_x" <a@b.c.invalid> - 2012-06-03 10:32 +0200
    Re: Q: Local variables initialization shortcut. "BartC" <bc@freeuk.com> - 2012-06-02 11:45 +0100
      Re: Q: Local variables initialization shortcut. Jean-Christophe <5.d@free.fr> - 2012-06-02 04:17 -0700
        Re: Q: Local variables initialization shortcut. "BartC" <bc@freeuk.com> - 2012-06-02 12:40 +0100
          Re: Q: Local variables initialization shortcut. "BartC" <bc@freeuk.com> - 2012-06-02 12:51 +0100
          Re: Q: Local variables initialization shortcut. Jean-Christophe <5.d@free.fr> - 2012-06-02 04:57 -0700
            Re: Q: Local variables initialization shortcut. "BartC" <bc@freeuk.com> - 2012-06-02 14:00 +0100
              Re: Q: Local variables initialization shortcut. Jean-Christophe <5.d@free.fr> - 2012-06-02 06:12 -0700
                Re: Q: Local variables initialization shortcut. Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-02 09:58 -0400
                  Re: Q: Local variables initialization shortcut. David Brown <david.brown@hesbynett.no> - 2012-06-03 15:41 -0500
                Re: Q: Local variables initialization shortcut. Robert Wessel <robertwessel2@yahoo.com> - 2012-06-02 11:45 -0500
    Re: Q: Local variables initialization shortcut. Noob <root@localhost> - 2012-06-02 16:05 +0200
      Re: Q: Local variables initialization shortcut. Jean-Christophe <5.d@free.fr> - 2012-06-02 07:48 -0700
        Re: Q: Local variables initialization shortcut. "BartC" <bc@freeuk.com> - 2012-06-02 18:31 +0100
        Re: Q: Local variables initialization shortcut. jt@toerring.de (Jens Thoms Toerring) - 2012-06-02 17:50 +0000

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#21671

Sorry about the misunderstanding,
this is what I meant :

#include <stdio.h>
double a,b;
int main(void)
{
unsigned int ia = (unsigned int)&a;
unsigned int ib = (unsigned int)&b;
 printf( "ib - ia = %u\r\n", ib - ia );
 printf( "ia - ib = %u\r\n", ia - ib );
 return 0;
}


ib - ia = 8 // = sizeof(double)
ia - ib = 4294967288 // crap

[toc] | [prev] | [next] | [standalone]

#21698

On 2012-06-02, Jean-Christophe <5.d@free.fr> wrote:
> Sorry about the misunderstanding,
> this is what I meant :
>
> #include <stdio.h>
> double a,b;
> int main(void)
> {
> unsigned int ia = (unsigned int)&a;
> unsigned int ib = (unsigned int)&b;
>  printf( "ib - ia = %u\r\n", ib - ia );
>  printf( "ia - ib = %u\r\n", ia - ib );
>  return 0;
> }
>
> ib - ia = 8 // = sizeof(double)
> ia - ib = 4294967288 // crap

It's probably not crap, but -8 + (UINT_MAX+1) .

[toc] | [prev] | [next] | [standalone]

#21740

"Jean-Christophe" <5.d@free.fr> ha scritto nel messaggio
news:8ba1c5dd-15a9-4ffc-aaa2-ec5fbaa74d59@5g2000vbf.googlegroups.com...
> Sorry about the misunderstanding,
> this is what I meant :
>
> #include <stdio.h>
> double a,b;
> int main(void)
> {
> unsigned int ia = (unsigned int)&a;
> unsigned int ib = (unsigned int)&b;
> printf( "ib - ia = %u\r\n", ib - ia );
> printf( "ia - ib = %u\r\n", ia - ib );
> return 0;
> }
>
>
> ib - ia = 8 // = sizeof(double)
> ia - ib = 4294967288 // crap

it is the pointer way that is a crap
(4294967288+8)0xFFFFFFFF=0x100000000 mod 0xFFFFFFFF=0
ia - ib +  ib - ia = 0

[toc] | [prev] | [next] | [standalone]

#21743

"io_x" <a@b.c.invalid> ha scritto nel messaggio 
news:4fcb2256$0$1375$4fafbaef@reader2.news.tin.it...
>
> "Jean-Christophe" <5.d@free.fr> ha scritto nel messaggio
> news:8ba1c5dd-15a9-4ffc-aaa2-ec5fbaa74d59@5g2000vbf.googlegroups.com...
>> Sorry about the misunderstanding,
>> this is what I meant :
>>
>> #include <stdio.h>
>> double a,b;
>> int main(void)
>> {
>> unsigned int ia = (unsigned int)&a;
>> unsigned int ib = (unsigned int)&b;
>> printf( "ib - ia = %u\r\n", ib - ia );
>> printf( "ia - ib = %u\r\n", ia - ib );
>> return 0;
>> }
>>
>>
>> ib - ia = 8 // = sizeof(double)
>> ia - ib = 4294967288 // crap
>
> it is the pointer way that is a crap
> (4294967288+8)0xFFFFFFFF=0x100000000 mod 0xFFFFFFFF=0
> ia - ib +  ib - ia = 0

(4294967288+8)%0x100000000=0x100000000 & 0xFFFFFFFF=0

[toc] | [prev] | [next] | [standalone]

#21664

Jean-Christophe wrote:
> 
> On 2 juin, 12:31, j...@toerring.de :
 
> > '&z - &a' isn't legal - you can only subtract addresses
> > of locations within a single object (e.g. an array),
> 
> I've done it many times and it always worked fine :

If you beieve that something which works once,
will always work again, 
then why ask questions 
instead of just testing your code?

> &a is the address of 'a' so it's its memory location.

The C standard characterizes that operation as being undefined.

N1570
6.5.6 Additive operators

9 When two pointers are subtracted,
  both shall point to elements of the same array object,
  or one past the last element of the array object; 
  the result is the difference of the
  subscripts of the two array elements.

-- 
pete

[toc] | [prev] | [next] | [standalone]

#21666

On 2 juin, 14:03, pete :

> If you beieve that something which works once,
> will always work again,

I didn't meant that.

> then why ask questions
> instead of just testing your code?

Because I need advice.

> The C standard characterizes that operation as being undefined.
> N1570
> 6.5.6 Additive operators
> 9 When two pointers are subtracted,
>   both shall point to elements of the same array object,
>   or one past the last element of the array object;
>   the result is the difference of the
>   subscripts of the two array elements.

Good enough for me, thanks.

[toc] | [prev] | [next] | [standalone]

#21739

"Jens Thoms Toerring" <jt@toerring.de> ha scritto nel messaggio
news:a2u8bhF5u8U1@mid.uni-berlin.de...
> Jean-Christophe <5.d@free.fr> wrote:
>> The function f() has some local (double)
>> which should all be initialized to zero :
>
>> double a,b,c,d,...,x,y,z;
>> a = b = c =  ... = y = z = 0.0;
>
>> Can I use a shortcut like this :
>
>>  memset( &a, 0, number_of_variables * sizeof(double) );
>
> Your idea has a number of problems: for once, while it is
> not unlikely that they are all in consecutive memory lo-
> cations, that's not guaranteed - the simplest practical
> reason would be that the compiler finds that one or more
> of the variables is not really needs to  be kept in memory
> and can be optimized to reside in a CPU register only. Se-
> cond, even if that wouldn't be an issue, there is no reason
> at all that 'a' should be at the lowest address - quite
> often the variable defined last is the one with the lowest
> address - this is completely at the discretion of the com-
> piler. Finally not on all systems a 0.0 value is represen-
> ted by all bits set to zero.

yes, the compiler can do that, the compiler can do this etc
and you have no idea on how data appear...

[toc] | [prev] | [next] | [standalone]

#21656

"Jean-Christophe" <5.d@free.fr> wrote in message
news:5835baa1-db3f-4b81-a9e9-3ea20a632ba8@w24g2000vby.googlegroups.com...

> The function f() has some local (double)
> which should all be initialized to zero :
>
> a = b = c =  ... = y = z = 0.0;
>
> Can I use a shortcut like this :
>
> memset( &a, 0, number_of_variables * sizeof(double) );
>
> If yes, can I do this :
>
> memset( &a, 0, (&z - &a + sizeof(double)) );
>
> Like this :
>
> void f(void)
> {
> double a,b,c,d,...,x,y,z;
>
> memset( &a, 0, (unsigned int)( &z - &a + sizeof(double) ) );
>
> ...
> }

You need a feature not available in C, which is being able to have a
variable which is an alias of another. It might work like this:

double V[26]={0};
double a @ V[0], b @ V[1], etc.

Then identifier 'c' is equivalant to 'V[2]'. This way you might expect the
26-element V array to be cleared more efficiently than 26 individual
variables.

The nearest C can actually do might be:

#define a (V[0])
#define b (V[1])
etc

But, these macro names will have file scope; they will no longer be local.
(Unless maybe you play around with #undef and stuff like that.) Of course
your actual variable names might not be single letters so it need not be an
issue.

You can also use array elements directly: V[0], V[1] in place of a,b. Or
define some enumerations:

enum {a,b,c...} so that it's possible to write V[a], V[b] etc.

Alternatively, a struct can be used to contain all the variables:

struct {double a, b, c,... }V = {0};

Now you can just write: V.a, V.b and so on.

It's possible also that your compiler will arrange the variables so that it
can initialise them as one block anyway...

-- 
bartc 

[toc] | [prev] | [next] | [standalone]

#21658

On 2 juin, 12:45, "BartC" :

> You need a feature not available in C, which is being able to have a
> variable which is an alias of another. It might work like this:
> double V[26]={0};
> double a @ V[0], b @ V[1], etc.
> Then identifier 'c' is equivalant to 'V[2]'. This way you might expect the
> 26-element V array to be cleared more efficiently than 26 individual
> variables.

Yep.


> The nearest C can actually do might be:
> #define a (V[0])
> #define b (V[1])
> etc

Yes, that's what I said to 'Jens'.
But to write the whole set of #define will be a pain.
( some functions have as much as ~50 variables ... )


> But, these macro names will have file scope; they will no longer be local.
> (Unless maybe you play around with #undef and stuff like that.)

Yes, in this case that's what I would have done.
( just at the end '}' of the function)


> Of course your actual variable names might not be single letters

No, they are not single letters.


> so it need not be an issue.
> You can also use array elements directly: V[0], V[1] in place of a,b. Or
> define some enumerations:
> enum {a,b,c...} so that it's possible to write V[a], V[b] etc.

Yes, but then, using variables in the code will look like :

 V[VAR_THIS] = ... ;

Which I found less easy-to-use and trensparent than :

 VAR_THIS = ... ;


> Alternatively, a struct can be used to contain all the variables:
> struct {double a, b, c,... }V = {0};
> Now you can just write: V.a, V.b and so on.

Yes, I think it's the easyest shortcut in this case.

Now the drawback is : many functions with always-different
variable names, meaning a lot of different structures to define.


> It's possible also that your compiler will arrange the variables
> so that it can initialise them as one block anyway...

Yes, but I can't seriously rely on this since these
are local allocations in stack, done at runtime, etc.

I'm translating an existing source code into C language so
I'm using the very same variables names (to ease debugging)
I *have* to keep separate, 'individual', variables names.
(if I wrote it down in the fist place, I'd use structures)

[toc] | [prev] | [next] | [standalone]

#21659

"Jean-Christophe" <5.d@free.fr> wrote in message
news:e51b172a-e540-4893-9722-825232b3d1c2@m24g2000yqh.googlegroups.com...
> On 2 juin, 12:45, "BartC" :
>
>> You need a feature not available in C, which is being able to have a
>> variable which is an alias of another. It might work like this:
>> double V[26]={0};
>> double a @ V[0], b @ V[1], etc.
>> Then identifier 'c' is equivalant to 'V[2]'. This way you might expect
>> the
>> 26-element V array to be cleared more efficiently than 26 individual
>> variables.
>
> Yep.

Actually, if you are using doubles, then it doesn't necessarily follow that
it will be much slower to clear these one-by-one, compared with, say, 8 or
16-bit variables. (It's possible also it might be faster, if the compiler
would otherwise use a loop.) Have you done any measurements?

> I'm translating an existing source code into C language so
> I'm using the very same variables names (to ease debugging)
> I *have* to keep separate, 'individual', variables names.
> (if I wrote it down in the fist place, I'd use structures)

Do the variables need to be cleared on every call to the function? If they
only need to be cleared once, then using static variables will ensure they
are 0.0 at the start of execution (at least, on most hardware).

Also, does *every* variable need to start at zero? Some, surely, must have a
different starting value, perhaps set by an assignment. (In which case, a
compiler might optimise out the 0.0 initialisation; but it means you don't 
need to clear it first.)

You mentioned Windows elsewhere. If you're only interested in one particular
platform (eg. x86) and don't care about portability, perhaps consider a bit
of inline assembler. This can look at the frame and stack pointers, and do a 
block clear of the memory in between. Although this will indiscriminately 
zero all local variables, including ones you want initialised to something 
else. (They need initialising by assignment instead.)

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#21661

"BartC" <bc@freeuk.com> wrote in message news:jqcu41$oa0$1@dont-email.me...
> "Jean-Christophe" <5.d@free.fr> wrote in message

>> I'm translating an existing source code into C language so

> You mentioned Windows elsewhere. If you're only interested in one 
> particular
> platform (eg. x86) and don't care about portability, perhaps consider a 
> bit
> of inline assembler. This can look at the frame and stack pointers, and do 
> a block clear of the memory in between.

I should add this might not be portable across compilers either. Especially 
gcc, which might just decide to eliminate the frame pointer completely. But 
then it also makes it more difficult to use inline asm anyway.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#21663

On 2 juin, 13:40, "BartC" :

> Actually, if you are using doubles, then it doesn't necessarily follow that
> it will be much slower to clear these one-by-one, compared with, say, 8 or
> 16-bit variables. (It's possible also it might be faster, if the compiler
> would otherwise use a loop.) Have you done any measurements?

The speed is not an issue here.
The point is to reset to zero all these variables,
while keeping their original names.


> Do the variables need to be cleared on every call to the function?

Yes.


> If they only need to be cleared once, then using static variables
> will ensure they are 0.0 at the start of execution
> (at least, on most hardware).

Nah, can't be static.


> Also, does *every* variable need to start at zero?
> Some, surely, must have a different starting value,
> perhaps set by an assignment.

Yes.


> (In which case, a compiler might optimise out the 0.0
> initialisation; but it means you don't need to clear it first.)

That's right, but the original code is a real mess,
for debug purpose I need al least to set all variables to zero
otherwise I won't even know whose values are (in)correct.


> You mentioned Windows elsewhere. If you're only interested in one particular
> platform (eg. x86) and don't care about portability,

Yes, this is the case.


> perhaps consider a bit of inline assembler.
> This can look at the frame and stack pointers, and do a
> block clear of the memory in between. Although this will indiscriminately
> zero all local variables, including ones you want initialised to something
> else. (They need initialising by assignment instead.)

Hum, sounds a bit tricky to me.
Thanks for the idea anyway.

[toc] | [prev] | [next] | [standalone]

#21672

"Jean-Christophe" <5.d@free.fr> wrote in message 
news:4b5d8284-87f0-4596-9fe5-89ac413172a1@j9g2000vbk.googlegroups.com...
> On 2 juin, 13:40, "BartC" :
>
>> Actually, if you are using doubles, then it doesn't necessarily follow 
>> that
>> it will be much slower to clear these one-by-one, compared with, say, 8 
>> or
>> 16-bit variables. (It's possible also it might be faster, if the compiler
>> would otherwise use a loop.) Have you done any measurements?
>
> The speed is not an issue here.
> The point is to reset to zero all these variables,
> while keeping their original names.

Perhaps I'm missing the point somewhere, but in that case, what's wrong 
with:

double a=0.0, b=0.0, .... ?

Do you just want to save some typing?

> perhaps consider a bit of inline assembler.
>> This can look at the frame and stack pointers, and do a
>> block clear of the memory in between.

> Hum, sounds a bit tricky to me.
> Thanks for the idea anyway.

Yeah, forget that. You need to be on intimate terms with your compiler to 
try things like that.

-- 
Bartc

 

[toc] | [prev] | [next] | [standalone]

#21674

On 2 juin, 15:00, "BartC" :

> Perhaps I'm missing the point somewhere,
> but in that case, what's wrong with:
> double a=0.0, b=0.0, .... ?
> Do you just want to save some typing?

I'm re-writing a messy 7500 lines source code into C,
I kept all the same variables names to ease debugging
and there are a LOT of functions, each one with its
own LOT of local variables - all having different names.
At least I want to initialise all of them to zero to
avoid uninitialized variables fuck-up (if I may say so)

So it won't save me 'some' typing: I'll save a 'lot' of typing.


> > perhaps consider a bit of inline assembler.
> >> This can look at the frame and stack pointers, and do a
> >> block clear of the memory in between.
> > Hum, sounds a bit tricky to me.
> > Thanks for the idea anyway.

> Yeah, forget that. You need to be on intimate
> terms with your compiler to try things like that.

Sure. Thanks Bartc.

[toc] | [prev] | [next] | [standalone]

#21678

On 6/2/2012 9:12 AM, Jean-Christophe wrote:
> On 2 juin, 15:00, "BartC" :
>
>> Perhaps I'm missing the point somewhere,
>> but in that case, what's wrong with:
>> double a=0.0, b=0.0, .... ?
>> Do you just want to save some typing?
>
> I'm re-writing a messy 7500 lines source code into C,
> I kept all the same variables names to ease debugging
> and there are a LOT of functions, each one with its
> own LOT of local variables - all having different names.
> At least I want to initialise all of them to zero to
> avoid uninitialized variables fuck-up (if I may say so)

     Usually it's better to leave the variable uninitialized than
to initialize it with an essentially meaningless value.  As part
of their optimization efforts, most compilers perform data flow
analysis to answer questions like "Must we fetch the value of `x'
from memory, or is the value in CPU register 7 still valid?"
Such analysis will discover execution paths that might read a
variable before it's written, and the compiler can usually be told
to produce diagnostics when such paths are detected.  The popular
gcc compiler, for example, has the "-Wuninitialized" flag (which
is implied by some others like "-Wall") to enable such warnings.

     So if you have

	double x;
	for (int i = 0; i < N; ++i) {
	    if (array[i] < 0) {
	        x = array[i];
	        break;
	    }
	}
	printf ("%g\n", x);

... gcc can warn you that `x' might not have a value when used,
because the `if' might never trigger.

     BUT if you change the first line to `double x = 0;' gcc will
NOT issue any such warning: It sees that `x' necessarily has a
value, regardless of what happens with the `if' statements.  So
gcc will be silent and the output will be zero -- which is fine
if that was in fact the intent, but not so fine if you really
truly expected `x' to be the first negative value in `array',
and there isn't one.

     In short, the bug (assuming `array' always has at least one
negative value) is still there, and all you've done is make the
bug's symptom predictable: Your supposedly negative value shows
up as zero.  So, which would you rather have: A nice session with
the debugger, trying to discover why `x' isn't negative (or why a
long computation deriving something from `x' behaves strangely),
or a compile-time warning drawing your attention to a potential
problem?

> So it won't save me 'some' typing: I'll save a 'lot' of typing.

     Seems to me the `lot' of typing does more harm than good.
Usually.  YMMV.  And so on.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#21762

On Sat, 02 Jun 2012 09:58:13 -0400, Eric Sosman wrote:

> On 6/2/2012 9:12 AM, Jean-Christophe wrote:
>> On 2 juin, 15:00, "BartC" :
>>
>>> Perhaps I'm missing the point somewhere, but in that case, what's
>>> wrong with:
>>> double a=0.0, b=0.0, .... ?
>>> Do you just want to save some typing?
>>
>> I'm re-writing a messy 7500 lines source code into C, I kept all the
>> same variables names to ease debugging and there are a LOT of
>> functions, each one with its own LOT of local variables - all having
>> different names. At least I want to initialise all of them to zero to
>> avoid uninitialized variables fuck-up (if I may say so)
> 
>      Usually it's better to leave the variable uninitialized than
> to initialize it with an essentially meaningless value.  As part of
> their optimization efforts, most compilers perform data flow analysis to
> answer questions like "Must we fetch the value of `x' from memory, or is
> the value in CPU register 7 still valid?" Such analysis will discover
> execution paths that might read a variable before it's written, and the
> compiler can usually be told to produce diagnostics when such paths are
> detected.  The popular gcc compiler, for example, has the
> "-Wuninitialized" flag (which is implied by some others like "-Wall") to
> enable such warnings.
> 
>      So if you have
> 
> 	double x;
> 	for (int i = 0; i < N; ++i) {
> 	    if (array[i] < 0) {
> 	        x = array[i];
> 	        break;
> 	    }
> 	}
> 	printf ("%g\n", x);
> 
> ... gcc can warn you that `x' might not have a value when used, because
> the `if' might never trigger.
> 
>      BUT if you change the first line to `double x = 0;' gcc will
> NOT issue any such warning: It sees that `x' necessarily has a value,
> regardless of what happens with the `if' statements.  So gcc will be
> silent and the output will be zero -- which is fine if that was in fact
> the intent, but not so fine if you really truly expected `x' to be the
> first negative value in `array', and there isn't one.
> 
>      In short, the bug (assuming `array' always has at least one
> negative value) is still there, and all you've done is make the bug's
> symptom predictable: Your supposedly negative value shows up as zero. 
> So, which would you rather have: A nice session with the debugger,
> trying to discover why `x' isn't negative (or why a long computation
> deriving something from `x' behaves strangely), or a compile-time
> warning drawing your attention to a potential problem?
> 
>> So it won't save me 'some' typing: I'll save a 'lot' of typing.
> 
>      Seems to me the `lot' of typing does more harm than good.
> Usually.  YMMV.  And so on.

This sounds to me like a /very/ important point.

To the OP - it's helpful to say what you are really trying to achieve, 
rather than just one aspect of the implementation.

[toc] | [prev] | [next] | [standalone]

#21696

On Sat, 2 Jun 2012 06:12:27 -0700 (PDT), Jean-Christophe <5.d@free.fr>
wrote:

>On 2 juin, 15:00, "BartC" :
>
>> Perhaps I'm missing the point somewhere,
>> but in that case, what's wrong with:
>> double a=0.0, b=0.0, .... ?
>> Do you just want to save some typing?
>
>I'm re-writing a messy 7500 lines source code into C,
>I kept all the same variables names to ease debugging
>and there are a LOT of functions, each one with its
>own LOT of local variables - all having different names.
>At least I want to initialise all of them to zero to
>avoid uninitialized variables fuck-up (if I may say so)
>
>So it won't save me 'some' typing: I'll save a 'lot' of typing.


7500 lines is a pretty small amount of code, but if the typing is
bothering you, set up a keyboard macro in your editor to insert the
"=0.0".  If you're cleaning code up, finish that macro with a search
to the next command space or semi-colon (and another to just do the
search), so you can just flip through looking at each item, and then
hit one of two keys - one inserts the initialization and skips to the
next possible place you need one, the other skips.

Use your tools.

[toc] | [prev] | [next] | [standalone]

#21683

Jean-Christophe wrote:

> The function f() has some local (double)
> which should all be initialized to zero :
> 
>  a = b = c =  ... = y = z = 0.0;
> 
> Can I use a shortcut like this :
> 
>  memset( &a, 0, number_of_variables * sizeof(double) );
> 
> If yes, can I do this :
> 
>  memset( &a, 0, (&z - &a + sizeof(double)) );
> 
> Like this :
> 
> void f(void)
> {
> double a,b,c,d,...,x,y,z;
> 
>  memset( &a, 0, (unsigned int)( &z - &a + sizeof(double) ) );
> 
>  ...
> }

You can use an anonymous struct.
No need for memset, and portable; what more do you want? :-)

void foo(void)
{
  struct { double a,b,c,d,e,f,g,h; } s = { 0 };
  s.a = 42.0;
}

[toc] | [prev] | [next] | [standalone]

#21697

On Jun 2, 4:05 pm, Noob <root@localhost> wrote:

> You can use an anonymous struct. No need for
> memset, and portable; what more do you want? :-)

Yes, Jens pointed it to me and I agreed.

[toc] | [prev] | [next] | [standalone]

#21699

"Jean-Christophe" <5.d@free.fr> wrote in message
news:78b578f9-5187-4a81-924c-a757f8cc1452@b1g2000vbb.googlegroups.com...
> On Jun 2, 4:05 pm, Noob <root@localhost> wrote:
>
>> You can use an anonymous struct. No need for
>> memset, and portable; what more do you want? :-)
>
> Yes, Jens pointed it to me and I agreed.

But, if the purpose now is to reduce typing, then sticking "s." in front of 
every instance of a variable, sounds like more work than simply putting "=0" 
once after it's declaration.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web