On 05 Mar 99 16:42:57 GMT, Christopher Eltschka

>- You can have pointers to embeddings.
>- You can derive embeddings from normal classes.
>- You can have embedding not only in classes, but also in
>  functions; together with derivation, this allows you
>  to access the function scope from outside.

OK.  I gave an example of how namespaces within classes could be
useful.  Please give me an example of where embeddings could be
useful.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Siemel Naran wrote:
>   class X {
>      public: // was private
>         const int x;
>         struct Silly { int f() const { return +x; } } // was namespace
>         struct Smart { int f() const { return -x; } } // was namespace
>      public:
>         explicit X(int x_) : x(x_) { }
>         int action() const { return Silly::f()+Smart::f(); }
>   };
>
>> The call "Silly::f()" is a syntax error because you are calling a
>> member function without an object.

David R Tribble <dtribble@technologist.com> wrote:
>> If you want a function that doesn't have a 'this' pointer, make it
>> static.  Then the class encloses a set of static-only functions,
>> which makes it act more like a namespace.  Sheesh.

Siemel Naran wrote:
> You don't get it.  I want Class::Silly::f to have a "this" pointer!
> Which means that it can't be a static function or a function inside a
> class. There are two funcs, Class::Silly::f and Class::Smart::f.
> Both must be able to see the variables Class::var1, Class::var2, etc.
>
> This is the whole point of namespace within classes.

Apologies, I get it now.

But what does having the names Silly::f and Smart::f buy you that
having the names Silly_f and Smart_f don't?  I.e., what are you
going to put into the namespace(s) that you wouldn't put into a
nested class or simply apply a name prefix to?

-- David R. Tribble, dtribble@technologist.com --
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7bhtlb$og2$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com
says...

[ ... ]

> The same thing ought to happen with
> uninitialized auto variables.
>
>     int myInt;                // Warning: myInt not initialized.
>     std::cout << "myInt is "
>         << myInt              // Don't say we didn't warn you!
>         << std::endl;

Do you mean something like this (from MSC):

warning C4700: local variable 'myInt' used without having been
initialized

Or do you prefer this one (from egcs):

warning.cpp: In function `int main()':
warning.cpp:4: warning: `int myInt' might be used uninitialized in
this function

MS has even gone far enough now, that you don't have to enable
optimization to get this warning when appropriate -- that's nice,
given that many people DON'T routinely turn on optimization until
rather late in a development cycle, and it's generally best to catch
things like this as early as possible.  It's also counterintuitive to
many that some warnings don't happen until or unless you turn on
optimization.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sbnaran@fermi.ceg.uiuc.edu (Siemel Naran) wrote:
>> I find this dichotomy between builtin variables and STL variables to
>> be positively annoying.

