default@nospam.invalid ("Espen Ruud Schultz") wrote in message news:<j1yka.2256$8g5.30516@news2.e.nsc.no>...
>
> What I meant in that a namespace doesn't exist is compiled code, is that the
> namespace scope doesn't exist in compiled code.

I'm not real sure what you mean here.  In one sense you are completely
correct in that namespaces, classes and all kinds of stuff don't
really exist in the compiled code.  The compiler just uses that
information to ensure that you don't write code that does anything
it's not supposed to.  However, any data defined in your source code
does exist in the compiled code, for constant values known at compile
time, or in the memory used by your program for all other data.
Whether that data is defined in a class, a namespace or globally does
not matter.  The values used in your code have to exist somewhere, and
if those values are not compile time constants then that somewhere can
only be the memory used by your code.

So, if you are trying to say that storage for the values of num0 et al
does not exist in your compiled code I believe that you are mistaken.
You may mean something else and I'm just not getting your point, in
which case I apologize for the misunderstanding and ask that you
please clarify what you do mean.

The only other thing that I can imagine that you may mean is that
defining values in a namespace inside a class would mean that those
values would not contribute to the size of objects of your class,
while defining those same values in a nested class or stuct would.  If
that is the case, then the answer is that the contribution to object
size depends on whether those values are per-object or per-class.

If each object of your class may have its own set of these values,
then you are talking about per-object data and there really is no way
to avoid that data having some impact on the size of objects of your
class.  You could minimize this by storing those values in a separate
object and storing a pointer or reference to that other object in an
object of your class.  This would still use the same total amount of
storage, but passing objects of your class by value would be quicker
since only the pointer (or reference) would need to be copied.

If, on the other hand, the data values you want to group are identical
for all objects of your class, then you could contain them in static
nested objects in your class.  In that case you would have only a
single copy of the data values that would be identical for every
object of your class.

>  So that this code:
>
> class MyClass {
>
>    int num0;
>    int num1;
>    int num2;
>
> }
>
> ....and this code:
>
> class MyClass {
>
>    namespace MySpace {
>
>       int num0;
>       int num1;
>       int num2;
>
>    }
>
> }
>
> ....will work exactly the same in compiled code.  That a namespace is just a
> grouping on paper, and does not exist in running code.  And this is why I
> want a namespace inside a class.  I do not wish to do anything else but to
> group a few variables.  So I'm stuck with a few options:
>
> 1.  Find a way to group member variables without namespaces.  The closest
> example to a namespace is Niklas Matthies example.  But there is still a
> tiny and unnecessary overhead, which both 2 and 3 won't have.

What Niklas Matthies showed in his code sample is exactly what I said
in text in my post.  The only difference is that he used a nested
struct instead of a nested class, a difference that is not significant
in any way in this case.

>
> 2.  Just skip grouping and face having tens or hundreds of memeber stuff in
> the same group or scope.  This makes the code harder to read, but at least
> it will be doen with.

This also makes the code harder to maintain and removes all the
benefits that you get from logically grouping your data to help ensure
correct usage.  Plus, if the overhead you refer to is the storage
space inside your class for these values, then it doesn't really
matter whether they are stored directly in the class object or in
sub-objects of that class object.  Any difference at all between these
two cases will be nothing more than a few padding bytes that may be
needed depending on how the data is grouped.

>
> 3.  Allow namespaces inside a class...

What specific benefit do you imagine that this will provide over the
solution proposed by Niklas and myself?

Sorry this is taking so long.  We are trying to help you out, but I at
least don't seem to understand what benefit you are claiming that the
proposed solution does not provide.  If you could clarify that point
perhaps we might be able to offer better advice.

Randy.

>
> , Espen
>

---
[ 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                       ]

"Randy Maddox" <rmaddox@isicns.com> wrote in message
news:8c8b368d.0304110609.7c039ed5@posting.google.com...
|
| I'm not real sure what you mean here.
|

Thanks for all your replies so far - to everyone.  I see that you're trying
to understand just as hard as I'm trying to explain.  So I will wipe it all
off and start over.  So please clear you mind of anything class like or
object oriented.  Because what I want isn't even near object oriented
programming - it is much simpler.

So to explain this I would like to start on the global scope.  Imagine you
have a few variables you want to group.  You would probably use a namespace,
right?  Just like this:

