""Carl Daniel"" <cpdaniel@nospam.mvps.org> wrote in message
news:KoS_9.313$qZ.63@newssvr19.news.prodigy.com...
> ""Carl Daniel"" <cpdaniel@nospam.mvps.org> wrote in message
[snip]
>material to address the "namespace template" idea
> before submitting the proposal to the committee.  It's really an
> independent proposal, but the two are so closely related, and so
> synergistic in use that I agree that it makes sense to propose them as a
> set.

great :-)

I was wondering if the proposal shouldn't mention that using declarations
are allowed in the reopened namespace:

class X
{ ... };

class Y
{ ...  }

namespace class X
{
    using namespace std;
    ...
}

namespace class Y
{
    using namespace boost;
}

Maybe it could be added as an extra bullet at the end of section 2.1 ?

regards

Thorsten



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

"Kalle Olavi Niemitalo" <kon@iki.fi> wrote in message
news:87hebmg7tn.fsf@Astalo.y2000.kon.iki.fi...
> "David B. Held" <dheld@codelogicconsulting.com> writes:
>
> >     namespace template <typename C, typename C2>
> >     {
> >         inline typename mutable_return<C2>::iterator
> >         remove_copy(...)
> >         // ...
> >     }
>
> This construct appears to be similar to extern "C" { ... }; both
> specify attributes to be attached to all declarations within the
> braces.

This is a good observation that establishes precedent and perhaps
should be noted in the proposal.

> I would prefer either omitting the "namespace" keyword here,
> or also allowing it with extern.

I would argue that 'namespace' should stay for the same reason
we have:

extern "C" { ... }

and not:

"C" { ... }

As far as allowing it to be used with extern "C", I guess I am not
adamantly opposed, as it would introduce a type of nice
orthogonality:

namespace class Foo { ... }
namespace template <typename T> { ... }
namespace extern "C" { ... }

On the other hand, I think definition namespaces and extern "C"
declarations are siblings, not parent/child concepts.  After all,
both 'class' and 'enum' introduce a type, but we don't say:

class enum T { ... };

Dave


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

cpdaniel@nospam.mvps.org ("Carl Daniel") wrote

> See http://home.pacbell.net/cpbd/cppdocs/n1420.pdf for the text of the
> proposal that I'm preparing to submit to the committee, based on the
> recent threads on this ng.

"The page you have requested is not available. Please check the URL and try again"

> Please post any review comments here, or send them to me by email.

By hunting, I managed to find what is (apparently) your wedding
picture. I'm not sure that type of proposal is relevant to the
C++ standard, but:

You both look lovely.

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

""THORSTEN OTTOSEN"" <nesotto@cs.auc.dk> wrote in message
news:b1bulo$hd1$1@sunsite.dk...
[snip]
> "In contrast to class member functions, free-functions declared in
> namespaces incur no such textual overhead, since namespaces can be
re-opened
> at will, while classes are closed."
>
> I don't agree: if the functions are template functions, it might be quite
> tedious.

just to give an example of some code I have been writing recently for boost:


    template< typename Container1, typename Container2, typename T >
    inline typename mutable_return<Container2>::iterator
    remove_copy( const Container1& c1, Container2& c2, const T& value )
    {
        return std::remove_copy( begin( c1 ), end( c1 ), begin( c2 ),
value );
    }



    template< typename Container1, typename Container2, typename Predicate >
    inline typename mutable_return<Container2>::iterator
    remove_copy_if( const Container1& c1, Container2& c2, Predicate pred )
    {
        return std::remove_copy_if( begin( c1 ), begin( c1 ),
                                    begin( c2 ), pred );
    }

forward declaring this is a nightmare and implementation is verbose. Maybe
it would be possible to allow something like

template< typename C, typename C2 >
namespace boost
{
    inline typename mutable_return<C2>::iterator
    remove_copy(...)
{ ... }

// here I could define all the other algorithms that used the same to
template parameters
...
}

?

regards

Thorsten


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

""THORSTEN OTTOSEN"" <nesotto@cs.auc.dk> wrote in message
news:b1c3md$9g4$1@sunsite.dk...
> [...]
> template< typename C, typename C2 >
> namespace boost
> {
>     inline typename mutable_return<C2>::iterator
>     remove_copy(...)
> { ... }
>
> // here I could define all the other algorithms that used the same to
> template parameters
> ...
> }

