Steve Donnelly wrote:

> Has the standards group ever considered allowing namespace-like block
> definitions of class members, external to their class definition?  To
> illustrate what I mean, imagine we have the following namespace and
> class:

There is one very fundamental difference between namespaces and classes
that make why those "block definitions" of class members are not
possible: A namespace definition can span multiple blocks in a program
(where each block can contain both declarations and definitions), but a
class definition must have exactly one block associated with it.

Thus, the
   namespace ns {
     void func();
   }
   /*...*/
   namespace ns {
     void func() {
       /* do something */
     }
   }
is not just a notational convenience for writing the definition. The
second namespace ns block can introduce new names into the namespace.
For classes, this would be extremely problematic, as the definition of a
class not only declares the members but also determines the memory
layout of the class. If multiple blocks were allowed, it becomes
impossible to guarantee a consistent layout across the entire program.

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/


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

Bart van Ingen Schenau wrote:
>
> Steve Donnelly wrote:
>
>> Has the standards group ever considered allowing namespace-like block
>> definitions of class members, external to their class definition?  To
>> illustrate what I mean, imagine we have the following namespace and
>> class:
>
> There is one very fundamental difference between namespaces and classes
> that make why those "block definitions" of class members are not
> possible: A namespace definition can span multiple blocks in a program
> (where each block can contain both declarations and definitions), but a
> class definition must have exactly one block associated with it.
>
> Thus, the
>   namespace ns {
>     void func();
>   }
>   /*...*/
>   namespace ns {
>     void func() {
>       /* do something */
>     }
>   }
> is not just a notational convenience for writing the definition. The
> second namespace ns block can introduce new names into the namespace.
> For classes, this would be extremely problematic, as the definition of a
> class not only declares the members but also determines the memory
> layout of the class. If multiple blocks were allowed, it becomes
> impossible to guarantee a consistent layout across the entire program.
>
Much worse than that, it completely torpedoes the concept of private
access. Anyone could simply add another block and gain access to the
private members of the class.

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

On Jul 11, 12:31 pm, Bart van Ingen Schenau <b...@ingen.ddns.info>
wrote:
> There is one very fundamental difference between namespaces and classes
> that make why those "block definitions" of class members are not
> possible: A namespace definition can span multiple blocks in a program
> (where each block can contain both declarations and definitions), but a
> class definition must have exactly one block associated with it.
>
> [code omitted]
>
> is not just a notational convenience for writing the definition. The
> second namespace ns block can introduce new names into the namespace.
> For classes, this would be extremely problematic, as the definition of a
> class not only declares the members but also determines the memory
> layout of the class. If multiple blocks were allowed, it becomes
> impossible to guarantee a consistent layout across the entire program.

I was already aware of this issue and tried to address it in my
initial post (which might have been more clear, had I not been so long-
winded).

First of all, I was suggesting that the external class block would not
be would not be a class definition, nor would it be able to extend
class definitions.  It would only be allowed to define members already
declared in a proper class definition, and it would only be able to
use class definitions already visible in the compilation unit.  To
differentiate class namespaces from definitions, I suggested the use
of the namespace keyword after the class declaration, for example:

// Foo.hpp ==========================
template <typename T> class Foo
{
    void bar();
    void baz();
};

// Foo.cpp ==========================
#include "Foo.hpp"  // Foo definition required

template <typename T> class Foo namespace {

void bar() { /* do stuff */ }
void baz() { /* do stuff */ }

void quux() { /* do stuff */ }
// ERROR:
// the definition above would render a compile-time
// error, similar to if you had tried to do the same
// using the traditional syntax, i.e.
// template <typename T> void Foo<T>::quux() { }

} // end namespace


There are a number of syntactic variations that would work as well--I
just think this would probably be the easiest to implement since there
is no such thing as a template namespace.

I fully agree that class definitions should be restricted to a single
block.  However, I still think that having a class-namespace block
would be valuable--requiring an explicit class-scope prefix in front
of every external method definition is clearly unnecessary, given the
alternative offered by namespaces.

