David R Tribble wrote:
.
> Uh, yes.  C++ uses '0', an integer constant, as its null pointer
> constant (which leads to ambiguous expressions).  C allows
> '(void*)0', an expression with a pointer type, as its null pointer
> constant (which is never ambiguous).
>
> Many C++ authors, Bjarne included, have the extremely annoying
> habit of saying "zero" instead of "null".  Assigning zero to a pointer
> is nonsense (since when is a pointer ever zero?); assigning null
> to a pointer is semantically correct.
>
> But neither language has a 'null' keyword (mostly for historical
> reasons), which is probably the "cleanest" solution.
.

It's misleading in the sense that the Standard does not require
that the expression "char *p = 0" set the bits bound as storage
for the pointer p all to zero.  If, on a particular CPU,
* reinterpret_cast<char *>(0) = 0 does not cause
the program to immediately abort, but
* reinterpret_cast<char *>(0xABC) = 0 does cause an
immediate abort, it would make more sense
(except for breaking gobs of otherwise
portable code) to put 0xABC into a pointer being set
to "zero".

The odd reuse of the numeral 0 for the number zero,
the null pointer, and in the syntax for a pure
virtuals pales in comparison to the infamous reuse
of "static".  It's fortunate that the Standard
Committee has lately decided to tell the "no new
keywords" crowd to stop crying and download
"sed" from the FSF website.

The desire to eliminate the need for "(X *) 0"
is based on the point of view that routine usage
of explicit casts should be eliminated.

Many C++ programmers are still using
#define NULL ((void *) 0) to init pointers.
This can (and should) cause compiler
warnings, which causes the programmer
to disable warnings, and thus not find
problems as quickly.  So, it may be better
to use the phrase "zero a pointer" becasue
"null a pointer" could be interpreted to mean
"set a pointer to NULL".

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

David R Tribble wrote:
> >> How far do you think C++ has progressed insomuch as
> >> abandoning its backward compatibility with C?

> James Kanze wrote:
> David R Tribble wrote:
> > > I think that many people today would say: not enough.

> David R Tribble wrote:
> >> And probably as many people, including Bjarne and most of the
> >> members of both the ISO C and ISO C++ committees, would say
> >> that attempting to maintain as much compatibility between the
> >> two languages is a desirable thing to do.

> James Kanze wrote:
> > I should have made it clear that I'm not one of those many:-).
> > I am fully in favor of maintaining a large degree of
> > compatibility with C.  My impression, however, is that I am in a
> > minority -- Stroustrup agrees, but sometimes I get the
> > impression that he is very alone on this.

> I'm agnostic about it myself.  They are two different
> langages, with two different audiences.  Problems only really
> arise when trying to use C libraries with C++ code.  This is
> probably an argument for C to be as upward-compatible with C++
> as possible, but not necessarily the other way around.

It is, IMHO, a very strong (almost a killer) argument for
maintaining a reasonably large compatible subset.

> David R Tribble wrote:
> >> And C++ programmers should not assume that C++ is superior
> >> in all areas than C.  (Take the issue of NULL, for example,
> >> for which C has a cleaner solution.)

> James Kanze wrote:
> > It does?  Your the first person I've heard express that view.
> > (Using the word "clean" for the current situation in either
> > language is an abuse, but the C++ solution seems slightly less
> > dirty.)

> Uh, yes.  C++ uses '0', an integer constant, as its null
> pointer constant (which leads to ambiguous expressions).

More precisely, any constant integral expression evaluating to 0
is a null pointer constant.  As I said, using the word "clean"
for this situation seems particularly inappropriate.  But this
is a situation that C++ inherited from C; it is, in fact,
exactly the situation in K&R C.

> C allows '(void*)0', an expression with a pointer type, as its
> null pointer constant (which is never ambiguous).

Allows, doesn't require.  The result is that C has all of the
problems of the C++ situation, plus some additional ambiguities
because you know even less about the real type.