namespace MySpace {

   int MyInt0;
   int MyInt1;
   int MyInt2;

}

This is simple.  The namespace MySpace is just a group that appears on paper
( the variables do indeed have their own memory, but the group does not ).
The problem is that I have lots of variables I would like to group like this
inside a class.  My first question was; "Why aren't namespaces allowed
inside a class?".  Becasue it seems so logical to have them there, to make
subgroups within a class.

There have been a few solutions, but none as simple as a namespace.  The
best solution so far includes a struct with a constructor.  Fairly this is a
simple solution.  But it is still a few steps more complex than a namespace.
But what annoys me the most, and that make me not want to settle with this
solution, is that this makes every group an object - with a constructor -
and some overhead ( the constructor ) - instead of just being separate
variables that are just grouped together.


I don't expect anyone to see this as a real problem.  Since you have
probably done it differently for years, and as I humbly would like to say;
"Have learned to live with the problem and work around it."  It's either
that, or you know something I don't.  And if so, please explain why a
namespace doesn't belong inside a class?  Because this is a rule I would
gladly see changed...

There is, however, another releated problem I would like to address in a new
topic.  I won't write that now, since it's obviously too late.  I do hope
that you won't think; "Aw, there he goes again.  Questioning the rules of
C++ as we have known them for years..."

Thank you.

, Espen

---
[ 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                       ]

default@nospam.invalid ("Espen Ruud Schultz") wrote in message news:<f%Gla.3367$8g5.45565@news2.e.nsc.no>...
> "Randy Maddox" <rmaddox@isicns.com> wrote in message
> news:8c8b368d.0304110609.7c039ed5@posting.google.com...
> |
> | I'm not real sure what you mean here.
> |
>
> Thanks for all your replies so far - to everyone.  I see that you're trying
> to understand just as hard as I'm trying to explain.  So I will wipe it all
> off and start over.  So please clear you mind of anything class like or
> object oriented.  Because what I want isn't even near object oriented
> programming - it is much simpler.
>
> So to explain this I would like to start on the global scope.  Imagine you
> have a few variables you want to group.  You would probably use a namespace,
> right?  Just like this:
>
> namespace MySpace {
>
>    int MyInt0;
>    int MyInt1;
>    int MyInt2;
>
> }
>
> This is simple.  The namespace MySpace is just a group that appears on paper
> ( the variables do indeed have their own memory, but the group does not ).
> The problem is that I have lots of variables I would like to group like this
> inside a class.  My first question was; "Why aren't namespaces allowed
> inside a class?".  Becasue it seems so logical to have them there, to make
> subgroups within a class.
>
> There have been a few solutions, but none as simple as a namespace.  The
> best solution so far includes a struct with a constructor.  Fairly this is a
> simple solution.  But it is still a few steps more complex than a namespace.
> But what annoys me the most, and that make me not want to settle with this
> solution, is that this makes every group an object - with a constructor -
> and some overhead ( the constructor ) - instead of just being separate
> variables that are just grouped together.
>

While you refer to the initialization by constructor of the nested
class as "overhead", I think you will find that those grouped
variables need to be initialized at some point anyway.  Thus, if you
were able to nest a namespace inside your class, you would still be
faced with the issue of initializing the values of the variables
inside that namespace.  Using nested classes instead provides a
well-defined idiom, ctor initializer list, to set those values, and
localizes the initialization of the values for each group to the ctor
for the nested class containing that group.  This is a good thing.

In other words, I still believe that the nested class solution is the
best, as far as I understand your question.

Sorry I couldn't be any more helpful.

Randy.

>
>
> Thank you.
>
> , Espen
>

---
[ 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                       ]

