Sriram Chandrasekaran wrote:
> for ex :
>=20
> void loop()
> {
>     for (int i =3D 0; i < 1000;i++)
>         func(i);
> }
>=20
> void func(int i)
> {
>     int j;
>     j =3D i;
>     //code here ....
>     .
>     .
>     .
> };
>=20
> if j is initialised to 0 , it is a waste.
>=20
Writing the function that way is a waste. Any programmer I know of would=20
write :

void func(int i)
{
     int j =3D i; // or int j(i);
     // code here ....
}

just as they would write :
void func(string s1)
{
     string  s2 =3D s1; // or string s2(s1);
     // code here ....
}

--=20
Lo=EFc

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Lo   c Joly" <loic.actarus.joly@wanadoo.fr> wrote in message news:allp19$kv3$1@wanadoo.fr...
> void func(int i)
> {
>     int j;
>     j = i;
>     //code here ....

Furthermore, if there is any reason you legitimately need to defer initialization, you can
allow it as a (non-default) option:

void func(int i) {
    auto int j;     // don't initialize.
    j = i;
}

The advantages are:

1.  If you use the old code unmodified, it does the right thing (value wise) at a slight
     performance penalty (although I can't get worked up over the extra instruction
     necessary to zero an int, a pod struct might be worse).

2.  If you need to squeeze the non-initialized version you can.   Code that is that tenuous
     on performance stuff probably needs examination anyhow when you switch implementations.

3.  The above case should work in the existing compiler now without being able to tell the difference
     (auto is a no op here).

4.  Anybody who is wierd enough to use auto now, won't see any different behavior with the
    change.




---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Dave Harris wrote:
> That's an example I'd call "fairly obscure".

That's precisely the example for which I would be forced
to pay an enormous runtime cost for a useless effect. I
don't know why you think it's obscure; among other things,
there is a ton of legacy code with automatic character
arrays which would need to be initialized in the new regime.

File this notion under no-how, no-way.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

for ex :

void loop()
{
    for (int i = 0; i < 1000;i++)
        func(i);
}

void func(int i)
{
    int j;
    j = i;
    //code here ....
    .
    .
    .
};

if j is initialised to 0 , it is a waste.

-Sri
"Lo   c Joly" <loic.actarus.joly@wanadoo.fr> wrote in message
news:akj5hu$p53$1@wanadoo.fr...
> It is usually a pain to me that if I write :
>
> class myClass
> {
>    int a;
>    myOtherClass b;
> };
>
> Then b is a well defined value whereas the value of a is not defined.
> My intuitive understanding of C++ (I know intuitive and C++ in the same
> sentance is often a source of error ;)) would be that something similar
> to default constructor existed for basic type.
>
> It is a point where C compatibility is not a problem, because C++
> behaviour would only be stricter.
>
> So my question is why is this behaviour the current one ? Does it have
> to do with performancs ? If it is so, has it been proven to have a real
> impact on real programs ?
>
> --
> Lo   c
>
> ---
> [ 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.jamesd.demon.co.uk/csc/faq.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.jamesd.demon.co.uk/csc/faq.html                       ]

hyrosen@mail.com (Hyman Rosen) wrote (abridged):
> > Although with a reasonable optimiser, examples must be fairly obscure.
>
> Not at all. For example, I may have a bounded stack with room
> for a certain number of elements, with an internal representation
> using an array of elements. Initializing that array would be
> completely useless, and I doubt any optimiser would deem it not
> necessary.

That's an example I'd call "fairly obscure". For simple cases, like:

    void proc() {
        int x; // Implicit = 0.
        x = 1;
    }

the compiler ought to optimise away the implicit assignment.

Where initialisation is needed, the compiler can often do it cheaper than
user code. This is partly because it can find more economies of scale, and
partly because the system will often provide nulls "for free", having
prepared them in advance in an idle loop. So the efficiency issue is not
clear-cut.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Lawrence Rust" <lvr@nospam.softsystem.co.uk> wrote in message
news:Srob9.962$gH4.37208@newsfep2-gui...