Julian Pardoe wrote:
> I agree!  The "STL variables" (complex<int> in your example) shouldn't
> be set to any well-defined value.  (If the type were complex<double>
> I'd be pleased if they were set to NaN.)  If your code relies on an
> initial value you should provide one explicitly.  And having the
> class/compiler pick a "normal" value like 0 is asking for
> "uninitialized variable" bugs to go unnoticed.  (My favourite example
> is the date class that is initialized to "today" by default.  What
> other value is more likely to pass any validation tests or slip past a
> human tester undetected?)

So you're arguing that it's better to "initialize" variables to
garbage than to predictable values, and that this somehow leads to
less bugs?  In other words, you're relying on all that testing to
catch variables initialized to garbage, but this testing wouldn't
catch variables initialized to "incorrect" values?

-- David R. Tribble, dtribble@technologist.com --
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 04 Mar 99 18:26:57 GMT, David R Tribble <dtribble@technologist.com> wrote:

>But what does having the names Silly::f and Smart::f buy you that
>having the names Silly_f and Smart_f don't?  I.e., what are you
>going to put into the namespace(s) that you wouldn't put into a
>nested class or simply apply a name prefix to?

I can use using-directives.
   void X::silly() { using namespace /*X::*/Silly; ...  };
   void X::smart() { using namespace /*X::*/Smart; ...  };
It's neat, but is it useful?

IMHO, not that useful.  But here's an example of where it might be
used.  I write an algorithm that has a step1 (bracketing) and a step2
(bisection).  This algorithm uses a calculator object that supplies
parameters and traits for step1 and step2.  (My definition of trait:
static const variables, nested classes, nested typedefs.)
   template <class Calculator>
   class rootfind { public: explicit rootfind(const Calculator&); ... };

A calculator class might look like this
   class TheWave { namespace bracket { ... }; namespace bisection { ... } };
Namespace TheWave::bracket provides parameters and functions relating
to the bracketing step (step1).  Similar remarks apply for
TheWave::bisection.  These namespaces will have lots of variable
names in common (eg: TOL, Ncount).

So member functions of class rootfind<Calc> can say
   using Calculator::bracket;
   using Calculator::bisection;

I'll admit that in my example, namespaces within classes don't solve
big problems.  But the feature seems like it would be trivial to
implement, and I can't see any problems that might arise, so why not
have it?

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 3 Mar 1999 16:52:10 GMT, Christopher Eltschka

>The "embedding" I proposed there would give you - besides
>other things - the functionality you want (with only slightly
>different syntax). [Note that in earlier postings, I've called
>that "embedded class"; However, it has some similarity to
>namespaces - enough for Petter Urkedal to suggest the name
>"local namespace" or "embedded namespace" for it.

Why invent a new keyword "embedding" when "namespace" along
with good old using-declarations could be used?

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Siemel Naran wrote:
>
> On 3 Mar 1999 16:52:10 GMT, Christopher Eltschka
>
> >The "embedding" I proposed there would give you - besides
> >other things - the functionality you want (with only slightly
> >different syntax). [Note that in earlier postings, I've called
> >that "embedded class"; However, it has some similarity to
> >namespaces - enough for Petter Urkedal to suggest the name
> >"local namespace" or "embedded namespace" for it.
>
> Why invent a new keyword "embedding" when "namespace" along
> with good old using-declarations could be used?

Because an embedding is _not_ just a namespace, as my
examples (and even more, the discussion I mentioned)
showed. It gives you the functionality of namespace
(minus using), but it gives you much more:

- You can have pointers to embeddings.
- You can derive embeddings from normal classes.
- You can have embedding not only in classes, but also in
  functions; together with derivation, this allows you
  to access the function scope from outside.

An emedding is somewhere between namespace and class. It has
some namespace features, and it has some class features.
It's different enough to namespaces to be named differently.
Indeed, IMHO the differences to namespaces are greater than
the differences to classes. However, the features you
seem to want from local namespaces are there: Access to
members of the surrounding class, and introducing a different
scope (which can be accessed explicitly through a name).
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Siemel Naran wrote:
>
> On 27 Feb 1999 15:57:08 GMT, Francis Glassborow
> >Siemel Naran
>
> >>But if 'Silly' and 'Smart' were nested classes, then they could
> >>not see X::x.
> >
> >Sure they can see it but do not have access.  So make the nested classes
> >friends (an example of friendship with which I have little problem)
>
> Friendship has nothing to do with anything.  A nested class is just
> a type.  A type does not have a "this" pointer.  Re-consider my
> example, where I've made 'Silly' and 'Smart' nested classes, and made
> the whole thing public, just for simplicity.
>
>   class X {
>      public: // was private
>         const int x;
>         struct Silly { int f() const { return +x; } } // was namespace
>         struct Smart { int f() const { return -x; } } // was namespace
>      public:
>         explicit X(int x_) : x(x_) { }
>         int action() const { return Silly::f()+Smart::f(); }
>   };
>
> The call "Silly::f()" is a syntax error because you are calling a
> member function without an object.

If you want a function that doesn't have a 'this' pointer, make it
static.  Then the class encloses a set of static-only functions,
which makes it act more like a namespace.  Sheesh.

-- David R. Tribble, dtribble@technologist.com --


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
>
> James Kuyper wrote:
...
> > A keyword to turn on default initialization wouldn't have that
> > problem, but is also not needed:
> >         default_initialize int arr[200];
> >
> > could be written right now as:
> >         int arr[200]={0};
> >
> > The key problem, of course, is template type parameters and typedefs,
> > ...
>
> The key problem is that programmers don't bother to write the
> '={0}' today, which is the whole point of mandating that the
> compiler do it for you.

Actually, we do it pretty often in my group, and our compiler gives us a
"variable used before initialized" warning if we forget.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 2 Mar 1999 09:13:08 GMT, David R Tribble <dtribble@technologist.com> wrote:
>Siemel Naran wrote:

>> The call "Silly::f()" is a syntax error because you are calling a
>> member function without an object.
>
>If you want a function that doesn't have a 'this' pointer, make it
>static.  Then the class encloses a set of static-only functions,
>which makes it act more like a namespace.  Sheesh.

You don't get it.  I want Class::Silly::f to have a "this" pointer!
Which means that it can't be a static function or a function inside a class.
There are two funcs, Class::Silly::f and Class::Smart::f.
Both must be able to see the variables Class::var1, Class::var2, etc.

This is the whole point of namespace within classes.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn7cm3ug.ddd.sbnaran@fermi.ceg.uiuc.edu>,
sbnaran@fermi.ceg.uiuc.edu (Siemel Naran) wrote:

> I find this dichotomy between builtin variables and STL variables to
> be positively annoying.

I agree!  The "STL variables" (complex<int> in your example) shouldn't
be set to any well-defined value.  (If the type were complex<double> I'd
be pleased if they were set to NaN.)  If your code relies on an
initial value you should provide one explicitly.  And having the
class/compiler pick a "normal" value like 0 is asking for "uninitialized
variable" bugs to go unnoticed.  (My favourite example is the date class
that is initialized to "today" by default.  What other value is more
likely to pass any validation tests or slip past a human tester
undetected?)

-- jP --
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <36DB21B6.F4D7EB85@technologist.com>,
  David R Tribble <dtribble@technologist.com> wrote:
> Ah, the first good objection to the idea.  I predict a 1%-3%
> slowdown in code execution speed on 97% of existing code due to the
> additional initialization.  Note that this is closer to 0% on
> systems that already intialize auto variables for you (such as AIX,
> which sets auto/stack words to 0xDEADBEEF upon function entry).
...
> > A keyword to turn on default initialization wouldn't have that
> > problem, but is also not needed:
> >         default_initialize int arr[200];
> >
> > could be written right now as:
> >         int arr[200]={0};
> >
> > The key problem, of course, is template type parameters and typedefs,
> > ...
>
> The key problem is that programmers don't bother to write the
> '={0}' today, which is the whole point of mandating that the
> compiler do it for you.

If the problem is that programmers *could* solve the problem
themselves, but often *forget* to do so, then a new warning
message would be appropriate.

How many compilers will let you write this:

    if (myInt=0) std::cout << "myInt is zero!" << std::endl;

without a warning? The same thing ought to happen with
uninitialized auto variables.

    int myInt;                // Warning: myInt not initialized.
    std::cout << "myInt is "
        << myInt              // Don't say we didn't warn you!
        << std::endl;

----
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Siemel Naran wrote:
>
> On 2 Mar 1999 09:13:08 GMT, David R Tribble <dtribble@technologist.com> wrote:
> >Siemel Naran wrote:
>
> >> The call "Silly::f()" is a syntax error because you are calling a
> >> member function without an object.
> >
> >If you want a function that doesn't have a 'this' pointer, make it
> >static.  Then the class encloses a set of static-only functions,
> >which makes it act more like a namespace.  Sheesh.
>
> You don't get it.  I want Class::Silly::f to have a "this" pointer!
> Which means that it can't be a static function or a function inside a class.
> There are two funcs, Class::Silly::f and Class::Smart::f.
> Both must be able to see the variables Class::var1, Class::var2, etc.
>
> This is the whole point of namespace within classes.

Perhaps you should look on the diskussion between Petter Urkedal
and me, in the thread "closures and properties" in comp.std.c++.

The "embedding" I proposed there would give you - besides
other things - the functionality you want (with only slightly
different syntax). [Note that in earlier postings, I've called
that "embedded class"; However, it has some similarity to
namespaces - enough for Petter Urkedal to suggest the name
"local namespace" or "embedded namespace" for it.

Example of embeddings:

class Class
{
public:
  embedding Silly_embedding
  {
    void f();
  } Silly;
  embedding Smart_embedding
  {
    void f();
  } Smart;
  // ...
private:
  int i;
};

void Class::Silly_embedding::f()
{
  ++i; // This is Class::i
}

void foo()
{
  Class x;
  x.Silly.f();
  x.Smart.f();

  void (Class::*f)() = &Class::Silly_embedding::f;
    // Members of the embedding are class members!

  // f=&Class::f; doesn't work: No Class::f exists

  Class::Silly_embedding& s = Class.Silly;
    // You can anyway treat the embedding as a class;
    // in that case, pointers really point to Class, but the
    // access is only to Silly_embedding members - similar
    // to base class pointers. Here, the similarity to namespaces
    // breaks down completely - it looks exactly like a class
    // without accessible constructors.

  s->f(); // same as x.Silly.f(); x.i gets incremented
}


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> Benjamin Scherrey wrote:
> > The (very good) reason that built-in types aren't is so when you do
> > this:
> >         unsigned long BigArray[1000000];
> >
> > ...you don't pay for 1000000 constructor/initialization calls. Of
> > course, if you declare that BigArray (or anything else) as static, it
> > does get initialized to zero (or its equivalent). Naturally, however,
> > you only get one of those.

In article <36D4A4FC.8651EC0F@technologist.com>,
  David R Tribble <dtribble@technologist.com> wrote:
> I've argued for default initialization of (auto) built-in types
> on this newsgroup before, and the only real objection was the same
> one that Benjamin gave above.  My response was to allow a language
> feature so that the programmer could explicitly specify that he
> doesn't want default initialization; after all, the example above
> is fairly rare, and most programmers probably wouldn't mind if
> their local variables were initialized for them.

We already have the ability to specify initialized or
uninitialized, but the syntax is the opposite of what you
want.

> So we could have something like and empty initializer-list to
> explicitly specify that no default initialization is to occur:
>
>     void foo()
>     {
>         double   bigArr[100000] = {};   // Is not initialized
>         double   small[20];             // Is initialized
>         ...
>     }

This would be inconsistent. Consider:
    // Specifies first 3 values, rest default to 0.0
    double array3[100] = {3.3, 2.2, 1.1};

    // Specifies first 2 values, rest default to 0.0
    double array2[100] = {2.2, 1.1};

    // Specifies first 1 values, rest default to 0.0
    double array1[100] = {1.1};

    // Specifies no values, rest default to 0.0
    double array1[100] = {}; // Whoops! Nothing initialized!

Besides, the current syntax *does* allow the programmer to
choose between initialized and not initialized. The only
differences between this and what you want are
 1) The "default" and "explicit" cases are backwards, and
 2) When initializing, at least one value must be specified.

    void bar()
    {
        double bigArr[1000000];   // Not initialized
        double small[20] = {0.0}; // *ALL 20* elements initialized to 0.0
        ...
    }

----
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 25 Feb 1999 21:53:14 GMT, Steve Clamage <stephen.clamage@Eng.sun.com> wrote:

>Speaking of which, what programming problem is solved by allowing
>namespaces in classes that is not solved equally well by using
>nested classes or sets of classes in a namespace?

The advantage of namespaces within classes is that entities in the
outer namespace are accessible in the enclosing namespace.  Eg,

   class X {
      private:
         const int x;
         namespace Silly { int f() const { return +x; } }
         namespace Smart { int f() const { return -x; } }
      public:
         explicit X(int x_) : x(x_) { }
         int action() const { return Silly::f()+Smart::f(); }
   };

But if 'Silly' and 'Smart' were nested classes, then they could
not see X::x.

I don't think namespaces in classes solve any urgent problems.
Classes are usually compact enough that they don't need to be
partitioned into namespaces.  But every once in a while, it
happens that we want two entities with the same name, and
namespaces would be great help here.  I still can't think of
any specific problem that could arise.  Anyway, I can use this
substitute:

   class X {
      private:
         const int x;
         int Silly_f() const { return +x; }
         int Smart_f() const { return -x; }
      public:
         explicit X(int x_) : x(x_) { }
         int action() const { return Silly_f()+Smart_f(); }
   };

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Al Stevens wrote:
>
> >   But in C++, you can and should initialize
> >   variables when you declare them.
>
> Should? Surely you aren't suggesting that all local variables need
> initialization?
>
> {
>     int x;
>     FillMyInt(&x);
>     // ...
> }
>
> Auto initialization of x would add unnecessary overhead.

May be one should allow an "extended initializer" for POD types,
maybe with a syntax like this:

{
  int x: { FillMyInt(&x); };
  // ...
}

const variables could be made non-const inside the extended
initializer. That is, you could write f.ex.

  int const x: { change(x); /* Ok, x is non-const here */ };
  change(x); // Error: x is const here

If you really want a POD uninitialized, you could write it
like this:

  int x: {}; // Empty extended initializer: Do nothing to init x

This extended initializer probably doesn't make sense for non-POD
types generally.

[...]
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Al Stevens wrote in message <2oiB2.25437$s%6.40929@newscene.newscene.com>...
>
>>   But in C++, you can and should initialize
>>   variables when you declare them.
>
>Should? Surely you aren't suggesting that all local variables need
>initialization?

Dr. Stroustrup seems to:

"If I were to design a langauge from scratch, I would follow the Algol68
path and make every statement and declaration an expression that yields a
value.  I would probably also ban uninitialized variables...."  --THE DESIGN
AND EVOLUTION OF C++, section 3.11.5.2.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Matt Seitz wrote in message <36d6f140.0@newsread.exodus.net>...
>Al Stevens wrote in message
<2oiB2.25437$s%6.40929@newscene.newscene.com>...
>>
>>>   But in C++, you can and should initialize
>>>   variables when you declare them.
>>
>>Should? Surely you aren't suggesting that all local variables need
>>initialization?
>
>Dr. Stroustrup seems to:
>
>"If I were to design a langauge from scratch, I would follow the Algol68
>path and make every statement and declaration an expression that yields a
>value.  I would probably also ban uninitialized variables...."  --THE
DESIGN
>AND EVOLUTION OF C++, section 3.11.5.2.

He also said in that book that if he had followed his druthers and designed
a language as he wanted but one that was not compatible with C, it would
have become an "unimportant cult language."

K&R describes C as "not a 'very high level' language, nor a 'big' one..." It
was designed such that compiler writers could take advantage of the target
machine's architecture. CPU memory cells and registers, the variables of
machine and assembly language, are rarely automatically initialized. I
repeat, not all variables need to be initialized.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn7dbjnj.580.sbnaran@bardeen.ceg.uiuc.edu>, Siemel Naran
<sbnaran@bardeen.ceg.uiuc.edu> writes
>The advantage of namespaces within classes is that entities in the
>outer namespace are accessible in the enclosing namespace.  Eg,
>
>   class X {
>      private:
>         const int x;
>         namespace Silly { int f() const { return +x; } }
>         namespace Smart { int f() const { return -x; } }
>      public:
>         explicit X(int x_) : x(x_) { }
>         int action() const { return Silly::f()+Smart::f(); }
>   };
>
>But if 'Silly' and 'Smart' were nested classes, then they could
>not see X::x.

Sure they can see it but do not have access.  So make the nested classes
friends (an example of friendship with which I have little problem)

Francis Glassborow      Chair of Association of C & C++ Users
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 27 Feb 1999 15:57:08 GMT, Francis Glassborow
>Siemel Naran

>>But if 'Silly' and 'Smart' were nested classes, then they could
>>not see X::x.
>
>Sure they can see it but do not have access.  So make the nested classes
>friends (an example of friendship with which I have little problem)

Friendship has nothing to do with anything.  A nested class is just
a type.  A type does not have a "this" pointer.  Re-consider my
example, where I've made 'Silly' and 'Smart' nested classes, and made
the whole thing public, just for simplicity.

  class X {
     public: // was private
        const int x;
        struct Silly { int f() const { return +x; } } // was namespace
        struct Smart { int f() const { return -x; } } // was namespace
     public:
        explicit X(int x_) : x(x_) { }
        int action() const { return Silly::f()+Smart::f(); }
  };

The call "Silly::f()" is a syntax error because you are calling a
member function without an object.
In fact, this is a compile error
   int X::Smart::f() { return x; } // error: no variable 'x'
Indeed, sizeof(X)==sizeof(X::x).

But if 'Silly' and 'Smart' were namespaces, "Silly::f()" makes sense.
Indeed, sizeof(X)==sizeof(X::x)+sizeof(data of X::Silly and X::Smart).

For clarity, the type of "this" in X::Silly::f() is "X *const".
Not "X::Silly *const"!

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn7dgm1u.6fo.sbnaran@bardeen.ceg.uiuc.edu>, Siemel Naran
<sbnaran@bardeen.ceg.uiuc.edu> writes
>Friendship has nothing to do with anything.  A nested class is just
>a type.  A type does not have a "this" pointer.  Re-consider my
>example, where I've made 'Silly' and 'Smart' nested classes, and made
>the whole thing public, just for simplicity.
>
>  class X {
>     public: // was private
>        const int x;
>        struct Silly { int f() const { return +x; } } // was namespace
>        struct Smart { int f() const { return -x; } } // was namespace
>     public:
>        explicit X(int x_) : x(x_) { }
>        int action() const { return Silly::f()+Smart::f(); }
>  };
>
>The call "Silly::f()" is a syntax error because you are calling a
>member function without an object.
>In fact, this is a compile error
>   int X::Smart::f() { return x; } // error: no variable 'x'
>Indeed, sizeof(X)==sizeof(X::x).
>
>But if 'Silly' and 'Smart' were namespaces, "Silly::f()" makes sense.
>Indeed, sizeof(X)==sizeof(X::x)+sizeof(data of X::Silly and X::Smart).
>
>For clarity, the type of "this" in X::Silly::f() is "X *const".
>Not "X::Silly *const"!


If you truly want to do something like this, use MI with ABC's providing
the partitions.  If the partitions are genuine features of the design
the odds are fairly high that one or more of them will be reusable and
so such an approach is probably a correct design.




Francis Glassborow      Chair of Association of C & C++ Users
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I wrote:
>> I've argued for default initialization of (auto) built-in types
>> on this newsgroup before, and the only real objection was the same
>> one that Benjamin gave above.

nabbasi@pacbell.net.NOSPAM wrote:
> I don't think default initialization is that much of a good idea.
> First, what would you initialize a boolean to? if you say False, I say
> why not True?  If you initialize an int to 0, why not -1 why not 999?
> What would you initialize an enum variable to?

The compiler would initialize an auto variable to the same value it
would be initialized to by default if it was declared static, i.e.,
zero.  This is already well-established and standardized behavior.

> Also, the point is not really what to initialize something to, it is
> for me the responsibility of the programmer to know what initial
> values theirs variable should take before being used. Not the
> compiler.

Yes, and when you fail to initialize a variable, what do you expect
its value to be?

Every data type except built-in and aggregate data types have
well-defined initializations.  Static variables of every type have
well-defined initializations.  All I'm asking for is that all
variables of all data types have well-defined initializations
(unless the programmer explicitly disables them).

>> My response was to allow a language
>> feature so that the programmer could explicitly specify that he
>> doesn't want default initialization; after all, the example above
>> is fairly rare, and most programmers probably wouldn't mind if
>> their local variables were initialized for them.
>
> I would mind :)
>
> A lot of people who program in C, even though C does this
> initialization, for global and static variables, would still
> initialize their variables.
> I guess just in case :)
>
> Also, it seems a waste for the compiler to generate instructions to
> initialize a local stack variables, when all you wanted to do is
> 'write' to them. no?

