www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Template inheritances issue

reply Joey Peters <Joey_member pathlink.com> writes:
There seems to be a logical problem (again) with templates. It's not really D's
faulth. Imagine you have an array, right:






What happens here is that if the compiler want to make the intermediate output,
it will recursively create types for split. For instance, for Array!(int) split
would return Array!(Array!(int)), and that on it's turn again return
Array!(Array!(Array!(int))) on split.

Though! I think it's 'sort of important' to implement some sort of a 'don't do
it unless I ask for it' feature in the compiler, so that it would allow
recursive class template definitions. For instance, if I had pop on the array
(which they by standard do not), I could never make it work like this:

somearray.split(".").top()

because top would be a function of an array returned by split which is a
template of array which you cannot do because... recursivenes. (hope you're
still following ;))

The problem is, you never know when it's going to happen, and I think it's a
hard to fix issue. I haven't actually tried this in C++ but I suppose it would
work. C++ arrays sort of suck for not having split types and other thigns that
return arrays from arrays though ;).

For now, I'm not that concerned about it, I can fix it again hackish by
converting a base array type to a normal array type with another cast, as in the
likes of:

Array!(char[]) Initial = "something.exe";
Array!(Array!(char[])) Foo = Initial.split(".");
Foo.top() -> "exe"

Instead of

Initial.split(".").top(); // imposible ;_; LAMENT!
Sep 10 2004
parent reply Berin Loritsch <bloritsch d-haven.org> writes:
Joey Peters wrote:

 There seems to be a logical problem (again) with templates. It's not really D's
 faulth. Imagine you have an array, right:
 




 
 What happens here is that if the compiler want to make the intermediate output,
 it will recursively create types for split. For instance, for Array!(int) split
 would return Array!(Array!(int)), and that on it's turn again return
 Array!(Array!(Array!(int))) on split.
 
 Though! I think it's 'sort of important' to implement some sort of a 'don't do
 it unless I ask for it' feature in the compiler, so that it would allow
 recursive class template definitions. For instance, if I had pop on the array
 (which they by standard do not), I could never make it work like this:
 


 From a compiler perspective, this would be an error.  Not even a C++
compiler would be able to do something like this AS WRITTEN.  C++ gets
around this issue by separating out things like "split()" into an
external function.  That makes it something that is only parsed and
processed _as_needed_.  If you rewrote it so that you have your
Array!(T) class and a separate split() function it would behave like
you expect:

// or whatever the right syntax is...
Array!(Array!(T)) split(Array!(T)) {}

That way when you perform split it looks like this:

Array!(int) intArray = new Array!(int)();

Array!(Array!(int)) splitArray = split(intArray);


That is why C++ doesn't include a split function on the array itself (I
bet).
Sep 10 2004
parent Joey Peters <Joey_member pathlink.com> writes:
 From a compiler perspective, this would be an error.  Not even a C++
compiler would be able to do something like this AS WRITTEN.  C++ gets
around this issue by separating out things like "split()" into an
external function.  That makes it something that is only parsed and
processed _as_needed_.  If you rewrote it so that you have your
Array!(T) class and a separate split() function it would behave like
you expect:

// or whatever the right syntax is...
Array!(Array!(T)) split(Array!(T)) {}

That way when you perform split it looks like this:

Array!(int) intArray = new Array!(int)();

Array!(Array!(int)) splitArray = split(intArray);


That is why C++ doesn't include a split function on the array itself (I
bet).


Well yes, but I'd figure it could be a feature, simply by not forward
referencing templates (terms get sort of woozy when you're being very specific),
but only 'advance' if it's used. I can find a work around though.
Sep 10 2004