default@nospam.invalid ("Espen Ruud Schultz") wrote in message news:<k5ija.1334$b71.28625@news4.e.nsc.no>...
> "Randy Maddox" <rmaddox@isicns.com> wrote in message
> news:8c8b368d.0304030631.69d1846@posting.google.com...
> |
> | But you can declare a namespace within a class.  It's called a nested
> | class.  Just rewrite your example above as:
> |
> |  class MyClass {
> |
> |  private:    // or public or protected, whatever you need
> |
> |     class Status {
> |
> |        static const unsigned int Ok        = 0;
> |        static const unsigned int ReadOnly  = 1;
> |        static const unsigned int WrongType = 2;
> |      };
> |  };
> |
> | A class is, among other things, a namespace, and the notation for
> | accessing the names is the same as for a namespace.  So I believe this
> | may work for you, but the constant values may need to be initialized
> | somewhere else, although the Standard says in 9.4.2/4 that the above
> | notation is good some compilers still complain.
> |
> | Does that work for you?
> |
>
> This works perfectly for const members.  But lets take this example which is
> something I'm working on right now:
>
> /"
> class Device {
>
>    public:
>
>       struct Setup {
>
>          Setup( const bool A, const unsigned int B, const unsigned int C,
> const unsigned int D, const unsigned int E ) : EnableLogging( A ),
> ViewportSizeX( B ), ViewportSizeY( C ), InputBufferSize( D ),
> OutputBufferSize( E ) { }
>
>          const bool EnableLogging;
>          const unsigned int ViewportSizeY;
>          const unsigned int ViewportSizeX;
>          const unsigned int InputBufferSize;
>          const unsigned int OutputBufferSize;
>
>       };
>
>       Device( const Setup cfg );
>
>       ...
>
>    private:
>
>       const Setup cfg;
>
>       ...
>
> };
> "/
>
> I've been using this code so far.  I use the Setup struct to group together
> a few constants ( these can't be static ).  First of all, the Setup struct
> has to be public, which is bad all by itself.  Second, I have to make an
> object out of Setup.  Now lets look at how it could've been done with a
> namespace:

If you use a ctor for Device like you show below, then your setup
class need not be public at all.  Furthermore, if you use a Setup
class as above with your device ctor from below, then the issue of the
initializer list disappears.

It looks to me like this combination meets all of your stated needs.
Your idea that the namespace does not exist in compiled code may be
true in some sense, but the constants in the namespace below would in
fact exist in your compiled code since they are apparently supplied to
the ctor at run time, as opposed to being compile time constants.  As
long as the constant values are supplied at run time there will always
need to be storage for them.

Another potential alternative would be to make all those parameters be
template parameters, which would need to be known at compile time, so
this would work if and only if you do actually know those values at
compile time.  Again, any constant whose value is not known at compile
time will need storage that is initialized at run time.

Randy.

>
> /"
> class Device {
>
>    public:
>
>       Device( const bool A, const unsigned int B, const unsigned int C,
> const unsigned int D, const unsigned int E ) : this->Setup::EnableLogging(
> A ), this->Setup::ViewportSizeX( B ), this->Setup::ViewportSizeY( C ),
> this->Setup::InputBufferSize( D ), this->Setup::OutputBufferSize( E ) { };
>
>       ...
>
>    private:
>
>       namespace Setup {
>
>          const bool EnableLogging;
>          const unsigned int ViewportSizeY;
>          const unsigned int ViewportSizeX;
>          const unsigned int InputBufferSize;
>          const unsigned int OutputBufferSize;
>
>       }
>
>       ...
>
> };
> "/
>
> I'm not sure how I would assign them in the init-list, but I think you get
> the idea, maybe it's even the right way.  This is, however, the ideal way:
> All the constants are private.  I don't have to create an object out of
> them.  And they are logically grouped in my eyes.  This code is easier to
> understand by anyone who reads it.  Especially with tens or hundreds of
> variables who easily can be put into nice groups.
>
> As I've said before ( if you read between the lines ):  There are number of
> ways to solve these "problems" one by one, but only a namespace will fix
> them all at once, and at a minimal cost, because a namespace don't exist in
> compiled code...
>
> , Espen
>
> ---
> [ 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                       ]

"Niklas Matthies" <comp.std.c++_2003-04-05@nmhq.net> wrote in message
news:slrnb8tnnr.23e5.comp.std.c++_2003-04-05@nmhq.net...
|
| This isn't so bad, is it?
|

Nope, that's actually the best solution to grouping so far.  And I would say
it's only a few %ages from pure namespace grouping...

| But personally, I *would* make Config a public class and an object for
| the user of Device, since it's a logical unit, and the user can have
| different Device configurations lying around as Config objects, and
| just pass one to the Device constructor to create a Device with that
| configuration. What could be more natural than that?
|

Nah.  You see, the absolutely first version I made of my class, the user had
to initialize a Setup object and then pass that object to the main class.  I
found this unlogical since then, the user would have an object in the
remainder of its code, that was no longer needed.  I agree that there are
lots of uses for having an external object that control a class, but none in
the class I'm working on now.  Then again, this is just my opinion...

, Espen

---
[ 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 2003-04-08 18:09, "Espen Ruud Schultz" <default@nospam.invalid> wrote:
> "Niklas Matthies" <comp.std.c++_2003-04-05@nmhq.net> wrote:
[...]
>| But personally, I *would* make Config a public class and an object for
>| the user of Device, since it's a logical unit, and the user can have
>| different Device configurations lying around as Config objects, and
>| just pass one to the Device constructor to create a Device with that
>| configuration. What could be more natural than that?
>
> Nah.  You see, the absolutely first version I made of my class, the user had
> to initialize a Setup object and then pass that object to the main class.  I
> found this unlogical since then, the user would have an object in the
> remainder of its code, that was no longer needed.

Why? Just construct it locally on the stack if you only need it at the
time of construction of the Device object:

   Device * makeDevice(...)
   {
      Device::Config const config(<some arguments>);
      return new Device(config);
   }

This is pretty much equivalent to:

   Device * makeDevice(...)
   {
      return new Device(<some arguments);
   }

If the constructors are inline, the generated code may even be exactly
the same.

-- Niklas Matthies

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

"Randy Maddox" <rmaddox@isicns.com> wrote in message
news:8c8b368d.0304070516.5399b0d0@posting.google.com...
|
| If you use a ctor for Device like you show below, then your setup
| class need not be public at all.  Furthermore, if you use a Setup
| class as above with your device ctor from below, then the issue of the
| initializer list disappears.
|
| It looks to me like this combination meets all of your stated needs.
| Your idea that the namespace does not exist in compiled code may be
| true in some sense, but the constants in the namespace below would in
| fact exist in your compiled code since they are apparently supplied to
| the ctor at run time, as opposed to being compile time constants.  As
| long as the constant values are supplied at run time there will always
| need to be storage for them.
|
| Another potential alternative would be to make all those parameters be
| template parameters, which would need to be known at compile time, so
| this would work if and only if you do actually know those values at
| compile time.  Again, any constant whose value is not known at compile
| time will need storage that is initialized at run time.
|

What I meant in that a namespace doesn't exist is compiled code, is that the
namespace scope doesn't exist in compiled code.  So that this code:

class MyClass {

   int num0;
   int num1;
   int num2;

}

....and this code:

class MyClass {

   namespace MySpace {

      int num0;
      int num1;
      int num2;

   }

}

....will work exactly the same in compiled code.  That a namespace is just a
grouping on paper, and does not exist in running code.  And this is why I
want a namespace inside a class.  I do not wish to do anything else but to
group a few variables.  So I'm stuck with a few options:

1.  Find a way to group member variables without namespaces.  The closest
example to a namespace is Niklas Matthies example.  But there is still a
tiny and unnecessary overhead, which both 2 and 3 won't have.

2.  Just skip grouping and face having tens or hundreds of memeber stuff in
the same group or scope.  This makes the code harder to read, but at least
it will be doen with.

3.  Allow namespaces inside a class...

, Espen

---
[ 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                       ]

default@nospam.invalid ("Espen Ruud Schultz") wrote in message news:<NZIia.786$8g5.8746@news2.e.nsc.no>...
> I can't think of any reasons why namespaces shouldn't be allowed inside a
> class.  So why is this the case?  A namespace is just a way to group
> variables, functions, etc, to make it look logical.

There is no techniocal reason, the main reason is that allowing it would
make the grammar even more complex.

> There have been number of cases where I find a namespace like this usefull.
> This is how I've been working past it:
>
> namespace MyClass {
>    namespace Status {
>       const unsigned int Ok        = 0;
>       const unsigned int ReadOnly  = 1;
>       const unsigned int WrongType = 2;
>    }
>    class MyRealClass {
>    };
> }
> Now this just makes an extra unnecessary scope.  And I have no control over
> the namespace, it's "public" even if I like it to be or not.  When I have a
> few or more of these "groups", then not grouping them makes a mess.

So why not write:
class MyRealClass {
  enum Errors {
    Ok = 0,
    ReadOnly = 1,
    WrongType = 2,
  }
};

HTH,
--
Michiel Salters

---
[ 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                       ]

""Espen Ruud Schultz"" <default@nospam.invalid> wrote in message
news:NZIia.786$8g5.8746@news2.e.nsc.no...
> I can't think of any reasons why namespaces shouldn't be allowed inside a
> class.  So why is this the case?  A namespace is just a way to group
> variables, functions, etc, to make it look logical.
>
> There have been number of cases where I find a namespace like this
usefull.
> This is how I've been working past it:
>
> namespace MyClass {
>
>    namespace Status {
>
>       const unsigned int Ok        = 0;
>       const unsigned int ReadOnly  = 1;
>       const unsigned int WrongType = 2;
>
>    }
>
>    class MyRealClass {
>
>       ...
>
>    };
>
> }
>
> Now this just makes an extra unnecessary scope.  And I have no control
over
> the namespace, it's "public" even if I like it to be or not.  When I have
a
> few or more of these "groups", then not grouping them makes a mess.
>
> What I'm trying to say is that namespaces inside a class can't possibly
hurt
> anyone, and will most likely add to the tidyness of classes...
>
> , Espen
>
> ---
> [ 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                       ]
>

Why don't you use an enum? it would work in your example and if you give it
a name it would be scoped just like a namespace.

---
[ 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                       ]

"Michiel Salters" <Michiel.Salters@cmg.nl> wrote in message
news:cefd6cde.0304030332.192928b0@posting.google.com...
|
| There is no techniocal reason, the main reason is that allowing it would
| make the grammar even more complex.
|

I think I once read Stroustrup say something like; he didn't want to
restrict the language to what he thought would be best right there and then,
because he couldn't anticipate what others could do, or wanted to do at a
later time.

I think what he said was aimed at a very specific part of the language (some
algorithm maybe?), and not as general as I make it seem here.  But anyway,
restricting namespaces to not be in a class is just this; a rule that might
have seemed good at the time it was thought of.  Maybe because that exact
person who had the idea didn't find any use for a namespace inside a class
at that time.  But who say that no one will ever find any use for it?

And besides, the complexity you get from allowing namespaces inside a class
is lost in the tidyness you will get from it.  Anyway, it's up to each one
to use it or not.  Some will find it helpfull, and some may not...

|
| So why not write:
| class MyRealClass {
|   enum Errors {
|     Ok = 0,
|     ReadOnly = 1,
|     WrongType = 2,
|   }
| };
|

Yeah, that can be done.  But what if I wanted to group some variables
instead of constants?

I don't want to gain any special powers by using a namespace, I just want it
to look logical and simple to the human eye.  And nothing is more simpler
than a namespace, mainly because it only have one purpose, but also becasue
it doesn't exist...

, Espen

---
[ 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 <cefd6cde.0304030332.192928b0@posting.google.com>,
Michiel.Salters@cmg.nl says...
> default@nospam.invalid ("Espen Ruud Schultz") wrote in message news:<NZIia.786$8g5.8746@news2.e.nsc.no>...
> > I can't think of any reasons why namespaces shouldn't be allowed inside a
> > class.  So why is this the case?  A namespace is just a way to group
> > variables, functions, etc, to make it look logical.
>
> There is no techniocal reason, the main reason is that allowing it would
> make the grammar even more complex.
>
> > There have been number of cases where I find a namespace like this usefull.
> > This is how I've been working past it:
> >
> > namespace MyClass {
> >    namespace Status {
> >       const unsigned int Ok        = 0;
> >       const unsigned int ReadOnly  = 1;
> >       const unsigned int WrongType = 2;
> >    }
> >    class MyRealClass {
> >    };
> > }
> > Now this just makes an extra unnecessary scope.  And I have no control over
> > the namespace, it's "public" even if I like it to be or not.  When I have a
> > few or more of these "groups", then not grouping them makes a mess.
>
> So why not write:
> class MyRealClass {
>   enum Errors {
>     Ok = 0,
>     ReadOnly = 1,
>     WrongType = 2,
>   }
> };
>
> HTH,
>

Or, another example:

namespace MyClass
{

 class MyRealClass
 {
  static struct
  {
   int myGlobal;
   void myMethod() { }
  } MyInsideNamespace;
 };

}


and call it like:

MyClass::MyRealClass::MyInsideNamespace.myMethod();

It looks almost like using namespaces inside a class. :)

Catalin

---
[ 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                       ]

default@nospam.invalid ("Espen Ruud Schultz") wrote in message news:<NZIia.786$8g5.8746@news2.e.nsc.no>...
> I can't think of any reasons why namespaces shouldn't be allowed inside a
> class.  So why is this the case?  A namespace is just a way to group
> variables, functions, etc, to make it look logical.
>
> There have been number of cases where I find a namespace like this usefull.
> This is how I've been working past it:
>
> namespace MyClass {
>
>    namespace Status {
>
>       const unsigned int Ok        = 0;
>       const unsigned int ReadOnly  = 1;
>       const unsigned int WrongType = 2;
>
>    }
>
>    class MyRealClass {
>
>       ...
>
>    };
>
> }
>
> Now this just makes an extra unnecessary scope.  And I have no control over
> the namespace, it's "public" even if I like it to be or not.  When I have a
> few or more of these "groups", then not grouping them makes a mess.
>
> What I'm trying to say is that namespaces inside a class can't possibly hurt
> anyone, and will most likely add to the tidyness of classes...
>
> , Espen
>

But you can declare a namespace within a class.  It's called a nested
class.  Just rewrite your example above as:

 class MyClass {

 private:    // or public or protected, whatever you need

    class Status {

       static const unsigned int Ok        = 0;
       static const unsigned int ReadOnly  = 1;
       static const unsigned int WrongType = 2;
     };
 };

A class is, among other things, a namespace, and the notation for
accessing the names is the same as for a namespace.  So I believe this
may work for you, but the constant values may need to be initialized
somewhere else, although the Standard says in 9.4.2/4 that the above
notation is good some compilers still complain.

Does that work for you?

Randy.

---
[ 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                       ]

"Randy Maddox" <rmaddox@isicns.com> wrote in message
news:8c8b368d.0304030631.69d1846@posting.google.com...
|
| But you can declare a namespace within a class.  It's called a nested
| class.  Just rewrite your example above as:
|
|  class MyClass {
|
|  private:    // or public or protected, whatever you need
|
|     class Status {
|
|        static const unsigned int Ok        = 0;
|        static const unsigned int ReadOnly  = 1;
|        static const unsigned int WrongType = 2;
|      };
|  };
|
| A class is, among other things, a namespace, and the notation for
| accessing the names is the same as for a namespace.  So I believe this
| may work for you, but the constant values may need to be initialized
| somewhere else, although the Standard says in 9.4.2/4 that the above
| notation is good some compilers still complain.
|
| Does that work for you?
|

This works perfectly for const members.  But lets take this example which is
something I'm working on right now:

/"
class Device {

   public:

      struct Setup {

         Setup( const bool A, const unsigned int B, const unsigned int C,
const unsigned int D, const unsigned int E ) : EnableLogging( A ),
ViewportSizeX( B ), ViewportSizeY( C ), InputBufferSize( D ),
OutputBufferSize( E ) { }

         const bool EnableLogging;
         const unsigned int ViewportSizeY;
         const unsigned int ViewportSizeX;
         const unsigned int InputBufferSize;
         const unsigned int OutputBufferSize;

      };

      Device( const Setup cfg );

      ...

   private:

      const Setup cfg;

      ...

};
"/

I've been using this code so far.  I use the Setup struct to group together
a few constants ( these can't be static ).  First of all, the Setup struct
has to be public, which is bad all by itself.  Second, I have to make an
object out of Setup.  Now lets look at how it could've been done with a
namespace:

/"
class Device {

   public:

      Device( const bool A, const unsigned int B, const unsigned int C,
const unsigned int D, const unsigned int E ) : this->Setup::EnableLogging(
A ), this->Setup::ViewportSizeX( B ), this->Setup::ViewportSizeY( C ),
this->Setup::InputBufferSize( D ), this->Setup::OutputBufferSize( E ) { };

      ...

   private:

      namespace Setup {

         const bool EnableLogging;
         const unsigned int ViewportSizeY;
         const unsigned int ViewportSizeX;
         const unsigned int InputBufferSize;
         const unsigned int OutputBufferSize;

      }

      ...

};
"/

I'm not sure how I would assign them in the init-list, but I think you get
the idea, maybe it's even the right way.  This is, however, the ideal way:
All the constants are private.  I don't have to create an object out of
them.  And they are logically grouped in my eyes.  This code is easier to
understand by anyone who reads it.  Especially with tens or hundreds of
variables who easily can be put into nice groups.

As I've said before ( if you read between the lines ):  There are number of
ways to solve these "problems" one by one, but only a namespace will fix
them all at once, and at a minimal cost, because a namespace don't exist in
compiled code...

, Espen

---
[ 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                       ]

""catalin.pitis"" <remove.this.catalin.pitis@home.ro> wrote in message
news:MPG.18f69d067ecbee3f989680@news.cis.dfn.de...
|
| Or, another example:
|
| namespace MyClass
| {
|
| class MyRealClass
| {
| static struct
| {
| int myGlobal;
| void myMethod() { }
| } MyInsideNamespace;
| };
|
| }
|
|
| and call it like:
|
| MyClass::MyRealClass::MyInsideNamespace.myMethod();
|
| It looks almost like using namespaces inside a class. :)
|

Jup, but it only solves a part of the problem.  This can't be used on
variables since all instances of the object share statics.  Unless this is
intended, something I think it was on your side since you called it
myGlobal, but I just thought I would point it out.  Though this is the best
solution, at this time, for constants.

Though I'm not sure what the standard says (probably implementor defined?),
I don't think constants inside a static struct will be optimized...

, Espen

---
[ 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 2003-04-05 02:02, "Espen Ruud Schultz" <default@nospam.invalid> wrote:
[...]
> lets take this example which is something I'm working on right now:
>
> /"
> class Device {
>
>    public:
>
>       struct Setup {
>
>          Setup( const bool A, const unsigned int B, const unsigned int C,
> const unsigned int D, const unsigned int E ) : EnableLogging( A ),
> ViewportSizeX( B ), ViewportSizeY( C ), InputBufferSize( D ),
> OutputBufferSize( E ) { }
>
>          const bool EnableLogging;
>          const unsigned int ViewportSizeY;
>          const unsigned int ViewportSizeX;
>          const unsigned int InputBufferSize;
>          const unsigned int OutputBufferSize;
>
>       };
>
>       Device( const Setup cfg );
>
>       ...
>
>    private:
>
>       const Setup cfg;
>
>       ...
>
> };
> "/
>
> I've been using this code so far.  I use the Setup struct to group together
> a few constants ( these can't be static ).  First of all, the Setup struct
> has to be public, which is bad all by itself.  Second, I have to make an
> object out of Setup.

You don't need to make Setup public, and you can mostly ignore it's
object nature:

   class Device
   {
      public:

         Device(bool A, unsigned int B, unsigned int C, unsigned int D, unsigned int E)
         : config(A, B, C, D, E) { }

      private:

         struct Config
         {
            Config(bool A, unsigned int B, unsigned int C, unsigned int D, unsigned int E)
            : EnableLogging(A), ViewportSizeX(B), ViewportSizeY(C), InputBufferSize(D), OutputBufferSize(E) { }

            bool EnableLogging;
            unsigned int ViewportSizeY;
            unsigned int ViewportSizeX;
            unsigned int InputBufferSize;
            unsigned int OutputBufferSize;
         };

         Config const config;
   };

This isn't so bad, is it?

But personally, I *would* make Config a public class and an object for
the user of Device, since it's a logical unit, and the user can have
different Device configurations lying around as Config objects, and
just pass one to the Device constructor to create a Device with that
configuration. What could be more natural than that?

-- Niklas Matthies

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

I can't think of any reasons why namespaces shouldn't be allowed inside a
class.  So why is this the case?  A namespace is just a way to group
variables, functions, etc, to make it look logical.

There have been number of cases where I find a namespace like this usefull.
This is how I've been working past it:

namespace MyClass {

   namespace Status {

      const unsigned int Ok        = 0;
      const unsigned int ReadOnly  = 1;
      const unsigned int WrongType = 2;

   }

   class MyRealClass {

      ...

   };

}

Now this just makes an extra unnecessary scope.  And I have no control over
the namespace, it's "public" even if I like it to be or not.  When I have a
few or more of these "groups", then not grouping them makes a mess.

What I'm trying to say is that namespaces inside a class can't possibly hurt
anyone, and will most likely add to the tidyness of classes...

, Espen

---
[ 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                       ]