Yes, if it were only that simple.  What if all you wanted to do was
to 'increment' them?

I still haven't heard any good arguments of what harm it would do.

-- David R. Tribble, dtribble@technologist.com --


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote:
> David's suggestion of making default initialization of built-ins the
> norm, turned off by a keyword, would slow down a lot of legacy code
> that was counting on the compiler to not waste time initializing
> things that will be re-initialized by later code.

Ah, the first good objection to the idea.  I predict a 1%-3%
slowdown in code execution speed on 97% of existing code due to the
additional initialization.  Note that this is closer to 0% on
systems that already intialize auto variables for you (such as AIX,
which sets auto/stack words to 0xDEADBEEF upon function entry).

> A keyword to turn on default initialization wouldn't have that
> problem, but is also not needed:
>         default_initialize int arr[200];
>
> could be written right now as:
>         int arr[200]={0};
>
> The key problem, of course, is template type parameters and typedefs,
> ...

The key problem is that programmers don't bother to write the
'={0}' today, which is the whole point of mandating that the
compiler do it for you.

The problem of not being able to default-initialize tremplate args
of built-in types simply makes my point, illustrating that the
language (C++) has a hole in it.  (C does too, but not as big.)

-- David R. Tribble, dtribble@technologist.com --
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I didn't write this, but someone else did:
>> But in C++, you can and should initialize
>> variables when you declare them.