> Why not allow the syntax:
>
> class myClass {
>   int a = <compile time constant>;
>   myOtherClass b;
> };
>
> I believe this has been proposed before but I don't have a reference.
>
> The construction sequence could be expanded to initialise these members
just
> before the initialisation list in the selected constructor is executed.
Is
> there a good reason not to permit this?

But why is it necessary?  The reason that objects that have constructors is
for just such a need - the need to initialize member variables.  It only
saves typing the variable name and a semi-colon once.  And it now moves
construction out of the constructor.  I don't think it's a good trade-off.

As far as the original question is concerned, I object to the performance
issues present in default construction of the inherent types.  Default
construction in STL containers would noticeably degrade my performance.  I
deal with a large volume of data that is usually of one or two simple
classes that have no good, single default representations.  And the default
of 0 for its members would be deadly (i.e. crash), unlike almost any
non-zero value.  For me then, the proposed default values for integers and
floats will cause my program to run slower without adding any benefit
whatsoever.  I like the rule as it stands.


-- Noah


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis wrote:
> Lo   c Joly <loic.actarus.joly@wanadoo.fr> writes:
>
> | Well, for some basic type, a reasonable default value exists. I do not
> | ask for a perfect value, justs for something reasonable. For example,
> | std::string has an arbitrary default value, but it is fine for me, even
> | if I write a program where most of the string are initialized to "Hello
> | world!".
>
> One thing to consider is that different reasonable people have
> different reasonable ideas of what a reasonable default value should
> be.

Yes, but some default value has already been defined with the
default-constructor-syntax T().

>
> | NaN for types where NaN is an acceptable value
>
> The traditional data type for which NaN has a meaning are floating
> point types -- and usually a signaling NaN is used to indicate that a
> datum is -not- given a value and therefore inappropriate as operand.
> The effect of using a NaN (quiet or signaling) is undefined in C++.
>
> I do not think that NaN (Not a Number) is a reasonable default value,
> especially when the value given by the default-constructor-syntax T() is
> well-defined.

I totally agree with you on this point, it was a mistake on my part to
propose NaN since T() is defined. I must have been half asleep when I
wrote it ;)

--
Lo   c

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Lo   c Joly <loic.actarus.joly@wanadoo.fr> wrote in message news:<akoetl$h1p$1@wanadoo.fr>...
> Francis Glassborow wrote:
> > In article <akm8j4$idl$1@wanadoo.fr>, Lo   c Joly
> > <loic.actarus.joly@wanadoo.fr> writes
> > [Why no default initialisation of basic types]
>
> > Do you understand why we have the present rule? Statics are default
> > initialised because that is cost free at execution time (they are loaded
> > with the required value). Non-statics (locals, parameters and instance
> > variables) are not default initialised because doing so costs both in
> > code size and execution time.
>
> Well, I do not understand the present rule (that is why I post...). More
> precisely, I do not see the difference between a basic type and a class
> in your sentence. I could say : Non-statics (locals, parameters and
> instance variables) instances of classes are not default initialised
> because doing so costs both in code size and execution time.
>
> > If I have a decision to make as to what
> > value to use for initialisation, why should I first pay the cost of a
> > default initialisation?
>
> void setValue (std:complex<double> &cplx);
>
> void g()
> {
>    std::complex<double> myComplex;
>    setValue(myComplex);
> }
>
> In this case, I had to pay the cost of a default initialisation, even if
> I did not need it.

I wonder, if you are really bugged about the cost of the default init,
can't you use a pointer and create the correctly initialized
complex<double> inside your setValue routine .. now declared as:

void setValue (std::complex<double> *cplx);

Or does this have its own drawbacks?  It seems like it should reduce
code size while keeping runtime speed about equal, but I am not
completely sure.  I guess there is the consideration of having to
delete the pointer later on?  Hmm, just some more questions that came
to mind while reading this thread ... sorry for the drift.

Dave Moore

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

