www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - A module comprehensive template-specialization

reply Matthias Walter <xammy xammy.homelinux.net> writes:
Hi list,

I tried to write a traits class comparable to iterator_traits in C++ STL
or graph_traits in Boost Graph Library in D 2.0, but failed to do so via
template specialization which is put into different modules. Putting
everything into one module interferes with extensibility. I tried the
following:

== Module a ==
| module a;
|
| template Base (T)
| {
|   alias T Base;
| }

== Module b ==
| module b;
|
| import a;
|
| template Base(T: T*)
| {
|   alias Base !(T) Base;
| }

== Main module ==
|
|  import a, b;
|
| int main(char[][] args)
| {
|   alias Base !(int*) foo;
|
|   return 0;
| }

The error message is:
"bug.d(8): Error: template instance ambiguous template declaration
b.Base(T : T*) and a.Base(T)"

Can I handle this in another way (like making the template a conditional
one)?

best regards
Matthias Walter
Jun 27 2010
next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Matthias Walter <xammy xammy.homelinux.net> wrote:

 Can I handle this in another way (like making the template a conditional
 one)?

Template constraints[1] sounds like what you want. Basically, you want the following: == Module a == | module a; | | template Base (T) if (!is(T t : t*)) | { | alias T Base; | } == Module b == | module b; | | import a; | | template Base(T) if (is(T t : t*)) | { | alias Base !(T) Base; | } == Main module == | | import a, b; | | int main(char[][] args) | { | alias Base !(int*) foo; | | return 0; | } Not tested, ymmv. [1]: http://digitalmars.com/d/2.0/template.html#Constraint -- Simen
Jun 27 2010
prev sibling next sibling parent Justin Spahr-Summers <Justin.SpahrSummers gmail.com> writes:
On Sun, 27 Jun 2010 18:51:35 +0200, Matthias Walter 
<xammy xammy.homelinux.net> wrote:
 
 Hi list,
 
 I tried to write a traits class comparable to iterator_traits in C++ STL
 or graph_traits in Boost Graph Library in D 2.0, but failed to do so via
 template specialization which is put into different modules. Putting
 everything into one module interferes with extensibility. I tried the
 following:
 
 == Module a ==
 | module a;
 |
 | template Base (T)
 | {
 |   alias T Base;
 | }
 
 == Module b ==
 | module b;
 |
 | import a;
 |
 | template Base(T: T*)
 | {
 |   alias Base !(T) Base;
 | }
 
 == Main module ==
 |
 |  import a, b;
 |
 | int main(char[][] args)
 | {
 |   alias Base !(int*) foo;
 |
 |   return 0;
 | }
 
 The error message is:
 "bug.d(8): Error: template instance ambiguous template declaration
 b.Base(T : T*) and a.Base(T)"
 
 Can I handle this in another way (like making the template a conditional
 one)?
 
 best regards
 Matthias Walter

I believe this is intended behavior, as it prevents template hijacking and the like. Using alias to import the two templates into the same scope might help, though I'm not sure exactly how it should be done. On another note, though, have you looked at __traits() and std.traits?
Jun 28 2010
prev sibling next sibling parent Matthias Walter <xammy xammy.homelinux.net> writes:
On 06/28/2010 05:32 AM, Simen kjaeraas wrote:
 Matthias Walter <xammy xammy.homelinux.net> wrote:
 
 Can I handle this in another way (like making the template a conditional
 one)?

Template constraints[1] sounds like what you want. Basically, you want the following: == Module a == | module a; | | template Base (T) if (!is(T t : t*)) | { | alias T Base; | } == Module b == | module b; | | import a; | | template Base(T) if (is(T t : t*)) | { | alias Base !(T) Base; | } == Main module == | | import a, b; | | int main(char[][] args) | { | alias Base !(int*) foo; | | return 0; | } Not tested, ymmv. [1]: http://digitalmars.com/d/2.0/template.html#Constraint