Al Stevens wrote:
> Should? Surely you aren't suggesting that all local variables need
> initialization?
>     {
>         int x;
>         FillMyInt(&x);
>         // ...
>     }
>
> Auto initialization of x would add unnecessary overhead.

Which is why I suggested the explicit disabling of intitialization
with something like:

    int  x = {};

Besides, the overhead of initializing built-in types is probably
not that high.  In your example above, the cost of setting x to
zero prior to calling FillMyInt() is more than likely less than
10% of the cost of calling FillMyInt().

> Now, if the compiler could see that a variable is referenced without
> first being initialized, assigned to, or dereferenced through its
> address (which is possible; some compilers emit warnings if you
> reference a variable without doing one of those), it might be useful
> to have the compiler auto-initialize the variable.

The compiler could only do this if it knew that FillMyInt() didn't
read the value of x before writing to x.  Which is not likely in
most uses of FillMyInt(), since it probably resides in a separate
source file or third-party library.

Then there's the problem of what happens when FillMyInt() throws
an exception.  Nothing bad happens in your code above, but what if
the outer function has a catch() block that uses the value of x,
which is indeterminate (due to its lack of initialization)?

Again, I'm not convinced that built-in types should be excluded
from default initialization simply because they are built-in types.
I believe the risks of unitialized data outweight the cost of
default initialization.