> Lawrence Rust <lvr@nospam.softsystem.co.uk> writes
> >Why not allow the syntax:
> >
> >class myClass {
> >  int a = <compile time constant>;
> >  myOtherClass b;
> >};
> >
> >The construction sequence could be expanded to initialise these members just
> >before the initialisation list in the selected constructor is executed.  Is
> >there a good reason not to permit this?

Francis Glassborow <francis.glassborow@ntlworld.com> wrote
> I think that is the wrong question. Is there a good reason to allow it?

I can think of one. It's about convenience.

"Syntactical Sugar" is a phrase I've sometimes heard bandied about,
usually to explain why some feature is NOT useful. For instance,
I've heard people say that references are just "syntactical sugar"
on top of pointers. The truth is, when something ought to be done,
there is value in writing it once instead of repeatedly.

I suppose my vision for this proposal is slightly different than the
one Mr. Rust envisioned. It looks to me like he wanted to have two
different phases of initialization; first the ones that are listed in
the class, then the ones in the constructor.

A better way to go would be to use these values as DEFAULTS for the
(one and only phase of) initialization lists.

    struct foo {
       int a=5, b=8, c;                        // #1
       foo()             :       b(2), c(3) {} // #2
       explicit foo(int) : a(1),       c(3) {} // #3
       explicit foo(bar) : a(1), b(2)       {} // #4
    };

The default constructor #2 does not specify a value for a, so the
value 5 specified at #1 is used. It does specify a value for b, so
this is used instead of the value 8. The constructor is therefore
exactly equivalent to:
       foo()             : a(1), b(2), c(3) {} // #5

Similarly for the int constructor #3, which initializes a with 1
and allows b to initialize with 8.

For classes with only one constructor, the only reason to consider
doing it this way is readability. It seems to me that this:

    struct complicated1 {
        comp1 member1;
        comp2 member2;
        comp3 member3;
        comp4 member4;
        comp5 member5;
        comp6 member6a, member6b;
        comp7 member7;
        complicated1()
            : member1(arg1)
            , member2(arg2a, arg2b)
            , member3(arg3)
            , member4(arg4)
            , member5(arg5)
            , member6a(arg6)
            , member6b(arg6)
            , member7(arg7)
            { }
    };

is harder to read and more error prone than this:

    struct complicated2 {
        comp1 member1 = arg1;
        comp2 member2 = comp2(arg2a,arg2b);
        comp3 member3 = arg3;
        comp4 member4 = arg4;
        comp5 member5 = arg5;
        comp6 member6a = arg6, member6b = arg6;
        comp7 member7 = arg7;
        complicated2() {}
    };

My version isn't without it's problems. Look at how I initialized
member2 -- is this how it ought to work? But if this (minor?) hurdle
can be overcome, I think it might prove worthwhile.

> Remember that we cannot just place it before the start of the normal
> ctor/init list because that has very specific order semantics. We
> already have perfectly satisfactory initialisation mechanisms through
> default ctors (and for cases like this, implicitly inline them if you
> need the speed).

You're right -- what we already have is clearly good enough, and having
a two-phased initialization would not be a good idea for many reasons.

This change would be a notational syntax only; "say it with code."
When a data member should (almost) ALWAYS be initialized the same way,
might as well say so at the point of declaration.

> Allowing this proposal would just add another point that would have to
> be covered in learning the language. And why require a compile time
> constant?

To keep it simple, perhaps. I can imagine cases like

    int g, h, i, j;
    struct bar {
       int a=g*h, b=a+22;
       bar() : a(i*j) {}
    };

What exactly would b be initialized with?

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Dave Harris wrote:
> Although with a reasonable optimiser, examples must be fairly obscure.

Not at all. For example, I may have a bounded stack with room
for a certain number of elements, with an internal representation
using an array of elements. Initializing that array would be
completely useless, and I doubt any optimiser would deem it not
necessary.

And as Ada has discovered in a number of cases, it is a design
error to fail to provide a means of accomplishing something in
the expectation that an optimiser will detect the situation and
do it for you.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Hi,

> A better way to go would be to use these values as DEFAULTS for the
> (one and only phase of) initialization lists.

