Templetized namespaces

[dgutson .]

Hi.

   I found a number of situations where the ability to templetize namespaces would be very useful.

My latest use case is this: I'm writing a library that is configured through a number of (non-type) template arguments. Such configuration affects to all the classes of the library. To be more specific, it's a fault-tolerant library for the aerospace industry where the whole library is tuned with some integers (some of then related to redundancy due to ionizing radiation).

The most natural thing would be to put all the classes in a namespace, and let the namespace be templetized with such arguments.

Moreover, a using namespace with the appropriate arguments would suffice for all the application. For example:

    using namespace TheLibrary<arg1, arg2, arg3>;

I didn't write the proposal yet, since I'd like to get some feedback.

Thanks,

   Daniel.

ps: The library will be available soon and uses template metaprogramming based on the arguments.

--
Who’s got the sweetest disposition?
One guess, that’s who?
Who’d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

[Andrew Tomazos]

Namespaces differ from classes in that they can be split within and amongst translation units.  The definition of a namespace is not required to be the same in different translation units.  Multiple namespace definitions of the same namespace in the same translation unit are logically merged into one (the first is called the original, the following are called extensions).

How do template namespace specialization and template namespace instantiation interact with these new properties that are not present in other template entities?

Also namespaces can contain the following declarations, whereas classes cannot:

explicit-instantiation

explicit-specialization

linkage-specification

namespace-definition

attribute-declaration

asm-definition

namespace-alias-definition

using-directive

opaque-enum-declaration

Now that all these are possible member declarations of a template entity, how are they handled?

Also you need to think about program initialization.  The members of a namespace have a bunch of rules about when they are initialized and in what order.  How will these rules interact with template namespace instances?

The best approach for this type of feature would be to put together an experimental compiler extension to gcc or clang that implements template namespaces.  This would shake out all the above issues (and likely more) which you could then use as the basis of a proposal.

[David Rodríguez Ibeas]

What are the shortcomings of using a class template as a poor-man's template?

I imagine that the first one is that it must be defined in a single header, so if the amount of code used internally is large enough it could make it hard to maintain.The syntax looks like a using-directive, do you also wish for the lookup changes associated with it? I imagine this to be the case, right? Can you use the same library in one program with different template arguments?

Can you provide a small code sample with how it would look like? 

--
 
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

[Richard Smith]

On Sun, Jan 19, 2014 at 10:16 AM, Andrew Tomazos <andrew...@gmail.com> wrote:

Namespaces differ from classes in that they can be split within and amongst translation units.  The definition of a namespace is not required to be the same in different translation units.  Multiple namespace definitions of the same namespace in the same translation unit are logically merged into one (the first is called the original, the following are called extensions).

How do template namespace specialization and template namespace instantiation interact with these new properties that are not present in other template entities?

Also namespaces can contain the following declarations, whereas classes cannot:

explicit-instantiation

explicit-specialization

linkage-specification

namespace-definition

attribute-declaration

asm-definition

namespace-alias-definition

using-directive

opaque-enum-declaration

Now that all these are possible member declarations of a template entity, how are they handled?

Also you need to think about program initialization.  The members of a namespace have a bunch of rules about when they are initialized and in what order.  How will these rules interact with template namespace instances?

The best approach for this type of feature would be to put together an experimental compiler extension to gcc or clang that implements template namespaces.  This would shake out all the above issues (and likely more) which you could then use as the basis of a proposal.

In addition to the above list, a proposal on this would need to consider whether namespace templates could support explicit specializations, partial specializations, and explicit instantiations (both for themselves and for their members).

 

On Sunday, January 19, 2014 6:26:57 PM UTC+1, dgutson . wrote:

Hi.

   I found a number of situations where the ability to templetize namespaces would be very useful.

My latest use case is this: I'm writing a library that is configured through a number of (non-type) template arguments. Such configuration affects to all the classes of the library. To be more specific, it's a fault-tolerant library for the aerospace industry where the whole library is tuned with some integers (some of then related to redundancy due to ionizing radiation).

The most natural thing would be to put all the classes in a namespace, and let the namespace be templetized with such arguments.