The problem with constraints arises when I want to make an existing class (who's code I cannot modify) match a Concept, in which case I would just add another template specialization for this class. Here I would have to add further conditions to the template constraints, which would also mean to modify a library. A prominent example for Boost Graph Library is the LEDA graph class, which can be enabled to be used by BGL by more or less just specializing the graph_traits template. Any further ideas?
Jun 28 2010
prev sibling next sibling parent Matthias Walter <xammy xammy.homelinux.net> writes:
On 06/28/2010 09:49 AM, Justin Spahr-Summers wrote:
 On Sun, 27 Jun 2010 18:51:35 +0200, Matthias Walter 
 <xammy xammy.homelinux.net> wrote:
 Hi list,

 I tried to write a traits class comparable to iterator_traits in C++ STL
 or graph_traits in Boost Graph Library in D 2.0, but failed to do so via
 template specialization which is put into different modules. Putting
 everything into one module interferes with extensibility. I tried the
 following:

 == Module a ==
 | module a;
 |
 | template Base (T)
 | {
 |   alias T Base;
 | }

 == Module b ==
 | module b;
 |
 | import a;
 |
 | template Base(T: T*)
 | {
 |   alias Base !(T) Base;
 | }

 == Main module ==
 |
 |  import a, b;
 |
 | int main(char[][] args)
 | {
 |   alias Base !(int*) foo;
 |
 |   return 0;
 | }

 The error message is:
 "bug.d(8): Error: template instance ambiguous template declaration
 b.Base(T : T*) and a.Base(T)"

 Can I handle this in another way (like making the template a conditional
 one)?

 best regards
 Matthias Walter

I believe this is intended behavior, as it prevents template hijacking and the like. Using alias to import the two templates into the same scope might help, though I'm not sure exactly how it should be done.

I tried to do so in some variants but did not succeed unfortunately. If you have a precise idea, please let me know!
 
 On another note, though, have you looked at __traits() and std.traits?

I looked at them but didn't find them helpful for this precise problem. The whole reason for doing this is to make it possible to make another existing class model the concept (i.e. have some aliases / typedefs done) of my library class without editing any of them. As I mentioned in my other response, a prominent example for Boost Graph Library is the LEDA graph class, which can be enabled to be used by BGL by more or less just specializing the graph_traits template. I'd like to have this kind of technique available, too. Any further suggestions?
Jun 28 2010
prev sibling parent "Rory McGuire" <rmcguire neonova.co.za> writes:
On Mon, 28 Jun 2010 11:09:13 +0200, Matthias Walter  
<xammy xammy.homelinux.net> wrote:

 On 06/28/2010 09:49 AM, Justin Spahr-Summers wrote:
 On Sun, 27 Jun 2010 18:51:35 +0200, Matthias Walter
 <xammy xammy.homelinux.net> wrote:
 Hi list,

 I tried to write a traits class comparable to iterator_traits in C++  
 STL
 or graph_traits in Boost Graph Library in D 2.0, but failed to do so  
 via
 template specialization which is put into different modules. Putting
 everything into one module interferes with extensibility. I tried the
 following:

 == Module a ==
 | module a;
 |
 | template Base (T)
 | {
 |   alias T Base;
 | }

 == Module b ==
 | module b;
 |
 | import a;
 |
 | template Base(T: T*)
 | {
 |   alias Base !(T) Base;
 | }

 == Main module ==
 |
 |  import a, b;
 |
 | int main(char[][] args)
 | {
 |   alias Base !(int*) foo;
 |
 |   return 0;
 | }

 The error message is:
 "bug.d(8): Error: template instance ambiguous template declaration
 b.Base(T : T*) and a.Base(T)"

 Can I handle this in another way (like making the template a  
 conditional
 one)?

 best regards
 Matthias Walter

I believe this is intended behavior, as it prevents template hijacking and the like. Using alias to import the two templates into the same scope might help, though I'm not sure exactly how it should be done.

I tried to do so in some variants but did not succeed unfortunately. If you have a precise idea, please let me know!
 On another note, though, have you looked at __traits() and std.traits?

I looked at them but didn't find them helpful for this precise problem. The whole reason for doing this is to make it possible to make another existing class model the concept (i.e. have some aliases / typedefs done) of my library class without editing any of them. As I mentioned in my other response, a prominent example for Boost Graph Library is the LEDA graph class, which can be enabled to be used by BGL by more or less just specializing the graph_traits template. I'd like to have this kind of technique available, too. Any further suggestions?

I haven't looked at the boost stuff you mention but is it possible that using alias this, solves a similar or the same problem? TDPL addresses the use of aliasing to bring multiple declarations into the same scope/module but it only uses actual functions not templates.
Jun 28 2010