The inconsistency here is how to create a "template namespace"
for the global namespace.  Whereas, this syntax:

namespace boost
{
    namespace template <typename C, typename C2>
    {
        inline typename mutable_return<C2>::iterator
        remove_copy(...)
        // ...
    }
}

Allows you define templates even in the global namespace.  As
far as the syntax for template classes, it could go either way.  This
syntax:

namespace template <typename C> class Foo
{
    // ...
}

is more consistent with the standalone template form, which may
be good or bad.  Whereas, this syntax:

template <typename T>
namespace class Foo
{
}

is more analogous to friend template declarations.  I wouldn't mind
either syntax.  However, one of the cases in which not having to
specify a namespace is useful is as follows:

template <..................>
class Foo
{
    template <conversion params>
    Foo(..., form1_tag);

    template <conversion params>
    Foo(..., form2_tag);

    template <conversion params>
    Foo(..., form3_tag);
};

namespace template <....................> class Foo
{
    namespace template <conversion params>
    {
        Foo(..., form1_tag)
        {
            // ...
        }
        Foo(..., form2_tag)
        {
            // ...
        }
        Foo(..., form2_tag)
        {
            // ...
        }
    }
}

Any time you have a lot of member template functions, it might be
convenient to be able to specify a template parameter namespace.
If you require a real namespace, this is not possible.

Dave



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

""THORSTEN OTTOSEN"" <nesotto@cs.auc.dk> wrote in message
news:b1bulo$hd1$1@sunsite.dk...
> I cite some of text and comment afterwards:
>
> "This situation creates a " Catch-22" for the template implementer: to
move
> member definitions out of line means a significant amount of extra
work,
> especially when template parameters change, but to leave member
definitions
> inline may cause unnecessary increases in code size, due to the
implicit
> inlining of those members"
>
> maybe one should mention that "code size" is not the only problem:
putting
> the implementation in the class definition removes the overview of the
> interface.

That's worth a mention - I'll add some appropriate text.

>
> "In contrast to class member functions, free-functions declared in
> namespaces incur no such textual overhead, since namespaces can be
re-opened
> at will, while classes are closed."
>
> I don't agree: if the functions are template functions, it might be
quite
> tedious.

This ties in directly with David B. Held's comment about template
namespaces.  Once I've had a chance to find & review the parts of the
thread that I've missed, I may try to better accomodate template
functions (member or otherwise).

>
> section 2.6: Incomplete nested classes: a small spelling error in code
> example

Thanks.  Already fixed in the latest version.

-cd

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

cpdaniel@nospam.mvps.org ("Carl Daniel") wrote in message news:<3_YZ9.591$kM2.67397748@newssvr21.news.prodigy.com>...
> See http://home.pacbell.net/cpbd/cppdocs/n1420.pdf for the text of the
> proposal that I'm preparing to submit to the committee, based on the
> recent threads on this ng.
>
> Please post any review comments here, or send them to me by email.
>
> -cd
>

Carl, this is an excellent proposal that I fully support, especially
if you add some accomodation for template namespaces as suggested by
David Held to complete the proposal.

One additional point that may bear mentioning is the fact that a class
already is a namespace, which adds to the ease with which this concept
will be assimilated.  It also ties in well with the historical usage
of a class as a namespace for groups of related static functions back
in the days before namespaces when this technique was used to simulate
a namespace.  So this proposal is thus an extension of a past
historical technique rather than something totally new.

Thanks for the effort put into this proposal and best of luck with it.
 :-)

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                       ]

""David B. Held"" <dheld@codelogicconsulting.com> wrote in message
news:v3impacli4qd6b@corp.supernews.com...
> I like it for the most part, but am a little disappointed to see that
you
> abandoned "template namespaces".  It happens that in a lot of
template-
> heavy code, you end up with a lot of non-member template functions
> (usually operators).  Having to repeat the template parameters in
those
> cases seems to be an oversight of the proposal.  I hope you'll either
> reconsider adding them to your proposal, or justify their absence.

I didn't so much abandon that concept as failed to include it since I
wasn't aware of it (my NNTP feed lost a bunch of comp.std.c++, so I
think I missed out on a good part of the discussion).