Moreover, a using namespace with the appropriate arguments would suffice for all the application. For example:

    using namespace TheLibrary<arg1, arg2, arg3>;

I didn't write the proposal yet, since I'd like to get some feedback.

I think this feature would have value, and seems worth putting before the committee.

 

Thanks,

   Daniel.

ps: The library will be available soon and uses template metaprogramming based on the arguments.

--
Who’s got the sweetest disposition?
One guess, that’s who?
Who’d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--

[Klaim - Joël Lamotte]

I had the exact same ideas few months ago after finding myself doing generic library which all types would depend on the same type,

and remarking how much duplication could be avoided if I was allowed to specify that a whole bunch of types would automatically have an additional template parameter implicitly.

namespace blah< typename X >

{

     class K {};

     template < class T > class U {};

}

would be translated to 

namespace blah

{

    template< typename X >

    class K {};

    template< typename X, class T > class U {};

}

However, after weeks of thinking about this I concluded that:

 1. namespace are not the appropriate construct for this, they really are too different and not really encapsulating anything than names;

 2. there are a lot of potential issues related to the order of template arguments;

 3. there is a potential issue for reading the code as you need to see the namespace declaration before being able to follow the rest of the code.

     What I mean here is basically the same argument that makes Clang developers avoid anonymous namespaces.

Also, I believe that the real thing I do want when I'm writing these generic libraries is actually to generate a whole bunch of types, using another type as argument of the process to generate the wanted types.

Basically, I want one of the features that the Reflection group is supposed to look for.

Since that realization, I think that efforts should be put to have a new reflection construct instead of making namespace do something too different from it's initial use.

[dgutson .]

On Sun, Jan 19, 2014 at 3:16 PM, Andrew Tomazos <andrew...@gmail.com> wrote:

Namespaces differ from classes in that they can be split within and amongst translation units.  The definition of a namespace is not required to be the same in different translation units.  Multiple namespace definitions of the same namespace in the same translation unit are logically merged into one (the first is called the original, the following are called extensions).

How do template namespace specialization and template namespace instantiation interact with these new properties that are not present in other template entities?

Also namespaces can contain the following declarations, whereas classes cannot:

explicit-instantiation

explicit-specialization

linkage-specification

namespace-definition

attribute-declaration

asm-definition

namespace-alias-definition

using-directive

opaque-enum-declaration

Now that all these are possible member declarations of a template entity, how are they handled?

Also you need to think about program initialization.  The members of a namespace have a bunch of rules about when they are initialized and in what order.  How will these rules interact with template namespace instances?

I understand that, in terms of a standard, all these considerations have to be taken into account. That's why I call for help here. Please note that the very concrete problem I'm referring to still holds and IMHO is relevant. I kindly invite you that, if you agree, begin drawing with me the possible rules for addressing all the points that you mentioned.

 

The best approach for this type of feature would be to put together an experimental compiler extension to gcc or clang that implements template namespaces.  This would shake out all the above issues (and likely more) which you could then use as the basis of a proposal.

Despite I was a gcc maintainer in the past, I don't have the resources for a full fledged implementation of this (specially since I mostly maintained the ARM backend). Nevertheless, I'll see what I can do with a plugin to get a proof-of-concept by using a template class to mimick the semantic of a template namespace. My initial idea is that the original template will be translated by the plugin as a base class, and the extensions as derived classes in a fixed order of inheritance.

But please, still consider my call for help while I manage to try a plugin like this.

Thanks,

   Daniel.

 

On Sunday, January 19, 2014 6:26:57 PM UTC+1, dgutson . wrote:

Hi.

   I found a number of situations where the ability to templetize namespaces would be very useful.

My latest use case is this: I'm writing a library that is configured through a number of (non-type) template arguments. Such configuration affects to all the classes of the library. To be more specific, it's a fault-tolerant library for the aerospace industry where the whole library is tuned with some integers (some of then related to redundancy due to ionizing radiation).

The most natural thing would be to put all the classes in a namespace, and let the namespace be templetized with such arguments.

Moreover, a using namespace with the appropriate arguments would suffice for all the application. For example:

    using namespace TheLibrary<arg1, arg2, arg3>;