The advantages of such a language feature are quite clear: it would
improve readability and ease of refactoring, while reducing
unnecessary keystrokes and copy-paste errors.

The only possible disadvantage that comes to mind is that in some
cases, programmers might have a hard time differentiating between
class definitions and class namespace blocks (perhaps a better
terminology would be a class definitions vs. class implementations).
However, I think the widely used convention of partitioning class
definitions and implementations into header and source files,
respectively, would handle the most common occurrences of this problem.

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

On Jul 9, 9:30 pm, Steve Donnelly <sjdonnell...@gmail.com> wrote:
> Has the standards group ever considered allowing namespace-like block
> definitions of class members, external to their class definition?

See the following proposal:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1420.pdf

which according to

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2869.html

is "Not ready for C++0x, but open to resubmit in future".

Yechezkel Mett


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

On Jul 12, 10:39 pm, ymett <ymett.on.use...@gmail.com> wrote:
> On Jul 9, 9:30 pm, Steve Donnelly <sjdonnell...@gmail.com> wrote:
>
> > Has the standards group ever considered allowing namespace-like block
> > definitions of class members, external to their class definition?
>
> See the following proposal:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1420.pdf
>
> which according to
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2869.html
>
> is "Not ready for C++0x, but open to resubmit in future".

I never understood this decision. The proposal is simple and useful. I
could probably add its functionality to Clang in two or three days.

Sebastian


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

On Jul 12, 4:39 pm, ymett <ymett.on.use...@gmail.com> wrote:
> On Jul 9, 9:30 pm, Steve Donnelly <sjdonnell...@gmail.com> wrote:
>
> > Has the standards group ever considered allowing namespace-like block
> > definitions of class members, external to their class definition?
>
> See the following proposal:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1420.pdf
>
> which according to
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2869.html
>
> is "Not ready for C++0x, but open to resubmit in future".

This proposal looks like a near-exact match for the concept I had in
mind.

Since it is dated as 2003, it is unlikely that the proposal is still
active?  I'm a little surprised it didn't get accepted on it's first
attempt, considering the simplicity of implementation and the obvious
time savings.


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

In article <ce1a2321-9467-419c-a624-
ba6f4d6bafaf@o13g2000vbl.googlegroups.com>, sjdonnellyjr@gmail.com
says...

[ ... ]

> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1420.pdf

[ ... ]

> Since it is dated as 2003, it is unlikely that the proposal is
> still active?  I'm a little surprised it didn't get accepted on
> it's first attempt, considering the simplicity of implementation
> and the obvious time savings.

I'm not surprised at its lack of acceptance at all. To get a proposal
accepted, especially later in the process of developing a new
standard, the proposal should normally include specific information
about how the wording of the standard should be changed -- the exact
existing sections, and proposals for what the new wording should be.
Since this would change the grammar of the language in quite a
fundamental way, there would probably be a fair number of places
throughout the standard that would have to be at least looked at and
considered. Even if the conclusion was: "no change will be needed to
this section", there are still quite a few sections that probably
need to be looked at anyway.

--
     Later,
     Jerry.

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

On Jul 13, 9:47 pm, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
> In article <ce1a2321-9467-419c-a624-
> ba6f4d6ba...@o13g2000vbl.googlegroups.com>, sjdonnell...@gmail.com
> says...
>
> [ ... ]
>
> > >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1420.pdf
>
> [ ... ]
>
> > Since it is dated as 2003, it is unlikely that the proposal is
> > still active?  I'm a little surprised it didn't get accepted on
> > it's first attempt, considering the simplicity of implementation
> > and the obvious time savings.
>
> I'm not surprised at its lack of acceptance at all. To get a proposal
> accepted, especially later in the process of developing a new
> standard, the proposal should normally include specific information
> about how the wording of the standard should be changed -- the exact
> existing sections, and proposals for what the new wording should be.