-- David R. Tribble, dtribble@technologist.com --
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sbnaran@KILL.uiuc.edu wrote:
> Siemel Naran wrote
> Sorry to reply to my own post, but there's an advanced technique
> I've used on occassion -- an anonymous struct.
>
> class Silly
> {
>    private:
>       struct { int a; int b; } hello;
>       struct { std::complex<int> a; std::complex<int> b; } world;
>    public:
>       Silly() { }
> };
>
> There's one problem with this method.  Builtin variables created as
> local or heap objects are not zero-initialized, whereas STL
> variables are.  So the above does not zero initialize hello::a and
> hello::b, but it does zero initialize world::a and world::b.
>
> I find this dichotomy between builtin variables and STL variables to
> be positively annoying.  IMNSHO, builtin variables should be zero
> initialized.

Benjamin Scherrey wrote:
> I wasn't aware that std::complex<> types were initialized upon
> construction and find *this* to be annoying (but only slightly so).
>
> The (very good) reason that built-in types aren't is so when you do
> this:
>         unsigned long BigArray[1000000];
>
> ...you don't pay for 1000000 constructor/initialization calls. Of
> course, if you declare that BigArray (or anything else) as static, it
> does get initialized to zero (or its equivalent). Naturally, however,
> you only get one of those.

I've argued for default initialization of (auto) built-in types
on this newsgroup before, and the only real objection was the same
one that Benjamin gave above.  My response was to allow a language
feature so that the programmer could explicitly specify that he
doesn't want default initialization; after all, the example above
is fairly rare, and most programmers probably wouldn't mind if
their local variables were initialized for them.