Had the C committee said that only "((void*)0)" could be used as
a null pointer constant, I could go along with the idea that it
was an improvement.  (But of course, by the time C was being
standardized, this wasn't really an option.)

> Many C++ authors, Bjarne included, have the extremely annoying
> habit of saying "zero" instead of "null".  Assigning zero to a
> pointer is nonsense (since when is a pointer ever zero?);
> assigning null to a pointer is semantically correct.

Except that assigning "0" to a pointer is legal; assigning
"zero" or "null" to it isn't (unless you've defined some
variable with these names).  And of course, most English
speakers would pronounce "0" as "zero".

> But neither language has a 'null' keyword (mostly for
> historical reasons), which is probably the "cleanest"
> solution.

Definitly for historical reasons.  (The use of "0" made sense in
B; it was probably the only thing that would make sense for a
null pointer in B.)

> James Kanze wrote:
> > The way it looks, however, C++ will have a much cleaner
> > solution after the next revision.

> Praise be.  Something resembling '(void*)0', which programmers
> have been asking for for years?

I think it is spelled "nullptr" in the current proposal.  And if
memory serves me right, it is distinguishable from '(void*)0',
e.g. in overloading and template instantiations (but I could be
thinking of some other suggestion in that regard).

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

wkaras@yahoo.com wrote:
> David R Tribble wrote:
> .
> > Uh, yes.  C++ uses '0', an integer constant, as its null
> > pointer constant (which leads to ambiguous expressions).  C
> > allows '(void*)0', an expression with a pointer type, as its
> > null pointer constant (which is never ambiguous).

> > Many C++ authors, Bjarne included, have the extremely
> > annoying habit of saying "zero" instead of "null".
> > Assigning zero to a pointer is nonsense (since when is a
> > pointer ever zero?); assigning null to a pointer is
> > semantically correct.

> > But neither language has a 'null' keyword (mostly for
> > historical reasons), which is probably the "cleanest"
> > solution.
> .

> It's misleading in the sense that the Standard does not
> require that the expression "char *p = 0" set the bits bound
> as storage for the pointer p all to zero.

It's very, very confusing that:

    int const i1 = 0 ;
    int       i2 = 0 ;
    assert( (char*)i1 == (char*)i2 ) ;

may fail.  But confusion is something that a language with a
history cannot always avoid.

> If, on a particular CPU, * reinterpret_cast<char *>(0) = 0
> does not cause the program to immediately abort, but *
> reinterpret_cast<char *>(0xABC) = 0 does cause an immediate
> abort, it would make more sense (except for breaking gobs of
> otherwise portable code) to put 0xABC into a pointer being set
> to "zero".

(I think you've misexpressed your point---reinterpret_cast of a
null pointer constant to a pointer type is guaranteed to result
in null pointer.  What you probably meant is reinterpret_cast of
a non-const integer variable initialized with the value you
give.)

It would make more sense, but for various reasons, many
implementations haven't followed this reasoning.  On an Intel
8086, it would have made a lot more sense for the null pointer
to be 0xFFFF:0, since that address was always in ROM.  But all
of the implementations I've seen used 0:0, despite that being
writable memory.

> The odd reuse of the numeral 0 for the number zero, the null
> pointer, and in the syntax for a pure virtuals pales in
> comparison to the infamous reuse of "static".  It's fortunate
> that the Standard Committee has lately decided to tell the "no
> new keywords" crowd to stop crying and download "sed" from the
> FSF website.

It's not a black and white question.  If someone were to propose
a new keyword "i" (say as a name for complex(0,-1)), I rather
doubt that it would pass---and the fact that it would clash with
user symbols in existing code would doubtlessly be a big part of
the motivation. Part of the rationale behind the choice of
keywords for the new casts, when they were added, was that the
names used were very unlikely to occur in existing user code.
The Standard Committee has certainly not decided that anything
goes with regards to adding keywords.  They have, however,
adopted a more balanced approach, which weighs the advantages of
using a new keyword against the probability of it being used in
existing code.  While trying to keep the name meaningful, of
course.