>     struct foo {
>        int a=3D5, b=3D8, c;                        // #1
>        foo()             :       b(2), c(3) {} // #2
>        explicit foo(int) : a(1),       c(3) {} // #3
>        explicit foo(bar) : a(1), b(2)       {} // #4
>     };

> The default constructor #2 does not specify a value for a, so the
> value 5 specified at #1 is used. It does specify a value for b, so
> this is used instead of the value 8. The constructor is therefore
> exactly equivalent to:
>        foo()             : a(1), b(2), c(3) {} // #5

> Similarly for the int constructor #3, which initializes a with 1
> and allows b to initialize with 8.

> For classes with only one constructor, the only reason to consider
> doing it this way is readability. It seems to me that this:

>     struct complicated1 {
>         comp1 member1;
>         comp2 member2;
>         comp3 member3;
>         comp4 member4;
>         comp5 member5;
>         comp6 member6a, member6b;
>         comp7 member7;
>         complicated1()
>             : member1(arg1)
>             , member2(arg2a, arg2b)
>             , member3(arg3)
>             , member4(arg4)
>             , member5(arg5)
>             , member6a(arg6)
>             , member6b(arg6)
>             , member7(arg7)
>             { }
>     };

> is harder to read and more error prone than this:

>     struct complicated2 {
>         comp1 member1 =3D arg1;
>         comp2 member2 =3D comp2(arg2a,arg2b);
>         comp3 member3 =3D arg3;
>         comp4 member4 =3D arg4;
>         comp5 member5 =3D arg5;
>         comp6 member6a =3D arg6, member6b =3D arg6;
>         comp7 member7 =3D arg7;
>         complicated2() {}
>     };

Of course, thre can be different opinions. But I would like to add a=20
thought:

Most times, constructor definitions, especially of complex=20
classes/structs,
are in a different file than the class declaration.
So it makes things harder to ensure that I initialised really every=20
member of the
class. I might assume, this was done in the header file, but that was=20
changed
later and now my constructor implementations become invalid.

I use an idiom, to list every(!) member of a class in each c'tor's=20
initialiser list,
even those with own default c'tors =96 so I can be sure, if a member does=
=20
not=20
appear there, it is always an error. This helps much in never forgetting
initialisation of a member. Having this idiom present, that additional
default values in the header wouldn't be necessary anyway.

Last not least, default values in the header make even more=20
implementation=20
details public than C++ already does. Another reason I wouldn't like it.


Regards,
Nikolai






---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
> In article <akm8j4$idl$1@wanadoo.fr>, Lo   c Joly
> <loic.actarus.joly@wanadoo.fr> writes
> [Why no default initialisation of basic types]

> Do you understand why we have the present rule? Statics are default
> initialised because that is cost free at execution time (they are loaded
> with the required value). Non-statics (locals, parameters and instance
> variables) are not default initialised because doing so costs both in
> code size and execution time.

Well, I do not understand the present rule (that is why I post...). More
precisely, I do not see the difference between a basic type and a class
in your sentence. I could say : Non-statics (locals, parameters and
instance variables) instances of classes are not default initialised
because doing so costs both in code size and execution time.

> If I have a decision to make as to what
> value to use for initialisation, why should I first pay the cost of a
> default initialisation?

void setValue (std:complex<double> &cplx);

void g()
{
   std::complex<double> myComplex;
   setValue(myComplex);
}

In this case, I had to pay the cost of a default initialisation, even if
I did not need it.

> This is all part of the philosophy of 'don't pay for what you don't use'
> and 'trust the other programmer' (derived from C's 'trust the programmer')

I roughly agree with this philosophy, but I also agree to another
philosophy wich promotes consistency and avoidance of special cases.

--
Lo   c

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Nicola Musatti" <Nicola.Musatti@objectway.it> wrote...
>
>
> Lo   c Joly wrote:
> >
> > It is usually a pain to me that if I write :
> >
> > class myClass
> > {
> >    int a;
> >    myOtherClass b;
> > };
> >
> > Then b is a well defined value whereas the value of a is not defined.
> > My intuitive understanding of C++ (I know intuitive and C++ in the same
> > sentance is often a source of error ;)) would be that something similar
> > to default constructor existed for basic type.
>
> Let's keep performance related considerations aside. There still is a
> big difference in terms of design; you designed the myOtherClass class
> and presumably you know what is the correct initial value for that
> class. On the other hand, what is a reasonable default value for an int?
> There is no single reasonable choice for all programs.