So we could have something like and empty initializer-list to
explicitly specify that no default initialization is to occur:

    void foo()
    {
        double   bigArr[100000] = {};   // Is not initialized
        double   small[20];             // Is initialized
        ...
    }

-- David R. Tribble, dtribble@technologist.com --
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>
>I've argued for default initialization of (auto) built-in types
>on this newsgroup before, and the only real objection was the same
>one that Benjamin gave above.

I dont think default initialization is that much of a good idea.
First, what would you initialize a boolean to? if you say False, I say
why not True?  If you initialize an int to 0, why not -1 why not 999? What
would you initialize an enum variable to?

Also, the point is not really what to initialize something to, it is
for me the responsibility of the programmer to know what initial values
theirs variable should take before being used. Not the compiler.

> My response was to allow a language
>feature so that the programmer could explicitly specify that he
>doesn't want default initialization; after all, the example above
>is fairly rare, and most programmers probably wouldn't mind if
>their local variables were initialized for them.
>

I would mind :)

Allot of people who program in C, even though C does this initialization,
for global and static variables, would still initialize their variables.
I guess just in case :)

ALso, it seems a waste for the compiler to generate instructions to
initialize a local stack variables, when all you wanted to do is  'write' to
them. no?

Nasser


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 25 Feb 1999 16:58:29 GMT, nabbasi@pacbell.net.NOSPAM
>David Tribble


>>I've argued for default initialization of (auto) built-in types
>>on this newsgroup before, and the only real objection was the same
>>one that Benjamin gave above.

>I dont think default initialization is that much of a good idea.
>First, what would you initialize a boolean to? if you say False, I say
>why not True?  If you initialize an int to 0, why not -1 why not 999? What
>would you initialize an enum variable to?

A boolean would be set to #false.
An enum would be set to the first enumeration.

What happens when you create a std::pair<int,int> or a
std::complex<double,double>.  Each value is zero initialized.
Technically, this is because of the following constructors:
   std::pair<T1,T2>::pair() : first(), second() { }
   std::complex<T>::complex() : d_real(), d_imag() { }

This is the precedent for zero initializing ints, doubles, etc.