I believe that the use of 'null' as the name of the new null
pointer constant was rejected because it was found to be too
widely used already.

> The desire to eliminate the need for "(X *) 0" is based on the
> point of view that routine usage of explicit casts should be
> eliminated.

> Many C++ programmers are still using
> #define NULL ((void *) 0) to init pointers.

In which case, they have undefined behavior.

In fact, I've never seen any recent code which does this; in
most implementations, it won't compile as soon as you include
some frequent standard headers.  In the Unix world, the most
frequent definition is probably:
    #define NULL __null
A magical "integral constant expression evaluating to 0", which
is recognized by the compiler and generates a warning if used
without being converted into a pointer.

> This can (and should) cause compiler warnings, which causes
> the programmer to disable warnings, and thus not find problems
> as quickly.

Does there exist a compiler where it doesn't cause an error if
<stddef.h> (or one of a couple of others) is included, even
indirectly.  (Note that one of the "couple of others" is
<stdio.h>.  And some of the iostream headers and maybe <string>
are pretty much required to include it, since they have to
ensure that the macro EOF has the same value as the return value
of std::char_traits<char>::eof().

> So, it may be better to use the phrase "zero a pointer"
> becasue "null a pointer" could be interpreted to mean "set a
> pointer to NULL".

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

>> How far do you think C++ has progressed insomuch as
>> abandoning its backward compatibility with C?
>

James Kanze wrote:
David R Tribble wrote:
> > I think that many people today would say: not enough.
>

David R Tribble wrote:
>> And probably as many people, including Bjarne and most of the
>> members of both the ISO C and ISO C++ committees, would say
>> that attempting to maintain as much compatibility between the
>> two languages is a desirable thing to do.
>>

James Kanze wrote:
> I should have made it clear that I'm not one of those many:-).
> I am fully in favor of maintaining a large degree of
> compatibility with C.  My impression, however, is that I am in a
> minority -- Stroustrup agrees, but sometimes I get the
> impression that he is very alone on this.

I'm agnostic about it myself.  They are two different langages,
with two different audiences.  Problems only really arise when
trying to use C libraries with C++ code.  This is probably an
argument for C to be as upward-compatible with C++ as possible,
but not necessarily the other way around.


David R Tribble wrote:
>> And C++ programmers should not assume that C++ is superior
>> in all areas than C.  (Take the issue of NULL, for example,
>> for which C has a cleaner solution.)
>

James Kanze wrote:
> It does?  Your the first person I've heard express that view.
> (Using the word "clean" for the current situation in either
> language is an abuse, but the C++ solution seems slightly less
> dirty.)

Uh, yes.  C++ uses '0', an integer constant, as its null pointer
constant (which leads to ambiguous expressions).  C allows
'(void*)0', an expression with a pointer type, as its null pointer
constant (which is never ambiguous).

Many C++ authors, Bjarne included, have the extremely annoying
habit of saying "zero" instead of "null".  Assigning zero to a pointer
is nonsense (since when is a pointer ever zero?); assigning null
to a pointer is semantically correct.

But neither language has a 'null' keyword (mostly for historical
reasons), which is probably the "cleanest" solution.


James Kanze wrote:
> The way it looks, however, C++ will have a much cleaner solution
> after the next revision.

Praise be.  Something resembling '(void*)0', which programmers
have been asking for for years?


David R Tribble wrote:
>> And finally, _both_ languages have features missing from them
>> that some people feel a "complete" language should provide
>> (e.g., automatic garbage collection, built-in support for
>> threads, etc.).
>

James Kanze wrote:
> Interesting point: in the parts I cut, you mentionned that the
> language shouldn't evolve, but only the libraries.  Where as the
> two points you mention cannot be handled strictly in the
> library; they require language modifications.  (Ditto the
> improvements in null pointer constants.)

I didn't say _I_ believed that, but that many people do.
I don't think either C or C++ are as complete as they should be,
language-wise or library-wise.

-drt

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 2006-06-18 04:26, David R Tribble wrote:
:
> Many C++ authors, Bjarne included, have the extremely annoying
> habit of saying "zero" instead of "null".

At least for Bjarne it might have to do with the fact that "zero" in
Danish is "nul". When you grow up in a language that gives you the
connotation "zero" for "null", it's very easy to extend the concept
of "zero" to include the null pointer value, or simply any canonical
singular element in a given algebraic structure.

-- Niklas Matthies

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

David  R Tribble writes:
>> Many people (again, including Bjarne) are of the opinion that
>> the languages should pretty much stop evolving (except for
>> some minor semantic clean-ups) and settle down for the long
>> haul, and that most of the improvements be made (only) to the
>> standard libraries.
>

Francis Glassborow wrote:
> FOFL. Have you had a good look at the work on the next version of C++
> including the contributions from Bjarne himself for things such as
> concepts, new initialisation syntax etc.

Bjarne said it, not me.  (In some magazine interview, IIRC.)
Obviously, he must have changed his mind.

-drt

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

>> How far do you think C++ has progressed insomuch as abandoning
>> its backward compatibility with C?
>

James Kanze wrote:
> I think that many people today would say: not enough.

And probably as many people, including Bjarne and most of the
members of both the ISO C and ISO C++ committees, would
say that attempting to maintain as much compatibility between
the two languages is a desirable thing to do.  (Bjarne has said
so in his "Sibling Rivalry" articles.)  Or to say it the other way
around, allowing the two languages to drift too far apart is a
bad thing.
  http://www.research.att.com/~bs/bs_faq.html#difference

Bear in mind that both languages continue to evolve, though
not as much as they did in their first one or two ISO revisions.
Many people (again, including Bjarne) are of the opinion that
the languages should pretty much stop evolving (except for
some minor semantic clean-ups) and settle down for the long
haul, and that most of the improvements be made (only) to the
standard libraries.

C and C++ are not that far apart today, and many conforming C
programs compile just fine as C++ programs (possibly with
just a few minor tweaks).  Many C programmers (I would think)
became better programmers because of the influence of C++.
  http://david.tribble.com/text/cdiffs.htm

And C++ programmers should not assume that C++ is superior
in all areas than C.  (Take the issue of NULL, for example,
for which C has a cleaner solution.)

And finally, _both_ languages have features missing from them
that some people feel a "complete" language should provide
(e.g., automatic garbage collection, built-in support for threads,
etc.).

-drt

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <1150042996.895868.31010@m38g2000cwc.googlegroups.com>, David
R Tribble <david@tribble.com> writes
>Bear in mind that both languages continue to evolve, though
>not as much as they did in their first one or two ISO revisions.
>Many people (again, including Bjarne) are of the opinion that
>the languages should pretty much stop evolving (except for
>some minor semantic clean-ups) and settle down for the long
>haul, and that most of the improvements be made (only) to the
>standard libraries.
FOFL. Have you had a good look at the work on the next version of C++
including the contributions from Bjarne himself for things such as
concepts, new initialisation syntax etc.

Yes the rate of change is greatly reduced but it is much more than just
adding new libraries.

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

David R Tribble wrote:
> >> How far do you think C++ has progressed insomuch as
> >> abandoning its backward compatibility with C?

> James Kanze wrote:
> > I think that many people today would say: not enough.

> And probably as many people, including Bjarne and most of the
> members of both the ISO C and ISO C++ committees, would say
> that attempting to maintain as much compatibility between the
> two languages is a desirable thing to do.

I should have made it clear that I'm not one of those many:-).
I am fully in favor of maintaining a large degree of
compatibility with C.  My impression, however, is that I am in a
minority -- Stroustrup agrees, but sometimes I get the
impression that he is very alone on this.

    [...]
> And C++ programmers should not assume that C++ is superior
> in all areas than C.  (Take the issue of NULL, for example,
> for which C has a cleaner solution.)

It does?  Your the first person I've heard express that view.
(Using the word "clean" for the current situation in either
language is an abuse, but the C++ solution seems slightly less
dirty.)

The way it looks, however, C++ will have a much cleaner solution
after the next revision.

> And finally, _both_ languages have features missing from them
> that some people feel a "complete" language should provide
> (e.g., automatic garbage collection, built-in support for
> threads, etc.).

Interesting point: in the parts I cut, you mentionned that the
language shouldn't evolve, but only the libraries.  Where as the
two points you mention cannot be handled strictly in the
library; they require language modifications.  (Ditto the
improvements in null pointer constants.)

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

No.Email@Address.ucar.edu wrote:
 >> However, your answer did not give a reason why, when an
 >> explicit initializer is not provided, the variable should be
 >> default initialized in some cases, and not initialized at all
 >> in others.

 > Answer:  Because C++ is based on C, and this feature
 > originated in C.

That is the explination of this particular case.  Arguably,
today, initialization should be required in every case.  With
today's technology, the cost would usually be very close to zero
anyway.

 > I've plenty of questions in my head to ask about the C++
 > programming language, but there isn't much point asking them
 > here because they were around since the time of C. For
 > example:

 > (Q) Why does "int" default to "signed int" rather than
 > "unsigned int"?  I've always thought it would be much more
 > natural to have "int" unsigned.

Because the name is an abbreviation for "integer", and the set
of integers includes negative numbers.  Because int was present
long before unsigned int, and changing it would have broken too
much existing code.

 > How far do you think C++ has progressed insomuch as abandoning
 > its backward compatibility with C?

I think that many people today would say: not enough.

 > I have an idea in my head: When the language is changed so
 > that it breaks existing code, would it be feesible to write a
 > little program which processes source code files to adjust the
 > code to the changes?

Usually yes.  There are probably some subtle cases, however --
the change in the scope of a variable declared in a for, or the
introduction of two phased lookup, come to mind.  (99% of the
time, these two changes result in an error.  But in both cases,
it's possible to construct code which subtly changes semantics
with the change.)

--=20
James Kanze                                    kanze.james@neuf.fr
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France +33 (0)1 30 23 00 34

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Tom=E1s wrote:
> The die was cast decades ago... but nonetheless I'd like to discuss:
>=20
> Why do global objects and also, static objects in functions, get defaul=
t=20
> initialised?

The bigger question, is why in an intelligent well thought out language
is default initialization skipped for only certain object in certain
arcane circumstances.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Ron Natalie posted:

> Tom=E1s wrote:
>> The die was cast decades ago... but nonetheless I'd like to discuss:
>>=20
>> Why do global objects and also, static objects in functions, get defau=
l
> t=20
>> initialised?
>=20
> The bigger question, is why in an intelligent well thought out language
> is default initialization skipped for only certain object in certain
> arcane circumstances.


For efficiency. Use as little resources as possible, and make it as fast =
as=20
possible. Also... it's better to be explicit about what value you want,=20
e.g.:

    static int *p =3D 0;

rather than:

    static int *p;


-Tom=E1s

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Tom   s" wrote:
> Ron Natalie posted:
..
> > The bigger question, is why in an intelligent well thought out language
> > is default initialization skipped for only certain object in certain
> > arcane circumstances.
>
>
> For efficiency. Use as little resources as possible, and make it as fast as
> possible. Also... it's better to be explicit about what value you want,
> e.g.:
>
>     static int *p = 0;
>
> rather than:
>
>     static int *p;

That doesn't really address the question. Efficiency is an argument for
providing the option of not initializing a variable. The rest of your
answer could be taken as an argument for making explicit initialization
mandatory. However, your answer did not give a reason why, when an
explicit initializer is not provided, the variable should be default
initialized in some cases, and not initialized at all in others.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

> However, your answer did not give a reason why, when an explicit
> initializer is not provided, the variable should be default
> initialized in some cases, and not initialized at all in others.=20


Answer:  Because C++ is based on C, and this feature originated in C.

I've plenty of questions in my head to ask about the C++ programming=20
language, but there isn't much point asking them here because they were=20
around since the time of C. For example:

(Q) Why does "int" default to "signed int" rather than "unsigned int"?=20
I've always thought it would be much more natural to have "int" unsigned.

How far do you think C++ has progressed insomuch as abandoning its=20
backward compatibility with C?

I have an idea in my head: When the language is changed so that it breaks=
=20
existing code, would it be feesible to write a little program which=20
processes source code files to adjust the code to the changes? For=20
instance, if we changed the syntax of the initialiser list (just a=20
hypothetical of course), the little program could change:

    int Blah::Blah(int &s) : p(5), r(22), t(s)
    {

    }

into:

    int Blah::Blah(int &s) =3D { p(5); r(22); t(s) }
    {

    }



-Tom=E1s

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

The die was cast decades ago... but nonetheless I'd like to discuss:

Why do global objects and also, static objects in functions, get default
initialised?

We're given the choice with local variables, e.g.:

    char s[65];

Versus:

    char s[65] = {};


It'd be nice to have the choice with globals and statics in functions.
Just a thought.


I suppose you could circumvent the system:

template<class T>
class DoNotInit {

    T object;

public:

    DoNotInit() {}

    /* Rather than:

       DoNotInit() : object() {}
    */


    T &operator()() { return object; }
};


void FuncInit()
{
    static char s[65];

    s[17] = '5';
};

void FuncDoNotInit()
{
    static DoNotInit<char[65]> dni;

    static char (&s)[65] = dni();

    s[17] = '5';
}


With all of C's claims of efficiency, it looks like they dropped the ball
on this one.

(One thing I'll say about C++ though: If you have a problem with the
language, you can get around it most of the time.)

-Tom   s

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Tom   s wrote:
> The die was cast decades ago... but nonetheless I'd like to discuss:
>
> Why do global objects and also, static objects in functions, get default
> initialised?
>
> We're given the choice with local variables, e.g.:
>
>     char s[65];
>
> Versus:
>
>     char s[65] = {};
>
>
> It'd be nice to have the choice with globals and statics in functions.
> Just a thought.
>
>
> I suppose you could circumvent the system:
>
> template<class T>
> class DoNotInit {
>
>     T object;
>
> public:
>
>     DoNotInit() {}
>
>     /* Rather than:
>
>        DoNotInit() : object() {}
>     */
>
>
>     T &operator()() { return object; }
> };
>
>
> void FuncInit()
> {
>     static char s[65];
>
>     s[17] = '5';
> };
>
> void FuncDoNotInit()
> {
>     static DoNotInit<char[65]> dni;
>
>     static char (&s)[65] = dni();
>
>     s[17] = '5';
> }
>
>
> With all of C's claims of efficiency, it looks like they dropped the ball
> on this one.
>
> (One thing I'll say about C++ though: If you have a problem with the
> language, you can get around it most of the time.)
>
> -Tom   s

Because space for global variables must be allocated in a program's
image - every global variable will be initialized with a specific value
at program startup. So in the interests of standardization, it makes
sense for all programs to initialize globals with the same, specific
value (0) instead of leaving each program to choose a specific value of
its own. There is certainly no incurred cost in terms of a program's
efficiency in zero-initializing global variables. Local variables, on
the other hand, re-use memory - so the initial value of a local
variable cannot be guaranteed without explicitly assigning it a value
upon allocation; so in the case of local variables, zero-initialization
would incur a cost.

In fact it is not possible to avoid zero-initialization for global
variables. The 65 character array in the static dni variable in the
sample program has in fact been zero-initialized -  no differently than
had it been declared a global array on its own. In fact, in order to
initialize a global variable with random values, the program would have
to execute an initialization routine to do so explicitly. In other
words the default zero-initialization behavior is in fact the more
efficient behavior than the behavior which the DoNotInit class template
attempts to - but fails to - attain.

Greg


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Wed, 17 May 2006 15:59:14 CST, "Tom=E1s" <No.Email@Address.ucar.edu>
wrote in comp.std.c++:

>=20
> The die was cast decades ago... but nonetheless I'd like to discuss:
>=20
> Why do global objects and also, static objects in functions, get defaul=
t=20
> initialised?

   [snip]

> With all of C's claims of efficiency, it looks like they dropped the ba=
ll=20
> on this one.

What makes you think this is all that inefficient?  Considering that C
and C++ were developed in (and primarily for) hosted environments,
where some OS mechanism copies the executable image from secondary
storage into processor memory, and generally has to do some fixing up
anyway, just how expensive do you think it is to zero out a block of
memory?

Especially when you consider that at least some operating systems zero
out all the memory accessible to a program before it begins execution,
for security reasons.  All the executable format and OS loader have to
do is not to overwrite those zeros.

On platforms where all-bits-zero is not a valid representation for a
null pointer and/or a floating point 0.0, there is more work involved,
but those are in a very small minority.

--=20
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

===================================== MODERATOR'S COMMENT:

This thread is now drifting into areas unrelated to C++ standardization.
Let's try not to drift too far into basic OS technology. -sdc


---
Steve Clamage, stephen.clamage@sun.com


===================================== END OF MODERATOR'S COMMENT
Greg Herlihy posted:

> Because space for global variables must be allocated in a program's
> image - every global variable will be initialized with a specific
> value at program startup.


I hadn't considered this. I can program in C++, but my knowledge of what
goes on under the hood is limited. I know a bit about assembly language,
but concepts like the "stack" escape me... I've tried reading up on it a
couple of times, but I find books on the topic to be quite unaccessible.
(Which is quite strange considering I can leisurely read through books
like TC++PL by Bjarne).

I know how assembly code works; it's basically just machine code written
in English. Assembly like the following:

mov ax, 34
inc qw

gets turned into hexadecimal codes:

0A EC F3 A3


Are you saying that the global and static objects get stored in the same
place as this machine code? And therefore that their value is hardcoded
in the executable, something like:

0A EC F3 A3 00 00 00 00 00 00 00

?

-Tom   s

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Tom   s wrote:
> Why do global objects and also, static objects in functions,
> get default initialised?

Because everything in C++ gets default initialized.  The only
difference with regards to static objects is that they are zero
initialized before hand.  This was doubtlessly done because it
was free on the early Unix systems -- everything was zero
initialized, whether the C language specification required it or
not, so they decided to make it a requirement.

    [...]
> With all of C's claims of efficiency, it looks like they
> dropped the ball on this one.

In what sense?  Logically, they probably should have required
the initialization everywhere, but on older machines, it can be
expensive for larger objects, so they just required it where it
was free.  (Depending on how malloc/free is implemented, larger
objects are in fact zero initialized on a lot of implementations
anyway.)

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Jack Klein wrote:
> On Wed, 17 May 2006 15:59:14 CST, "Tom=E1s" <No.Email@Address.ucar.edu>
> wrote in comp.std.c++:
>=20
>=20
>>The die was cast decades ago... but nonetheless I'd like to discuss:
>>
>>Why do global objects and also, static objects in functions, get defaul=
t=20
>>initialised?

    The embedded computer world has some issues with C++ in this area.  S=
ee

 http://www.embedded.com/98/9812/9812pp.htm

These have mainly to do with whether const C++ objects can be initialized
at compile time and placed in ROM.  In a typical deeply embedded environm=
ent,
at power-on, all the code and constants are in ROM, and all the data is r=
andom.
Anything beyond that needs to be handled in startup code.  A memory clear=
 of the
data areas has to explicitly be done before the constructors run to satis=
fy
the C++ rules.

    John Nagle

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]