I didn't write the proposal yet, since I'd like to get some feedback.

Thanks,

   Daniel.

ps: The library will be available soon and uses template metaprogramming based on the arguments.

--
Who’s got the sweetest disposition?
One guess, that’s who?
Who’d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--

 
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

[dgutson .]

On Tue, Jan 21, 2014 at 7:16 PM, David Rodríguez Ibeas <dib...@ieee.org> wrote:

What are the shortcomings of using a class template as a poor-man's template?

That was my original approach (and is my idea of the plugin I mentioned in my previous email).

Please read below.

 

I imagine that the first one is that it must be defined in a single header, so if the amount of code used internally is large enough it could make it hard to maintain.

That's one of the issues, though the workaround is an awful preprocessor hack of #including pieces within the class definition:

template <.....args...>

struct MyLibrary

{

    #include "part1.h"

...

    #include "part2.h"

};

Of course every reader of this list will feel the profound disgusting taste of this solution.

And even so, there's the 'using' problem: we cannot write

  using class MyLibrary<int, int, char, 25u>;

which clearly can be done with namespaces.

 

The syntax looks like a using-directive, do you also wish for the lookup changes associated with it?

Sure.

 

I imagine this to be the case, right? Can you use the same library in one program with different template arguments?

It is not my case. When you use "a" library, you use all of it as a single entity (despite library classes can be customized individually through templates too).

I don't foresee the need of instantiating the same library with different arguments.

 

Can you provide a small code sample with how it would look like? 

For exemplification, I will show an ongoing library we are developing (I insist it is heavily under development).

It's called robusto: robusto.googlecode.com

We are using it for undisclosed situations of ionizing radiation. The library (intentionally written in C++03 but useful for my example here, only for illustrative purposes) will provide a number of classes that provide sparse redundancy data. Two arguments rule the tuning of the library: the "distance" of the data, and the number of copies of each data (it's sparse since ionizing radiation has "regional" effects); the algorithms that apply to all the copies will be implemented with template metaprogramming (it's currently fixed in 3 copies). I'm not going to discuss here why such tuning configuration will apply for all the data types, nor any other reason of the library design. I'm bringing it here for the sake of the discussion.

I'd need  two things: 1) not to repeat all the two tuning configuration template arguments in all the classes, 2) be able to bring the classes of the specialized library to the scope that uses them with a using directive.

Exemplifying:

template <uint32_t Distance, uint32_t Copies>

namespace NSRobusto

{

    template <class T>

    class Class1

    {

        ...

    };

    template <class T>

    class Class2

    {

       ...

    };

}

// Then, in all the user-side code:

using namespace NSRobusto<4u, 3u>;

Class1<int> c1int;

Class2<char> c2char;

What happens if another translation unit instantiates the namespace with other arguments?

I think that c1int and c2char should be name-mangled according to the using namespace affecting them, so no linking clash should occur.

Please, get the token to continue the discussion :-) I already typed too much.

   Daniel.

[dgutson .]

On Tue, Jan 21, 2014 at 8:54 PM, Richard Smith <ric...@metafoo.co.uk> wrote:

On Sun, Jan 19, 2014 at 10:16 AM, Andrew Tomazos <andrew...@gmail.com> wrote:

Namespaces differ from classes in that they can be split within and amongst translation units.  The definition of a namespace is not required to be the same in different translation units.  Multiple namespace definitions of the same namespace in the same translation unit are logically merged into one (the first is called the original, the following are called extensions).

How do template namespace specialization and template namespace instantiation interact with these new properties that are not present in other template entities?

Also namespaces can contain the following declarations, whereas classes cannot:

explicit-instantiation

explicit-specialization

linkage-specification

namespace-definition

attribute-declaration

asm-definition

namespace-alias-definition

using-directive

opaque-enum-declaration

Now that all these are possible member declarations of a template entity, how are they handled?

Also you need to think about program initialization.  The members of a namespace have a bunch of rules about when they are initialized and in what order.  How will these rules interact with template namespace instances?