>Also, the point is not really what to initialize something to, it is
>for me the responsibility of the programmer to know what initial values
>theirs variable should take before being used. Not the compiler.

Good point.  Two notes.

1. The practice of not zero-initializing arose because in the early
   days of C, you declared all the variables your function needs
   at the top of the function.  To eliminate the overhead of zero
   initializing the variables, and then re-initializing them later
   in the function, the rule was that locals should not be
   zero-initialized.  But in C++, you can and should initialize
   variables when you declare them.  Besides, this makes the types of
   variables easier to track, and also affords greater locality.
   I hear that C is going to adopt the C++ rule of declaring
   variables anywhere in the function (how long before they adopt
   C++ casts?!).  So now builtins can be zero initialized in both
   languages.  It would only hurt old code (and there's lots of that).

2. Your point that it is the programmer's responsibility to know
   what the initial values are is a good one.  On more than one
   occassion, the warning "variable used before its value set" has
   saved me.  In most cases, I initialize variables anyway.


>ALso, it seems a waste for the compiler to generate instructions to
>initialize a local stack variables, when all you wanted to do is  'write' to
>them. no?

Ah, but see my point (1) above.


Here's the practical reason why I want builtins to be zero initialized
by default.  I use these fixed sized arrays very often:

template <class T, size_t N>
class fvector { T d_data[N]; public: fvector(){} ... };

In fvector<std::complex<double>,10>, each of the 10 elements is zeroed.
In fvector<double,10>, each of the 10 elements is not zeroed.
Within the language, what I need is something like this:

fvector<T,N>::fvector()
{
   if (T==builtin_type) // makes sense
   {
      for (size_t i=0; i<N; i++) d_data[i]=T();
   }
}

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 25 Feb 99 05:07:28 GMT, David R Tribble <dtribble@technologist.com> wrote:

>So we could have something like and empty initializer-list to
>explicitly specify that no default initialization is to occur:
>
>    void foo()
>    {
>        double   bigArr[100000] = {};   // Is not initialized
>        double   small[20];             // Is initialized
>        ...
>    }

I like it!

What about the subject of this thread?!  I think that namespaces
within a class are a great idea, and it seems that they should be
easy to implement.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

nabbasi@pacbell.net.NOSPAM wrote:
>
>
> >
> >I've argued for default initialization of (auto) built-in types
> >on this newsgroup before, and the only real objection was the same
> >one that Benjamin gave above.
>
> I dont think default initialization is that much of a good idea.
> First, what would you initialize a boolean to? if you say False, I say
> why not True?  If you initialize an int to 0, why not -1 why not 999? What
> would you initialize an enum variable to?

What value they should be initialized to is very clear; default
initialization is defined for built-in types; it just doesn't apply to
auto variables. It is (usually?) equivalent to initialization by 0, cast
to the appropriate type.

David's suggestion of making default initialization of built-ins the
norm, turned off by a keyword, would slow down a lot of legacy code that
was counting on the compiler to not waste time initializing things that
will be re-initialized by later code. A keyword to turn on default
initialization wouldn't have that problem, but is also not needed:

 default_initialize int arr[200];

could be written right now as:

 int arr[200]={0};

The key problem, of course, is template type parameters and typedefs,
where this is just one of the many incompatibilities between built-in
types and user-defined types that complicate template code. That's a
side-effect of the decision to keep C++ somewhat backward compatible
with C, and I don't see any solution that won't violate that goal.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>   But in C++, you can and should initialize
>   variables when you declare them.

Should? Surely you aren't suggesting that all local variables need
initialization?

{
    int x;
    FillMyInt(&x);
    // ...
}

Auto initialization of x would add unnecessary overhead.

Now, if the compiler could see that a variable is referenced without first
being initialized, assigned to, or dereferenced through its address (which
is possible; some compilers emit warnings if you reference a variable
without doing one of those), it might be useful to have the compiler
auto-initialize the variable.



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7b2q3e$q83@drn.newsguy.com>,  <nabbasi@pacbell.net.NOSPAM> wrote:
>I dont think default initialization is that much of a good idea.
>First, what would you initialize a boolean to? if you say False, I say
>why not True?

Consistancy.

>  If you initialize an int to 0, why not -1 why not 999?

Consistancy.

> What
>would you initialize an enum variable to?
>
Zero - which is always a legal value for an enum inb C++.


Basically, *static* duration objects are all zero-initialized,
automatically, so *if* on does auto-initialization of automatics
it should be to zero as well.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <36D58C0D.2C7C42F7@wizard.net>, James says...

>
>What value they should be initialized to is very clear; default
>initialization is defined for built-in types; it just doesn't apply to
>auto variables. It is (usually?) equivalent to initialization by 0, cast
>to the appropriate type.
>

In this, the language seem not consistant with enumeration. In this example:

enum enum_type { A,B };
int main()
{
  enum_type e;
  return 0;
}

Here, e is initialized to A, a member of the enumeration type.
However, replace the type with this:

enum enum_type { A=3, B};

You'll find that e is initialized to 0, which is NOT an element in enum_type.

If the compiler must initialize a variable, it better be smart enough to
at least initialize it to a value in the domain of values the variable type
is defined over.

Nasser


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sbnaran@fermi.ceg.uiuc.edu (Siemel Naran) writes:


>What about the subject of this thread?!  I think that namespaces
>within a class are a great idea, and it seems that they should be
>easy to implement.

But not easy to specify the semantics. All the current rules about
namespaces and scopes would require modification if namespaces could
appear other than in "namespace scope."

Lookup rules involving namespaces are very complicated, especially
when using-declarations and using-directives are involved. The rules
now in the standard have gone through quite a bit of tweaking, and
some on the C++ Committee argue they still are not correct. More
tweaking would be required with this change.  We should get a large
benefit for the large headaches we would take on.

Speaking of which, what programming problem is solved by allowing
namespaces in classes that is not solved equally well by using
nested classes or sets of classes in a namespace?

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


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Siemel Naran wrote in message ...
[snip]
>Within the language, what I need is something like this:
>
>fvector<T,N>::fvector()
>{
>   if (T==builtin_type) // makes sense
>   {
>      for (size_t i=0; i<N; i++) d_data[i]=T();
>   }
>}


But you already can do that. Put in place a template class type_traits
and then:

fvector<T,N>::fvector()
{
   if (type_traits<T>::builtin_type) // makes sense
   {
      for (size_t i=0; i<N; i++) d_data[i]=T();
   }
}

Andrei




[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 25 Feb 1999 21:53:15 GMT, nabbasi@pacbell.net <nabbasi@pacbell.net> wrote:

>enum enum_type { A=3, B};
>
>You'll find that e is initialized to 0, which is NOT an element in enum_type.

If I'm not mistaken, 0x00 is in the enum's range.  Perhaps the fields
A and B are bit fields that can be either off or on.  Then A which is
0x011 means bits 0,1 are ON, and B which is 0x100 means bits 2 are ON.

It would be nice if the language let us distinguish bit enums and one
enums.  Bit enums are like 0x01, 0x02, 0x04, 0x08, etc -- any bit can
be ON or OFF.  One enums are like 1, 2, 3, 4, etc -- only one value
can be ON at any time.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7b4f59$8jc$1@engnews1.eng.sun.com>, Steve Clamage
<stephen.clamage@Eng.sun.com> writes
>Speaking of which, what programming problem is solved by allowing
>namespaces in classes that is not solved equally well by using
>nested classes or sets of classes in a namespace?

Being lazy minded;-)  Not understanding how the language works;-) Like
the ones that are solved with goto.