I understand what you're proposing (in general terms).  My gut reaction
is that it's a separate, orthogonal proposal, but perhaps there's enough
synergy with re-opening classes that the two belong in a single
proposal.   I need to review all the parts of the thread that I missed,
then try to put the two ideas together into one proposal.  I'm trying to
get this proposal written & into the committee before the 03/03/03
deadline for the next mailing, so I don't want to let the scope creep up
any more than necessary...

Thanks for bringing it to my attention.

-cd

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

Carl Daniel wrote:
> See http://home.pacbell.net/cpbd/cppdocs/n1420.pdf
Error 404
--
www.c-plusplus.de
Das deutsche C++ Forum

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

""Carl Daniel"" <cpdaniel@nospam.mvps.org> wrote in message
news:3_YZ9.591$kM2.67397748@newssvr21.news.prodigy.com...
> See http://home.pacbell.net/cpbd/cppdocs/n1420.pdf for the text of the
> proposal that I'm preparing to submit to the committee, based on the
> recent threads on this ng.

The download URL has changed, it's now

http://home.pacbell.net/cpbd/cppdocs/d1420.pdf

The name change is to emphasize/clarify that this is not (yet) an
official proposal, and won't be until it's distributed as an official
committee document in an upcoming mailing.

I will be adding material to address the "namespace template" idea
before submitting the proposal to the committee.  It's really an
independent proposal, but the two are so closely related, and so
synergistic in use that I agree that it makes sense to propose them as a
set.

-cd


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

Carl Daniel wrote:

> See http://home.pacbell.net/cpbd/cppdocs/n1420.pdf for the text of the
> proposal that I'm preparing to submit to the committee, based on the
> recent threads on this ng.

I like it, but have you considered allowing the class-namespaces to
include new declarations not known in the class definition proper ?

Like this:

        #include <list>

        template<T>
        namespace list {
                void my_list_function() { ... }
        };

        int main() {
                list<int> l;

                l.my_list_function();
        }

The BETA language allows such extensions of existing classes and in
my opinion its a very usefull feature as it frees the programmer from
a lot of work, when he just want to add a few functions to an already
existing class.

        -Claus

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

"David B. Held" <dheld@codelogicconsulting.com> writes:

>     namespace template <typename C, typename C2>
>     {
>         inline typename mutable_return<C2>::iterator
>         remove_copy(...)
>         // ...
>     }

This construct appears to be similar to extern "C" { ... }; both
specify attributes to be attached to all declarations within the
braces.  I would prefer either omitting the "namespace" keyword
here, or also allowing it with extern.

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

See http://home.pacbell.net/cpbd/cppdocs/n1420.pdf for the text of the
proposal that I'm preparing to submit to the committee, based on the
recent threads on this ng.

Please post any review comments here, or send them to me by email.

-cd

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

""Carl Daniel"" <cpdaniel@nospam.mvps.org> wrote in message
news:3_YZ9.591$kM2.67397748@newssvr21.news.prodigy.com...
> See http://home.pacbell.net/cpbd/cppdocs/n1420.pdf for the text of the
> proposal that I'm preparing to submit to the committee, based on the
> recent threads on this ng.
>
> Please post any review comments here, or send them to me by email.

I like it for the most part, but am a little disappointed to see that you
abandoned "template namespaces".  It happens that in a lot of template-
heavy code, you end up with a lot of non-member template functions
(usually operators).  Having to repeat the template parameters in those
cases seems to be an oversight of the proposal.  I hope you'll either
reconsider adding them to your proposal, or justify their absence.

Dave


---
[ 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 cite some of text and comment afterwards:

"This situation creates a " Catch-22" for the template implementer: to move
member definitions out of line means a significant amount of extra work,
especially when template parameters change, but to leave member definitions
inline may cause unnecessary increases in code size, due to the implicit
inlining of those members"

maybe one should mention that "code size" is not the only problem: putting
the implementation in the class definition removes the overview of the
interface.

"In contrast to class member functions, free-functions declared in
namespaces incur no such textual overhead, since namespaces can be re-opened
at will, while classes are closed."

I don't agree: if the functions are template functions, it might be quite
tedious.

section 2.6: Incomplete nested classes: a small spelling error in code
example

regards

Thorsten


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