220 8810 article Path: news.gmane.org!not-for-mail From: "dgutson ." Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Templetized namespaces Date: Sat, 25 Jan 2014 22:44:56 -0200 Lines: 481 Approved: news@gmane.org Message-ID: References: <4cfc2db6-97da-4750-9296-5aaaa3475014@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=e89a8ff1cc026cb46704f0d4e646 X-Trace: ger.gmane.org 1390697091 13459 80.91.229.3 (26 Jan 2014 00:44:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Jan 2014 00:44:51 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDE3NBMV6UFBBCVVSGLQKGQEE6DWWWQ@isocpp.org Sun Jan 26 01:45:00 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-bk0-f72.google.com ([209.85.214.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W7DqN-0002bw-RY for gclcip-std-proposals@m.gmane.org; Sun, 26 Jan 2014 01:44:59 +0100 Original-Received: by mail-bk0-f72.google.com with SMTP id mx11sf8059713bkb.7 for ; Sat, 25 Jan 2014 16:44:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=N2HnkEzBelli/6R9E9c8eg92kRT2ulRsHPmx6AYA8tI=; b=GC610dR5WpfCR29wRjjqAEyU0WHTQGj8XVJw7veiEKmIQCyRN1ZHfGPqgjq+il2gxU d8JXtdfRv2TqkhJWeysY0i1OgrukGc8WwKsw7BmZVFWZ3LC8x+MS/Gz2uI+yRe9Gc1vf NUZ5iaLxEpHVc+NNoZYDYja6Z634JDjAlgsS0G/ceMqIDFKGnWQWZ2nZSKF5aQ95eTqk KmNT2TkZj2WkynbVFum5g9B3FKuSXUvutG+Iq8oknmzhQF+vnCRl3u+4dI8Qjpw6iSE0 SqEzThk+OkNUwCYk3CUJquKE59tuh1J5UacsuVVfMTiM8ARZeKTLz4m72VaJlXWlVLHJ BEzQ== X-Gm-Message-State: ALoCoQnDppPwifYr6LWTSj7mQnVB4/hNOqSfuCzCq5mvCn5+8RSi18kWX1hnF5o1w/n9Tod6LgJV X-Received: by 10.204.198.16 with SMTP id em16mr5781440bkb.5.1390697099392; Sat, 25 Jan 2014 16:44:59 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.218.195 with SMTP id pi3ls1006wic.43.canary; Sat, 25 Jan 2014 16:44:58 -0800 (PST) X-Received: by 10.204.122.193 with SMTP id m1mr42630bkr.92.1390697098370; Sat, 25 Jan 2014 16:44:58 -0800 (PST) Original-Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [2607:f8b0:400e:c01::234]) by mx.google.com with ESMTPS id og3si8536965bkb.279.2014.01.25.16.44.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Jan 2014 16:44:58 -0800 (PST) Received-SPF: pass (google.com: domain of danielgutson@gmail.com designates 2607:f8b0:400e:c01::234 as permitted sender) client-ip=2607:f8b0:400e:c01::234; Original-Received: by mail-pb0-f52.google.com with SMTP id jt11so4615284pbb.11 for ; Sat, 25 Jan 2014 16:44:56 -0800 (PST) X-Received: by 10.68.189.132 with SMTP id gi4mr22401686pbc.57.1390697096457; Sat, 25 Jan 2014 16:44:56 -0800 (PST) Original-Received: by 10.70.78.200 with HTTP; Sat, 25 Jan 2014 16:44:56 -0800 (PST) In-Reply-To: X-Original-Sender: danielgutson@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of danielgutson@gmail.com designates 2607:f8b0:400e:c01::234 as permitted sender) smtp.mail=danielgutson@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:8810 Archived-At: --e89a8ff1cc026cb46704f0d4e646 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 21, 2014 at 7:16 PM, David Rodr=C3=ADguez Ibeas 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; 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 namespace NSRobusto { template class Class1 { ... }; template class Class2 { ... }; } // Then, in all the user-side code: using namespace NSRobusto<4u, 3u>; Class1 c1int; Class2 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. > > > On Sun, Jan 19, 2014 at 1:16 PM, Andrew Tomazos = wrote: > >> Namespaces differ from classes in that they can be split within and >> amongst translation units. The definition of a namespace is not require= d >> 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 followi= ng >> 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-speci=EF=AC=81cation >> namespace-de=EF=AC=81nition >> attribute-declaration >> asm-de=EF=AC=81nition >> namespace-alias-de=EF=AC=81nition >> 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 w= hat >> 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. >> >> 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 libra= ry >>> 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 suffic= e >>> for all the application. For example: >>> >>> using namespace TheLibrary; >>> >>> 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 metaprogrammin= g >>> based on the arguments. >>> >>> >>> -- >>> Who=E2=80=99s got the sweetest disposition? >>> One guess, that=E2=80=99s who? >>> Who=E2=80=99d 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 Group= s >> "ISO C++ Standard - Future Proposals" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to std-proposals+unsubscribe@isocpp.org. >> To post to this group, send email to std-proposals@isocpp.org. >> Visit this group at >> http://groups.google.com/a/isocpp.org/group/std-proposals/. >> > > -- > > --- > 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-proposals+unsubscribe@isocpp.org. > To post to this group, send email to std-proposals@isocpp.org. > Visit this group at > http://groups.google.com/a/isocpp.org/group/std-proposals/. > --=20 Who=E2=80=99s got the sweetest disposition? One guess, that=E2=80=99s who? Who=E2=80=99d 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? --=20 ---=20 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 e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --e89a8ff1cc026cb46704f0d4e646 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Jan 21, 2014 at 7:16 PM, David Rodr=C3=ADguez Ibeas <dibeas@= ieee.org> wrote:
What are the shortcomings of using a clas= s template as a poor-man's template?

That was my original approach (and is my i= dea of the plugin I mentioned in my previous email).
Please read = below.
=C2=A0

I imagine that the first one is that i= t must be defined in a single header, so if the amount of code used interna= lly 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 M= yLibrary
{
=C2=A0 =C2=A0 #include "part1.h"
...
=C2=A0 =C2=A0 #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: w= e cannot write
=C2=A0 using class MyLibrary<int, int, char, 25= u>;

which clearly can be done with namespaces.<= /div>

=C2=A0
The = syntax looks like a using-directive, do you also wish for the lookup change= s associated with it?

Sure.
=C2=A0
I imagine this to be the case, right? Can you use th= e same library in one program with different template arguments?

It is not my case. When you use "a&q= uot; 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 di= fferent arguments.
=C2=A0

Can you provide a small code sample with how it would l= ook like?=C2=A0

For exempli= fication, I will show an ongoing library we are developing (I insist it is = heavily under development).
It's called robusto: rob= usto.googlecode.com
We are using it for undisclosed situation= s of ionizing radiation. The library (intentionally written in C++03 but us= eful for my example here, only for illustrative purposes) will provide a nu= mber of classes that provide sparse redundancy data. Two arguments rule the= tuning of the library: the "distance" of the data, and the numbe= r of copies of each data (it's sparse since ionizing radiation has &quo= t;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 desi= gn. I'm bringing it here for the sake of the discussion.
I'd need =C2=A0two things: 1) not to repeat all the two tuning con= figuration template arguments in all the classes, 2) be able to bring the c= lasses of the specialized library to the scope that uses them with a using = directive.

Exemplifying:

template <uin= t32_t Distance, uint32_t Copies>
namespace NSRobusto
{
=C2=A0 =C2=A0 template <class T>
=C2=A0 =C2=A0= class Class1
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
= =C2=A0 =C2=A0 };

=C2=A0 =C2=A0 template <class = T>
=C2=A0 =C2=A0 class Class2
=C2=A0 =C2=A0 {
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 };
}

// Then, in all the user-side code:
using namespace NSRobusto<= 4u, 3u>;

Class1<int> c1int;
Cla= ss2<char> c2char;

What happens if another tr= anslation 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 t= oo much.

=C2=A0 =C2=A0Daniel.
=C2=A0


On Sun, Jan 19, 2014 at 1:16 PM, Andr= ew Tomazos <andrewtomazos@gmail.com> wrote:
Namespaces differ from classes in that th= ey can be split within and amongst translation units. =C2=A0The definition = of a namespace is not required to be the same in different translation unit= s. =C2=A0Multiple namespace definitions of the same namespace in the same t= ranslation unit are logically merged into one (the first is called the orig= inal, the following are called extensions).

How do template namespace specialization and template namesp= ace instantiation interact with these new properties that are not present i= n other template entities?

Also namespaces can con= tain the following declarations, whereas classes cannot:

explicit-instantiation
explicit-spec= ialization
linkage-speci=EF=AC=81cation
namespace-de=EF= =AC=81nition
attribute-declaration
asm-de=EF=AC=81n= ition
namespace-alias-de=EF=AC=81nition
using-directive
o= paque-enum-declaration

Now that all thes= e are possible member declarations of a template entity, how are they handl= ed?

Also you need to think about program initialization. = =C2=A0The members of a namespace have a bunch of rules about when they are = initialized and in what order. =C2=A0How will these rules interact with tem= plate namespace instances?

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

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

=C2=A0 =C2=A0I found a number of situations where th= e ability to templetize namespaces would be very useful.

My latest use case is this: I'm writing a library that is config= ured 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 i= s tuned with some integers (some of then related to redundancy due to ioniz= ing 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 s= uffice for all the application. For example:

=C2=A0 =C2=A0 using namespace TheLibrary<arg1, arg2,= arg3>;

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

Thanks,

=C2=A0 =C2=A0Daniel.

ps: The librar= y will be available soon and uses template metaprogramming based on the arg= uments.


--
Who=E2=80=99s got= the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argume= nt?
Who never shows a bit of temperament?
Who's never wrong but a= lways right?
Who'd never dream of starting a fight?
Who get stuck= with all the bad luck?=20

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

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



--
= Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s wh= o?
Who=E2=80=99d 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 ba= d luck?=20

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