Francis Glassborow      Chair of Association of C & C++ Users
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn7cm3ug.ddd.sbnaran@fermi.ceg.uiuc.edu>, sbnaran@KILL.uiuc.edu
wrote:
>On 17 Feb 1999 17:57:30 GMT, Siemel Naran
>Sorry to reply to my own post, but there's an advanced technique I've
>used on occassion -- an anonymous struct.
>
>class Silly
>{
>   private:
>      struct { int a; int b; } hello;
>      struct { std::complex<int> a; std::complex<int> b; } world;
>   public:
>      Silly() { }
>};
>
>There's one problem with this method.  Builtin variables created as
>local or heap objects are not zero-initialized, whereas STL variables
>are.  So the above does not zero initialize hello::a and hello::b, but
>it does zero initialize world::a and world::b.
>
>I find this dichotomy between builtin variables and STL variables to
>be positively annoying.  IMNSHO, builtin variables should be zero
>initialized.

        I wasn't aware that std::complex<> types were initialized upon
construction and find *this* to be annoying (but only slightly so). The (very
good) reason that built-in types aren't is so when you do this:

        unsigned long BigArray[1000000];

        ...you don't pay for 1000000 constructor/initialization calls. Of
course, if you declare that BigArray (or anything else) as static, it does get
initialized to zero (or its equivalent). Naturally, however, you only get one
of those.

        regards & later,

                Ben Scherrey

On Tue, 16 Feb 1999 21:28:21 -0500, Malavon <malavon@erols.com> wrote:

>I don't understand why I can't have a namespace within a class.  I'd like to
>have something like:

The feature makes sense, but I think it's overkill.
A class is usually compact enough that all the members and data
can reside within a single namespace within the class.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 17 Feb 1999 17:57:30 GMT, Siemel Naran
>On Tue, 16 Feb 1999 21:28:21 -0500, Malavon <malavon@erols.com> wrote:

>>I don't understand why I can't have a namespace within a class.  I'd like to
>>have something like:

>The feature makes sense, but I think it's overkill.
>A class is usually compact enough that all the members and data
>can reside within a single namespace within the class.

Sorry to reply to my own post, but there's an advanced technique I've
used on occassion -- an anonymous struct.

class Silly
{
   private:
      struct { int a; int b; } hello;
      struct { std::complex<int> a; std::complex<int> b; } world;
   public:
      Silly() { }
};

There's one problem with this method.  Builtin variables created as
local or heap objects are not zero-initialized, whereas STL variables
are.  So the above does not zero initialize hello::a and hello::b, but
it does zero initialize world::a and world::b.

I find this dichotomy between builtin variables and STL variables to
be positively annoying.  IMNSHO, builtin variables should be zero
initialized.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]