The best approach for this type of feature would be to put together an experimental compiler extension to gcc or clang that implements template namespaces.  This would shake out all the above issues (and likely more) which you could then use as the basis of a proposal.

In addition to the above list, a proposal on this would need to consider whether namespace templates could support explicit specializations, partial specializations, and explicit instantiations (both for themselves and for their members).

Maybe funny things could be done with this and template metaprogramming: template namespaces recursively instantiating themselves.

However, I'm not sure if new inventions would arise not done before with template classes.

[dgutson .]

On Wed, Jan 22, 2014 at 9:47 AM, Klaim - Joël Lamotte <mjk...@gmail.com> wrote:

I had the exact same ideas few months ago after finding myself doing generic library which all types would depend on the same type,

and remarking how much duplication could be avoided if I was allowed to specify that a whole bunch of types would automatically have an additional template parameter implicitly.

namespace blah< typename X >

{

     class K {};

     template < class T > class U {};

}

would be translated to 

namespace blah

{

    template< typename X >

    class K {};

    template< typename X, class T > class U {};

}

However, after weeks of thinking about this I concluded that:

 1. namespace are not the appropriate construct for this, they really are too different and not really encapsulating anything than names;

 2. there are a lot of potential issues related to the order of template arguments;

Please elaborate about the last two points.

 

 3. there is a potential issue for reading the code as you need to see the namespace declaration before being able to follow the rest of the code.

I don't find this issue different than any other template declaration, for example a nested class of a template class.

 

     What I mean here is basically the same argument that makes Clang developers avoid anonymous namespaces.

Also, I believe that the real thing I do want when I'm writing these generic libraries is actually to generate a whole bunch of types, using another type as argument of the process to generate the wanted types.

We agree on that.

 

Basically, I want one of the features that the Reflection group is supposed to look for.

I'm working on statement-templates.googlecode.com but that's something I will post in this list later.

 

Since that realization, I think that efforts should be put to have a new reflection construct instead of making namespace do something too different from it's initial use.

--
 
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

[con...@ncomputers.org]

Daniel,

I agree with you.

PF, ncomputers.org

[Klaim - Joël Lamotte]

Sorry I didn't see your reply before.

On Sun, Jan 26, 2014 at 1:52 AM, dgutson . <daniel...@gmail.com> wrote:

On Wed, Jan 22, 2014 at 9:47 AM, Klaim - Joël Lamotte <mjk...@gmail.com> wrote:

I had the exact same ideas few months ago after finding myself doing generic library which all types would depend on the same type,

and remarking how much duplication could be avoided if I was allowed to specify that a whole bunch of types would automatically have an additional template parameter implicitly.

namespace blah< typename X >

{

     class K {};

     template < class T > class U {};

}

would be translated to 

namespace blah

{

    template< typename X >

    class K {};

    template< typename X, class T > class U {};

}

However, after weeks of thinking about this I concluded that:

 1. namespace are not the appropriate construct for this, they really are too different and not really encapsulating anything than names;

 2. there are a lot of potential issues related to the order of template arguments;

Please elaborate about the last two points.

 

Basically, namespaces don't have a unique definition and are only affecting naming.

Therefore, what would be better to template would be something like a module or a class or a mixin (a class component).

 

 3. there is a potential issue for reading the code as you need to see the namespace declaration before being able to follow the rest of the code.

I don't find this issue different than any other template declaration, for example a nested class of a template class.

 

Yes, it's a weak point but apparently some people have trouble with this.

Not sure if it should be taken into account.

[con...@ncomputers.org]

I think that templetized templates should be allowed using nested namespaces by classes, for example:

template<typename Typename>
class A{
    namespace B{
        Typename Variable;
    }
};

PF, ncomputers

[rjwhi...@gmail.com]

Templetized is not a word. 

[Andrew Tomazos]

Neither is pedanitpicated.

[Jake Arkinstall]

Are you still interested in this proposal? I created a new post a few days ago and was pointed in the direction of this post. We can continue the discussion here or there - it's up to you. I have addressed a couple of the points made on this thread in my thread:

https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/templated$20namespaces/std-proposals/3MR8IhevevU/HQNEFn5fAwAJ