Why not allow the syntax:

class myClass {
  int a = <compile time constant>;
  myOtherClass b;
};

I believe this has been proposed before but I don't have a reference.

The construction sequence could be expanded to initialise these members just
before the initialisation list in the selected constructor is executed.  Is
there a good reason not to permit this?

-- Lawrence Rust, Software Systems, www.softsystem.co.uk
The problem with Windows XP: http://www.arachnoid.com/boycott

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Lo   c Joly wrote:
>
> I truely believe that for all basic types that have a special value
> defined in the language, that value should be used as a default value :
>
[...]

And of course, as I just remembered, reading Andrea Griffini's post, I
totally forgot that default values for basic type were already defined
in some circonstances...

So please, forget my previous post, and just read Andrea Griffini's one. ;)


--
Lo   c

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Lo   c Joly <loic.actarus.joly@wanadoo.fr> writes:

| Well, for some basic type, a reasonable default value exists. I do not
| ask for a perfect value, justs for something reasonable. For example,
| std::string has an arbitrary default value, but it is fine for me, even
| if I write a program where most of the string are initialized to "Hello
| world!".

One thing to consider is that different reasonable people have
different reasonable ideas of what a reasonable default value should
be.

| NaN for types where NaN is an acceptable value

The traditional data type for which NaN has a meaning are floating
point types -- and usually a signaling NaN is used to indicate that a
datum is -not- given a value and therefore inappropriate as operand.
The effect of using a NaN (quiet or signaling) is undefined in C++.

I do not think that NaN (Not a Number) is a reasonable default value,
especially when the value given by the default-constructor-syntax T() is
well-defined.

| '\0' for char (This char is a special value for many C-inherited
| "string" functions)
|
| I agree that for types like bool or int, a genuine default value is
| harder to choose (though not has hard, I believe, as for std::string or
| std::vector), but some arbitrary values like false or 0  might be used.

If you beleive that NaN (e.g. a trap representation) is a reasonable
default value for floating point types, why the same can't apply for
bool or int, e.g. reading an uninitialized datum of such a type is
undefined behaviour?  After all, they are just as fundamental as
floating point types.


--
Gabriel Dos Reis                    gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <Srob9.962$gH4.37208@newsfep2-gui>, Lawrence Rust
<lvr@nospam.softsystem.co.uk> writes
>Why not allow the syntax:
>
>class myClass {
>  int a = <compile time constant>;
>  myOtherClass b;
>};
>
>I believe this has been proposed before but I don't have a reference.
>
>The construction sequence could be expanded to initialise these members just
>before the initialisation list in the selected constructor is executed.  Is
>there a good reason not to permit this?

I think that is the wrong question. Is there a good reason to allow it?
Remember that we cannot just place it before the start of the normal
ctor/init list because that has very specific order semantics. We
already have perfectly satisfactory initialisation mechanisms through
default ctors (and for cases like this, implicitly inline them if you
need the speed).

Allowing this proposal would just add another point that would have to
be covered in learning the language. And why require a compile time
constant?


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

It is usually a pain to me that if I write :

class myClass
{
   int a;
   myOtherClass b;
};

Then b is a well defined value whereas the value of a is not defined.
My intuitive understanding of C++ (I know intuitive and C++ in the same
sentance is often a source of error ;)) would be that something similar
to default constructor existed for basic type.

It is a point where C compatibility is not a problem, because C++
behaviour would only be stricter.

So my question is why is this behaviour the current one ? Does it have
to do with performancs ? If it is so, has it been proven to have a real
impact on real programs ?

--
Lo   c

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Lo   c Joly wrote:
 > Does it have to do with performancs ?
 > If it is so, has it been proven to have a real
> impact on real programs ?