It's dated 2003, so it wasn't exactly "later in the process". This was
the time when all the TR1 proposals came in (with proposed text, but
they were close to the TR). This was the time the very first paper on
decltype and auto was posted - without proposed text.

So whatever the reason for the rejection was, "too close to release
with insufficient work already done" can't have been it.

Sebastian


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

Steve Donnelly wrote:
> This proposal looks like a near-exact match for the concept I had in
> mind.
>
> Since it is dated as 2003, it is unlikely that the proposal is still
> active?  I'm a little surprised it didn't get accepted on it's first
> attempt, considering the simplicity of implementation and the obvious
> time savings.

I would also like to know the reason for rejection. I think anyone who
has done at least a bit of generic programming has noticed this problem.
In particular, I am surprised that the Boost people haven't raised their
voice over this matter.

I can offer a real-world example (the .htm postfix views the source with
coloring, remove it to view in ascii):

http://kaba.hilvi.org/Public_Files/unorderedbase.hpp.htm

I would be very glad if someone did something about this matter:)

--
http://kaba.hilvi.org

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

Has the standards group ever considered allowing namespace-like block
definitions of class members, external to their class definition?  To
illustrate what I mean, imagine we have the following namespace and
class:

namespace ns
{
    void func();
}

class type
{
   void method();
};

The definition of ns::func() can take one of the following two forms:

1)
// note: this namespace block is not assumed to be contiguous
//    with the one above
namespace ns
{
    void func() { /* do stuff */ }
}

2)
void ns::func() { /* do stuff */ }

The definition of type::method(), however, can only use the second
form of definition.  Note: I am ignoring the ability to define class
methods inside the class definition, because it typically forces the
methods to be inlined, and it inhibits using separate compilation
units.

2)
void type::method() { /* do stuff */ }

Given such a simple example, it's difficult to see why one prefer to
use the first form, since it involves slightly more typing and it
breaks func's complete, qualified name into separate parts.  However,
when defining multiple functions that reside within the same
namespace, the first form can often greatly cut back on duplicated
keystrokes as well as improve the code's readability and the ease of
refactoring.  This is especially true when using verbose and/or nested
namespaces.  For example:

(Form 1)
namespace really_long_namespace_name {
namespace inner_namespace {

// Ahh... :)
void func1() { }
void func2() { }
void func3() { }

} // end inner_namespace
} // end really_long_namespace_name


(Form 2)
void really_long_namespace_name::inner_namespace::func1() { }
void really_long_namespace_name::inner_namespace::func2() { }
// Ugh.... :(


The disadvantages of the second form more or less translate directly
to the way class members must be defined (if external to the class
definition).  It makes me wonder why, then, is form 1 allowed only for
namespaces and not classes.  Consider the following example:

//class definition
namespace ns1 {
namespace ns2 {

template <typename T, typename U, typename V> class
really_long_class_name
{
    void method1();
    void method2();
    ....
};

} } // end namespaces


// class method definitions
// fortunately, the namespaces can be factored out into a block
definition
namespace ns1 {
namespace ns2 {

// unfortunately, I have to retype this monstrous class prefix before
*every* method definition
template <typename T, typename U, typename V> class
really_long_class_name<T, U, V>::
method1() { /* do stuff */ }

template <typename T, typename U, typename V> class
really_long_class_name<T, U, V>::
method2() { /* do stuff */ }

...

} } // end namespaces


It seems rather silly and inconsistent to allow block definitions for
namespaces, but not classes, considering namespaces are essentially a
subset of class functionality.  A possible solution could be allowing
something like:

namespace ns1 {
namespace ns2 {

// - appending namespace to the end of the following line
differentiates it from a class definition,
// implying what's in the brackets can only define members already
declared inside the class
// - there are a number of ways this could be done, but this would
probably be the easiest to parse
template <typename T, typename U, typename V> class
really_long_class_name namespace {

void method1() { }
void method2() { }
...

} } } // end namespaces

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