Yes, and yes.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Lo   c Joly wrote:
>
> It is usually a pain to me that if I write :
>
> class myClass
> {
>    int a;
>    myOtherClass b;
> };
>
> Then b is a well defined value whereas the value of a is not defined.
> My intuitive understanding of C++ (I know intuitive and C++ in the same
> sentance is often a source of error ;)) would be that something similar
> to default constructor existed for basic type.

Let's keep performance related considerations aside. There still is a
big difference in terms of design; you designed the myOtherClass class
and presumably you know what is the correct initial value for that
class. On the other hand, what is a reasonable default value for an int?
There is no single reasonable choice for all programs.

Cheers,
Nicola Musatti

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On 29 Aug 2002 12:05:00 GMT, Nicola Musatti
<Nicola.Musatti@objectway.it> wrote:

....
>Let's keep performance related considerations aside. There still is a
>big difference in terms of design; you designed the myOtherClass class
>and presumably you know what is the correct initial value for that
>class. On the other hand, what is a reasonable default value for an int?
>There is no single reasonable choice for all programs.

I don't agree at all: other parts of the language already
made this choice. For example when you write int() you get
an initializated integer with value 0, or if you declare a
global variable of type int the value assigned to it is 0.
So there's already a value (0) that plays a special role
for integers like for example another special value (the
null pointer) does for pointers.

Andrea

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

hyrosen@mail.com (Hyman Rosen) wrote (abridged):
>  > Does it have to do with performancs ?
>  > If it is so, has it been proven to have a real
> > impact on real programs ?
>
> Yes, and yes.

Although with a reasonable optimiser, examples must be fairly obscure.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Nicola Musatti wrote:
>
> Lo   c Joly wrote:
>
>>My intuitive understanding of C++ (I know intuitive and C++ in the same
>>sentance is often a source of error ;)) would be that something similar
>>to default constructor existed for basic type.
>
>
> Let's keep performance related considerations aside. There still is a
> big difference in terms of design; you designed the myOtherClass class
> and presumably you know what is the correct initial value for that
> class. On the other hand, what is a reasonable default value for an int?
> There is no single reasonable choice for all programs.

Well, for some basic type, a reasonable default value exists. I do not
ask for a perfect value, justs for something reasonable. For example,
std::string has an arbitrary default value, but it is fine for me, even
if I write a program where most of the string are initialized to "Hello
world!".

I truely believe that for all basic types that have a special value
defined in the language, that value should be used as a default value :

NULL for pointers (delete NULL is special)
NaN for types where NaN is an acceptable value
'\0' for char (This char is a special value for many C-inherited
"string" functions)

I agree that for types like bool or int, a genuine default value is
harder to choose (though not has hard, I believe, as for std::string or
std::vector), but some arbitrary values like false or 0  might be used.
This might not be perfect values in all applications, but it is IMHO
better than undefined behaviour (especially when this undefined
behaviour cannot be detected at compile time, even by kindest of the
compilers).

--
Lo   c

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <akm8j4$idl$1@wanadoo.fr>, Lo   c Joly
<loic.actarus.joly@wanadoo.fr> writes
>Well, for some basic type, a reasonable default value exists. I do not
>ask for a perfect value, justs for something reasonable. For example,
>std::string has an arbitrary default value, but it is fine for me, even
>if I write a program where most of the string are initialized to "Hello
>world!".
>
>I truely believe that for all basic types that have a special value
>defined in the language, that value should be used as a default value :
>
>NULL for pointers (delete NULL is special)
>NaN for types where NaN is an acceptable value
>'\0' for char (This char is a special value for many C-inherited
>"string" functions)

Do you understand why we have the present rule? Statics are default
initialised because that is cost free at execution time (they are loaded
with the required value). Non-statics (locals, parameters and instance
variables) are not default initialised because doing so costs both in
code size and execution time. If I have a decision to make as to what
value to use for initialisation, why should I first pay the cost of a
default initialisation?

This is all part of the philosophy of 'don't pay for what you don't use'
and 'trust the other programmer' (derived from C's 'trust the
programmer')


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]