www.digitalmars.com         C & C++   DMDScript  

D - C and/or C++ in D

reply "Ben Woodhead" <zander echotech.ca> writes:
Hello Everybody

I have been reading this newsgroup for quite some time and I am starting to
get worried. People have to stop looking at how am I going to do this c or
C++ feature in D and start looking at it from what is the best why to do
this.

The one comment I see a lot in this newsgroup is can you implement this
feature from c or c++. If you want c++ the use it. I like C++ a lot. But its
not a nice language (no affence to the creators). Its a very powerful
language. Don't mistake the 2 things.

You are using c++ because its powerful, not because its a nice. You have
learned to like c++, and you did that because of the power. When you started
do you really think that you were saying stuff like "wow, this is the best
way to handle strings, and I really like these pointers". You might like
them now.

As it is I have see a few feature that (although needed/wanted by the c++
community) were not in the design that were put in (i.e. templates). I liked
Walters original plan of not putting it in. Java does fine without it.

Please stop being c++ programmers using d. If you want one macro that has
not been talked about yet. Don't worry its still in c++. Or if you want
templates they are still in c++, or you want to remove string handling or
dynamic arrays don't worry they are not in c++. There is only a small amount
of c++ used by everything, so before you ask the question "Can you put this
feature in" ask yourself a few questions:

1. Does anybody else actually use this? If its not in walters design then
chances are not everybody.
2. Is there another way to do this? There usually is.
3. Is the way that I want really a good way or is it just some *ugly* thing
that I got comformable with.

One possible way to do this, is instead of coming to the list with your c++
code and saying this is something that is needed, perhaps you should say
"this is what I am trying to do and here is they way I would do it in c++,
anybody have any ideas on how to do this in D".

Thanks, Ben
Jan 14 2003
next sibling parent reply "Kwan Ting" <me here.com> writes:
Hi, I've been reading the group for quite some time as well but
haven't contributed coz my knowledge in programming is limited. So,
here's go my first post in this group.

Ben, you've made a very valued point there. Of course with a new
language, one should think in terms of the features of the new
language and not that I did it this way before, how do I do it now. On
the other hand, some features that are not use by everybody are still
necessary if D is to be a successor to C and C++. One such example is
templates which is pretty important for generic programming.

Kwan Ting
        - just some comments from me.

--
To everyone is given the key to the gates of heaven, but the same key
opens the gate of hell.
Jan 14 2003
next sibling parent "Ben Woodhead" <zander echotech.ca> writes:
Hello

Templates have there uses, but they are something you have to get use to.
There has to be an approach that allows for the same generality without the
need for templates. Java has lived quite well without it, and it is being
used for some big projects. Thanks for the responce.

Later, Ben

"Kwan Ting" <me here.com> wrote in message
news:b0284i$1uud$1 digitaldaemon.com...
 Hi, I've been reading the group for quite some time as well but
 haven't contributed coz my knowledge in programming is limited. So,
 here's go my first post in this group.

 Ben, you've made a very valued point there. Of course with a new
 language, one should think in terms of the features of the new
 language and not that I did it this way before, how do I do it now. On
 the other hand, some features that are not use by everybody are still
 necessary if D is to be a successor to C and C++. One such example is
 templates which is pretty important for generic programming.

 Kwan Ting
         - just some comments from me.

 --
 To everyone is given the key to the gates of heaven, but the same key
 opens the gate of hell.
Jan 14 2003
prev sibling parent reply "Ben Woodhead" <zander echotech.ca> writes:
Hello, I have a few questions. Perhaps someone can help me out.

What is the purpose in generic programming?
What problems does it solve?
Is that problem a language problem?
How does Java live without it?

Ben

"Kwan Ting" <me here.com> wrote in message
news:b0284i$1uud$1 digitaldaemon.com...
 Hi, I've been reading the group for quite some time as well but
 haven't contributed coz my knowledge in programming is limited. So,
 here's go my first post in this group.

 Ben, you've made a very valued point there. Of course with a new
 language, one should think in terms of the features of the new
 language and not that I did it this way before, how do I do it now. On
 the other hand, some features that are not use by everybody are still
 necessary if D is to be a successor to C and C++. One such example is
 templates which is pretty important for generic programming.

 Kwan Ting
         - just some comments from me.

 --
 To everyone is given the key to the gates of heaven, but the same key
 opens the gate of hell.
Jan 14 2003
next sibling parent reply Niall Douglas <Niall_member pathlink.com> writes:
In article <b02uv8$2cnb$1 digitaldaemon.com>, Ben Woodhead says...
Hello, I have a few questions. Perhaps someone can help me out.
I might be able to. I disagree fundamentally with OO and through my arguments with OO gurus, I've learned a lot (though not been convinced I'm wrong!) :)
What is the purpose in generic programming?
What problems does it solve?
Is that problem a language problem?
How does Java live without it?
Firstly, I don't think Java does live without it. It's like operator overloading - Sun just removed it completely. Operator overloading, when used correctly, actually produces far more reliable, intuitive and thus bug-free code. I'll just outline what it is for those not familiar with these things, then say why it was incorporated. Now if for example I want a list object which maintains a list of another object, in Java I'd use a dual object approach - there'd be a list item object which would be the base class of all items to be placed in the list and then the list would manage those subclasses of the list item object. Using templates, you specify the list object as taking one or more parameters ie; it's like a mould used to "stamp" out objects. So if I want a list of string objects, it's class list<string> and equally class list<class<string>> works too (a list of lists of string). The point is with templates you write the class guts once, and the parameters determine the actual implementation. If you're familiar with C, then most use of parameterised macros can be replaced with templates eg; #define ADD(type) \ { return a + b; } In templates becomes: template<class type> type Add(type a, type b) { return a + b; } The great problem I see with C++ templates is they are limited to type parameters. I'd personally like to see free-form parameters. You may be asking what can templates let me do other approaches cannot? In Java, I don't think there are any - Java stores lengthy meta-data about all its data constructs so the language always knows what type some data is and thus how to work with it. In a static system like C++, there is no knowledge of data type except at time of compilation - hence "new X" is useless unless X's type is immediately known. Templates are the way of implementing multi-type generic code without requiring a run-time system. BTW if you're thinking fine, let's add a run-time system - well, that's why objective C failed in competing against C++. Nowadays you may get away with it, One other point is that Java's solution to the above problems would require more code than in C++. Using abstract base classes to generalise objects to some collection class is fine but it really needs multiple inheritance to be useful. I think the most productive future for D would be to remain as a primarily static system, though I wouldn't mind seeing optional dynamic features like ObjC has. Cheers, Niall
Jan 15 2003
next sibling parent reply "Lars Ivar Igesund" <larsivi stud.ntnu.no> writes:
My first post to this newsgroup, so hi everyone!

 Now if for example I want a list object which maintains a list of another
 object, in Java I'd use a dual object approach - there'd be a list item
object
 which would be the base class of all items to be placed in the list and
then the
 list would manage those subclasses of the list item object.
I am no fan of Java and might even completely misunderstand what you mean, but in Java and (as far as I can see) D, all classes inherits from a class Object. This means that some sort of list programmed around the Object class can include ALL types of object since they explicitly or implicitly inherits Object. When dealing with lists, the only need I can see for templates, is when making lists of some general approach but should store only one type of objects. (Maybe for performance reasons?) Since I've never come over this issue, I've never needed templates in Java. Please tell me if there are other needs for templates that cannot be solved in Java or a template free D. I am always eager to learn :) Lars Ivar
Jan 15 2003
next sibling parent Niall Douglas <Niall_member pathlink.com> writes:
In article <b03cek$2lv8$1 digitaldaemon.com>, Lars Ivar Igesund says...

I am no fan of Java and might even completely misunderstand what you mean,
but in Java and (as far as I can see) D, all classes inherits from a class
Object.
This means that some sort of list programmed around the Object class can
include ALL types of object since they explicitly or implicitly inherits
Object.
True, but such lists can only be basic collections. If you wanted a sorted list for example, you'd need some sort of comparison method. In C++, you'd overload the < operator and you could have as many different types in the list as < operator overloads exist. It's more intuitive.
When dealing with lists, the only need I can see for templates, is when
making
lists of some general approach but should store only one type of objects.
(Maybe
for performance reasons?) Since I've never come over this issue, I've never
needed
templates in Java.

Please tell me if there are other needs for templates that cannot be solved
in Java
or a template free D. I am always eager to learn :)
Well as I said in my original post, Java stores type information with its data whereas C++ does not. Thus Java always knows what to do with an unknown type whereas C++ can not. Thus, C++ needs extra features to account for this. I still think free form templates are useful in any language in their own right, just as C macros are useful (though unhealthy). Cheers, Niall
Jan 16 2003
prev sibling parent reply Daniel Yokomiso <Daniel_member pathlink.com> writes:
In article <b03cek$2lv8$1 digitaldaemon.com>, Lars Ivar Igesund says...
My first post to this newsgroup, so hi everyone!

 Now if for example I want a list object which maintains a list of another
 object, in Java I'd use a dual object approach - there'd be a list item
object
 which would be the base class of all items to be placed in the list and
then the
 list would manage those subclasses of the list item object.
I am no fan of Java and might even completely misunderstand what you mean, but in Java and (as far as I can see) D, all classes inherits from a class Object. This means that some sort of list programmed around the Object class can include ALL types of object since they explicitly or implicitly inherits Object. When dealing with lists, the only need I can see for templates, is when making lists of some general approach but should store only one type of objects. (Maybe for performance reasons?) Since I've never come over this issue, I've never needed templates in Java. Please tell me if there are other needs for templates that cannot be solved in Java or a template free D. I am always eager to learn :) Lars Ivar
Hi, Generics are used to allow type-safe programming. If you read type theory articles or books (I recommend Luca Cardelli papers. There is also a good column about classification theory in the Journal of Object Technology www.jot.fm) you'll see that there are two classes of operations: those defined on types (e.g. addition is defined for numeric types) and those defined on sets or types, aka kinds or meta-types (e.g.: minimum is a operation defined for every type that has a binary comparison operator). If you want type safety, we need to define methods that work only for certain types. With overloading in D we can define: int min(int left, int right) { return left < right ? left : right; } float min(float left, float right) { return left < right ? left : right; } char min(char left, char right) { return left < right ? left : right; } which are always type correct. Using function generators, we can define a function, that given a type will return a function specialized for the given type. D's template mechanism can be used as a function generator. T fun(T,T) TMin(type T) { return T fun(T left, T right) { return left < right ? left : right; } } using template syntax: template TMin(T) { return T min(T left, T right) { return left < right ? left : right; } } So this template is a function generator. Most OO languages provide a equality operation defined for type Object, so any object can be compared to any object, and possibly be equal. If we want to perform some value equality test in our objects, we need to redefine the equal(Object) method using runtime type information (e.g.: instanceof and cast operators in Java) to recover the type lost. That means: cast the other object to my type, if it's ok, use all operations (methods or attribute selection) to compare we two, else return false. This allows heteregenous collections be defined (e.g. Lists or Sets with Object type in its methods). With templates we can define function or class generators that create specialized classes for the type parameter we give it. If you define a Matrix type in Java you need to decide which kind of type you will work with (choose one of the primitives, or Number, or Integer, or something else). The code written and tested for you Matrix of double class will be useless if your user want a Matrix of Complex instead. Current state of art makes usage of a Matrix of Number be worse (one or more orders) than using primitives, due to vtables and all this inheritance stuff. This may be done with inheritance only, if you want to force your users to always inherit from a particular class. But on some problem domains it's not plausible to force them. Look at Java's nio Buffer classes. The generic Buffer interface doesn't define get and put operations, because those are type-sensitive, instead it relies on documentation to enforce this. Any usage of Java's collection classes force's you to cast everything you put inside the collections when you get it back. There is nothing that Java or a template free D can't do without templates. They're Turing complete ;-) But there are lots of thing that are really awkward to do, and some of these casts will bite you someday, specially in large programs (I've got one yesterday when one of my objects put something in a container but the other expected something different. The fun thing is that I needed tests to discover this, because the compiler thinks casts are nice). Best regards, Daniel Yokomiso.
Jan 16 2003
parent reply Burton Radons <loth users.sourceforge.net> writes:
Daniel Yokomiso wrote:
 which are always type correct. Using function generators, we can define a
 function, that given a type will return a function specialized for the given
 type. D's template mechanism can be used as a function generator.
 
 T fun(T,T) TMin(type T) {
 return T fun(T left, T right) {
 return left < right ? left : right;
 }
 }
 
 using template syntax:
 
 template TMin(T) {
 return T min(T left, T right) {
 return left < right ? left : right;
 }
 }
The template method I suggested a long time ago would use: $T min ($T left, $T right) { return left < right ? left : right; } When applied to an argument name they mean a value that is trivially constfolded, so "(ClassInfo $a, TypeInfo $b)" fall into a special rule very nicely.
Jan 16 2003
parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Burton Radons" <loth users.sourceforge.net> escreveu na mensagem
news:3E26F644.9090506 users.sourceforge.net...
 Daniel Yokomiso wrote:
 which are always type correct. Using function generators, we can define
a
 function, that given a type will return a function specialized for the
given
 type. D's template mechanism can be used as a function generator.

 T fun(T,T) TMin(type T) {
 return T fun(T left, T right) {
 return left < right ? left : right;
 }
 }

 using template syntax:

 template TMin(T) {
 return T min(T left, T right) {
 return left < right ? left : right;
 }
 }
The template method I suggested a long time ago would use: $T min ($T left, $T right) { return left < right ? left : right; }
I don't think I've read about them. Do you remember the date of the posts, so I can search them? I'm too lazy to just search everything manually ;-)
 When applied to an argument name they mean a value that is trivially
 constfolded, so "(ClassInfo $a, TypeInfo $b)" fall into a special rule
 very nicely.
Perhaps I'm just tired but I don't understand what you mean by that. Please enlighten me. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.443 / Virus Database: 248 - Release Date: 11/1/2003
Jan 17 2003
parent reply Burton Radons <loth users.sourceforge.net> writes:
Daniel Yokomiso wrote:
 "Burton Radons" <loth users.sourceforge.net> escreveu na mensagem
 news:3E26F644.9090506 users.sourceforge.net...
 
Daniel Yokomiso wrote:

which are always type correct. Using function generators, we can define
a
function, that given a type will return a function specialized for the
given
type. D's template mechanism can be used as a function generator.

T fun(T,T) TMin(type T) {
return T fun(T left, T right) {
return left < right ? left : right;
}
}

using template syntax:

template TMin(T) {
return T min(T left, T right) {
return left < right ? left : right;
}
}
The template method I suggested a long time ago would use: $T min ($T left, $T right) { return left < right ? left : right; }
I don't think I've read about them. Do you remember the date of the posts, so I can search them? I'm too lazy to just search everything manually ;-)
"Generics in D", starting on 24/06/2002. It's a simple syntax, just puts C++'s basic syntax inside the language instead of as a layer. Here's the body of my description of it: For generic functions and generic class methods, a "$" followed by an identifier in the place where a type would exist indicates a generic type. The specific type of this generic is determined by the first argument using it; a function cannot return a generic type only. For example: $type foo ($type a, $type b) $type bar (int c); /* Illegal */ complex x = foo (4, 2.3); /* Returns int and casts 2.3 to int */ Generic values are also prefixed with a $ and must be trivially constant. Generic values of type "TypeInfo" or "ClassInfo" are special in that they can be used both as a value and a generic type, and if so must be the first argument to use this generic value: $type cast (TypeInfo $type, $type value) { return value; } $type tsac ($type value, TypeInfo $type) /* Illegal */ cast (int, 4.3); /* Returns 4 */ A generic function that takes only generic types and values and only accesses other similarly compile-time values is considered trivially constant and must be folded. The generic function for a given function name and number of arguments is searched for eligibility after any specific-type functions. There can't be two generic functions with the same name and number of arguments as it's easy to make the overloading rules go crazy, and this restriction can be relaxed in the future. On to struct, class, and union. I've only taken the most obvious choice: struct Vector (TypeInfo $type, int $size) { $type [$size] array; } Vector (float, 4) v; struct Vector2 (TypeInfo $type) : Vector ($type, 2) { float x () { return array [0]; } float y () { return array [1]; } } struct Matrix (TypeInfo $type) { $type [,] array; Vector ($vtype, $vsize) mul (Vector ($vtype, $vsize) v) { } } There's many ways in which it falls behind C++'s template's expressiveness, but matching it is not the point. I don't write interdependent templates where instantiating inner templates might need some intelligence, so the many complexities of C++'s templates are not used by me. What I exclusively need are simple single-layer templates like vectors and matrices, and template methods.
Jan 17 2003
parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Burton Radons" <loth users.sourceforge.net> escreveu na mensagem
news:b0amv6$qlb$1 digitaldaemon.com...
 Daniel Yokomiso wrote:
 "Burton Radons" <loth users.sourceforge.net> escreveu na mensagem
 news:3E26F644.9090506 users.sourceforge.net...

Daniel Yokomiso wrote:

which are always type correct. Using function generators, we can define
a
function, that given a type will return a function specialized for the
given
type. D's template mechanism can be used as a function generator.

T fun(T,T) TMin(type T) {
return T fun(T left, T right) {
return left < right ? left : right;
}
}

using template syntax:

template TMin(T) {
return T min(T left, T right) {
return left < right ? left : right;
}
}
The template method I suggested a long time ago would use: $T min ($T left, $T right) { return left < right ? left : right; }
I don't think I've read about them. Do you remember the date of the posts, so I can search them? I'm too lazy to just search everything
manually
 ;-)
"Generics in D", starting on 24/06/2002. It's a simple syntax, just puts C++'s basic syntax inside the language instead of as a layer. Here's the body of my description of it: For generic functions and generic class methods, a "$" followed by an identifier in the place where a type would exist indicates a generic type. The specific type of this generic is determined by the first argument using it; a function cannot return a generic type only. For example: $type foo ($type a, $type b) $type bar (int c); /* Illegal */ complex x = foo (4, 2.3); /* Returns int and casts 2.3 to int */ Generic values are also prefixed with a $ and must be trivially constant. Generic values of type "TypeInfo" or "ClassInfo" are special in that they can be used both as a value and a generic type, and if so must be the first argument to use this generic value: $type cast (TypeInfo $type, $type value) { return value; } $type tsac ($type value, TypeInfo $type) /* Illegal */ cast (int, 4.3); /* Returns 4 */ A generic function that takes only generic types and values and only accesses other similarly compile-time values is considered trivially constant and must be folded. The generic function for a given function name and number of arguments is searched for eligibility after any specific-type functions. There can't be two generic functions with the same name and number of arguments as it's easy to make the overloading rules go crazy, and this restriction can be relaxed in the future. On to struct, class, and union. I've only taken the most obvious choice: struct Vector (TypeInfo $type, int $size) { $type [$size] array; } Vector (float, 4) v; struct Vector2 (TypeInfo $type) : Vector ($type, 2) { float x () { return array [0]; } float y () { return array [1]; } } struct Matrix (TypeInfo $type) { $type [,] array; Vector ($vtype, $vsize) mul (Vector ($vtype, $vsize) v) { } } There's many ways in which it falls behind C++'s template's expressiveness, but matching it is not the point. I don't write interdependent templates where instantiating inner templates might need some intelligence, so the many complexities of C++'s templates are not used by me. What I exclusively need are simple single-layer templates like vectors and matrices, and template methods.
Hmmm, I think I lost these posts, because I wasn't lurking here before it (or was I? I don't remember). Anyway, it's a very simple but expressive syntax. I like it a lot. Maybe it isn't too late to sway Walter's opinion? --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.443 / Virus Database: 248 - Release Date: 11/1/2003
Jan 17 2003
next sibling parent "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
I like it better than what D has now.

Sean

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:b0ao5r$rhs$1 digitaldaemon.com...

 "Generics in D", starting on 24/06/2002.  It's a simple syntax, just
 puts C++'s basic syntax inside the language instead of as a layer.
 Here's the body of my description of it:

 For generic functions and generic class methods, a "$" followed by an
 identifier in the place where a type would exist indicates a generic
 type.  The specific type of this generic is determined by the first
 argument using it; a function cannot return a generic type only.  For
 example:

     $type foo ($type a, $type b)
     $type bar (int c); /* Illegal */

     complex x = foo (4, 2.3); /* Returns int and casts 2.3 to int */
Hmmm, I think I lost these posts, because I wasn't lurking here before it (or was I? I don't remember). Anyway, it's a very simple but expressive syntax. I like it a lot. Maybe it isn't too late to sway Walter's opinion?
Jan 18 2003
prev sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Daniel Yokomiso wrote:
 "Burton Radons" <loth users.sourceforge.net> escreveu na mensagem
 news:b0amv6$qlb$1 digitaldaemon.com...
[snip]
There's many ways in which it falls behind C++'s template's
expressiveness, but matching it is not the point.  I don't write
interdependent templates where instantiating inner templates might need
some intelligence, so the many complexities of C++'s templates are not
used by me.  What I exclusively need are simple single-layer templates
like vectors and matrices, and template methods.
Hmmm, I think I lost these posts, because I wasn't lurking here before it (or was I? I don't remember). Anyway, it's a very simple but expressive syntax. I like it a lot. Maybe it isn't too late to sway Walter's opinion?
As far as I know you're the only user of the feature! So no, it's not too late. Glancing over the spec, my missing features are specialization and argument deduction, both of which fit in easily. First, specialization: struct TFoo (TypeInfo $T) { } struct TFoo (TypeInfo $T : $T []) { } struct TFoo (TypeInfo $T : char) { } struct TFoo (TypeInfo $T, TypeInfo $U, TypeInfo $V) { } TFoo (char, int) fooe; /* Error, number of arguments mismatch */ Argument deduction: struct TBar (TypeInfo $D, TypeInfo $U : $D []) { } TBar (int, int[]) Bar1; /* $D is int, $U is int [] */ struct TBar (TypeInfo $D : $E *, TypeInfo $E) { } TBar (int *, int) Bar2; /* $D is int *, $E is int */ Bar2 additionally requires loosened rules on order of determining the type of a template value. I won't argue for this, as I don't use them. So it can be as flexible as the current syntax, with the addition of easily-expressed template functions and methods (which C++ doesn't have either). It is absolutely more intrusive; the struct/class types and functions all need an abstract template form. But I've never liked the implicit layered scheme of C++ or the explicit layering that D puts on the language; it's unnecessary at best and clumsy at its worst. The Walter factor needed is to convince him that implicit instantiation is a reasonable request to make of compiler authors. Honestly, I don't understand his objection to it; the only difference between these lines: instance TBar (int, 4) x; TBar (int, 4) y; Is a keyword. We can tell right during parsing that these must be instantiating template types. I don't see most of C++'s implicit instantiation rules as making any sense in our context, such as the: Z<int> a; // instantiation of class Z<int> required Z<char>* p; // instantiation of class Z<char> not required I can't even imagine the cavalcade of drugs the C++ designers must have been on to make some of their decisions.
Jan 18 2003
next sibling parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Burton Radons" <loth users.sourceforge.net> escreveu na mensagem
news:b0cb3o$1pt0$1 digitaldaemon.com...
 Daniel Yokomiso wrote:
 "Burton Radons" <loth users.sourceforge.net> escreveu na mensagem
 news:b0amv6$qlb$1 digitaldaemon.com...
[snip]
There's many ways in which it falls behind C++'s template's
expressiveness, but matching it is not the point.  I don't write
interdependent templates where instantiating inner templates might need
some intelligence, so the many complexities of C++'s templates are not
used by me.  What I exclusively need are simple single-layer templates
like vectors and matrices, and template methods.
Hmmm, I think I lost these posts, because I wasn't lurking here
before
 it (or was I? I don't remember). Anyway, it's a very simple but
expressive
 syntax. I like it a lot. Maybe it isn't too late to sway Walter's
opinion?
 As far as I know you're the only user of the feature!  So no, it's not
 too late.
I started using templates so I could convince Walter of changing them to fit my whims ;-)
 Glancing over the spec, my missing features are specialization and
 argument deduction, both of which fit in easily.  First, specialization:

       struct TFoo (TypeInfo $T) { }
       struct TFoo (TypeInfo $T : $T []) { }
       struct TFoo (TypeInfo $T : char) { }
       struct TFoo (TypeInfo $T, TypeInfo $U, TypeInfo $V) { }




       TFoo (char, int) fooe; /* Error, number of arguments mismatch */

Current DTL 0.0.2 uses specialization to overcome lack of value parameters in templates.
 Argument deduction:

       struct TBar (TypeInfo $D, TypeInfo $U : $D []) { }
       TBar (int, int[]) Bar1; /* $D is int, $U is int [] */

       struct TBar (TypeInfo $D : $E *, TypeInfo $E) { }
       TBar (int *, int) Bar2; /* $D is int *, $E is int */

 Bar2 additionally requires loosened rules on order of determining the
 type of a template value.  I won't argue for this, as I don't use them.
Argument deduction is a strange thing to me. First I thought them of being type constraints, but right now I don't know why or how I would use them.
 So it can be as flexible as the current syntax, with the addition of
 easily-expressed template functions and methods (which C++ doesn't have
 either).  It is absolutely more intrusive; the struct/class types and
 functions all need an abstract template form.  But I've never liked the
 implicit layered scheme of C++ or the explicit layering that D puts on
 the language; it's unnecessary at best and clumsy at its worst.

 The Walter factor needed is to convince him that implicit instantiation
 is a reasonable request to make of compiler authors.  Honestly, I don't
 understand his objection to it; the only difference between these lines:

      instance TBar (int, 4) x;
      TBar (int, 4) y;
As most of D posters here come from a C/C++ background, Walter fear adding features that will end making D another C++. I agree that explicit instantiation is too verbose, almost impossible to mix with generic methods.
 Is a keyword.  We can tell right during parsing that these must be
 instantiating template types.  I don't see most of C++'s implicit
 instantiation rules as making any sense in our context, such as the:

      Z<int> a; // instantiation of class Z<int> required
      Z<char>* p; // instantiation of class Z<char> not required

 I can't even imagine the cavalcade of drugs the C++ designers must have
 been on to make some of their decisions.
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.443 / Virus Database: 248 - Release Date: 10/1/2003
Jan 18 2003
prev sibling parent "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:b0cb3o$1pt0$1 digitaldaemon.com...
     Hmmm, I think I lost these posts, because I wasn't lurking here
before
 it (or was I? I don't remember). Anyway, it's a very simple but
expressive
 syntax. I like it a lot. Maybe it isn't too late to sway Walter's
opinion?
 As far as I know you're the only user of the feature!  So no, it's not
 too late.
It still won't be easy.
 Glancing over the spec, my missing features are specialization and
 argument deduction, both of which fit in easily.  First, specialization:

       struct TFoo (TypeInfo $T) { }
       struct TFoo (TypeInfo $T : $T []) { }
       struct TFoo (TypeInfo $T : char) { }
       struct TFoo (TypeInfo $T, TypeInfo $U, TypeInfo $V) { }




       TFoo (char, int) fooe; /* Error, number of arguments mismatch */

That's a welcome addition, but it looks more like a Pascal typespec than a C one. Not that I like C typespecs. ;) Maybe struct TFoo (TypeInfo $T) { } struct TFoo (TypeInfo( $T [] ) $T) { } struct TFoo (TypeInfo( char ) $T) { } ?
 Argument deduction:

       struct TBar (TypeInfo $D, TypeInfo $U : $D []) { }
       TBar (int, int[]) Bar1; /* $D is int, $U is int [] */

       struct TBar (TypeInfo $D : $E *, TypeInfo $E) { }
       TBar (int *, int) Bar2; /* $D is int *, $E is int */

 Bar2 additionally requires loosened rules on order of determining the
 type of a template value.  I won't argue for this, as I don't use them.

 So it can be as flexible as the current syntax, with the addition of
 easily-expressed template functions and methods (which C++ doesn't have
 either).  It is absolutely more intrusive; the struct/class types and
 functions all need an abstract template form.  But I've never liked the
 implicit layered scheme of C++ or the explicit layering that D puts on
 the language; it's unnecessary at best and clumsy at its worst.

 The Walter factor needed is to convince him that implicit instantiation
 is a reasonable request to make of compiler authors.  Honestly, I don't
 understand his objection to it; the only difference between these lines:

      instance TBar (int, 4) x;
      TBar (int, 4) y;

 Is a keyword.  We can tell right during parsing that these must be
 instantiating template types.  I don't see most of C++'s implicit
 instantiation rules as making any sense in our context, such as the:

      Z<int> a; // instantiation of class Z<int> required
      Z<char>* p; // instantiation of class Z<char> not required
Just makes the compiler faster. It's the whole #include file mess. It would have to go ahead and instantiate Z<char> if you dereferenced p.
 I can't even imagine the cavalcade of drugs the C++ designers must have
 been on to make some of their decisions.
Some people don't need drugs to be stupid. ;) Sean
Jan 19 2003
prev sibling parent Daniel Yokomiso <Daniel_member pathlink.com> writes:
In article <b03a3c$2kig$1 digitaldaemon.com>, Niall Douglas says...
In article <b02uv8$2cnb$1 digitaldaemon.com>, Ben Woodhead says...
Hello, I have a few questions. Perhaps someone can help me out.
I might be able to. I disagree fundamentally with OO and through my arguments with OO gurus, I've learned a lot (though not been convinced I'm wrong!) :)
What is the purpose in generic programming?
What problems does it solve?
Is that problem a language problem?
How does Java live without it?
Firstly, I don't think Java does live without it. It's like operator overloading - Sun just removed it completely. Operator overloading, when used correctly, actually produces far more reliable, intuitive and thus bug-free code. I'll just outline what it is for those not familiar with these things, then say why it was incorporated. Now if for example I want a list object which maintains a list of another object, in Java I'd use a dual object approach - there'd be a list item object which would be the base class of all items to be placed in the list and then the list would manage those subclasses of the list item object. Using templates, you specify the list object as taking one or more parameters ie; it's like a mould used to "stamp" out objects. So if I want a list of string objects, it's class list<string> and equally class list<class<string>> works too (a list of lists of string). The point is with templates you write the class guts once, and the parameters determine the actual implementation. If you're familiar with C, then most use of parameterised macros can be replaced with templates eg; #define ADD(type) \ { return a + b; } In templates becomes: template<class type> type Add(type a, type b) { return a + b; } The great problem I see with C++ templates is they are limited to type parameters. I'd personally like to see free-form parameters. You may be asking what can templates let me do other approaches cannot? In Java, I don't think there are any - Java stores lengthy meta-data about all its data constructs so the language always knows what type some data is and thus how to work with it. In a static system like C++, there is no knowledge of data type except at time of compilation - hence "new X" is useless unless X's type is immediately known. Templates are the way of implementing multi-type generic code without requiring a run-time system. BTW if you're thinking fine, let's add a run-time system - well, that's why objective C failed in competing against C++. Nowadays you may get away with it, One other point is that Java's solution to the above problems would require more code than in C++. Using abstract base classes to generalise objects to some collection class is fine but it really needs multiple inheritance to be useful. I think the most productive future for D would be to remain as a primarily static system, though I wouldn't mind seeing optional dynamic features like ObjC has. Cheers, Niall
Hi, AFAIK C++ offers at least integer template parameters. If you read http://osl.iu.edu/~tveldhui/papers/Template-Metaprograms/meta-art.html you will find a template specialized by a integer parameter. I think other value types can be used too, but I may be wrong. Your remarks about Java are correct, as someone said: "Every use of reflection shows a hole in the type system". Best regards, Daniel Yokomiso.
Jan 16 2003
prev sibling parent Evan McClanahan <evan dontSPAMaltarinteractive.com> writes:
Ben Woodhead wrote:
 Hello, I have a few questions. Perhaps someone can help me out.
 
 What is the purpose in generic programming?
 What problems does it solve?
 Is that problem a language problem?
 How does Java live without it?
Many and various, and it doesn't, really. They've just been added ti the language spec for forthcoming versions, I believe. Generic programming is simply a way of defining a datastructure or algorthm to work with an type or set of types. Google, there are better descriptions out there. Evan
Jan 15 2003
prev sibling next sibling parent reply Niall Douglas <Niall_member pathlink.com> writes:
In article <b01afa$16dn$1 digitaldaemon.com>, Ben Woodhead says...

You are using c++ because its powerful, not because its a nice. You have
learned to like c++, and you did that because of the power. When you started
do you really think that you were saying stuff like "wow, this is the best
way to handle strings, and I really like these pointers". You might like
them now.
No 90% of people who use C++ do so because it's the industry standard. I personally would greatly prefer to use something non-OO and functional, but the tools for C++ are extremely mature so it tips the balance in favour. Also, of course, employers want to use the lowest common denominator of technology so they can easily replace their employees. I have not met one single person who is happy with C++ - everyone has annoyances and gripes - much is through ignorance, low technical ability and poor understanding, but some are very real faults too eg; my earlier point about the exception handling system in C++ being fundamentally broken.
As it is I have see a few feature that (although needed/wanted by the c++
community) were not in the design that were put in (i.e. templates). I liked
Walters original plan of not putting it in. Java does fine without it.
I would *not* use Java as a baseline for anything, but then I personally hate the language :). Templates I think were "stolen" from Ada by C++ and while they're ok in C++, they really should go a lot further. Generic programming can only be 75% done using C++ style templates, so if D were adopting them, I'd go the full hog and make them completely substitutable ie; leave it to the compiler to determine where it's like a C macro and needs new code each time or whether some code can be centralised. This approach would also mean we can get rid of the C preprocessor parameterised macros. Just make everything involving substitution templates.
One possible way to do this, is instead of coming to the list with your c++
code and saying this is something that is needed, perhaps you should say
"this is what I am trying to do and here is they way I would do it in c++,
anybody have any ideas on how to do this in D".
I agree with what you're saying completely. However, I would say that C++ does have some very useful features which D could learn from. I personally use templates, multiple inheritence and exceptions wherever they produce a better project which is quite often. However, one must be careful of wearing "C++ goggles" where if it's done some way in C++, that therefore must be the only way. That's hardly true, especially for C++ out of all languages. I would hope D will take the opportunity to improve on every single area possible over C++ and effectively become the superior choice for a C-style OO language which I think is its design goal? Me personally: I think D should have inbuilt strings, dynamic arrays, hash tables, lists (linked and vector), fully flexible templates, recursively throwable exceptions and optional garbage collection (for this, new and delete allocate from the freestore, but "newgc" has its deletions managed by a GC algorithm). My rationale for including all that STL stuff is that very few programmers can improve significantly enough on those algorithms and even if they could, they could still always implement their own and use it manually. The garbage collection debate to my mind is stupid (!) because you can support both very easily with slight syntaxical improvement eg; newgc. Internally you would allocate from two different heaps, one GC'ed and the other not. Heh, I bet I get significant replies this time! :) Cheers, Niall
Jan 14 2003
parent reply "Ben Woodhead" <zander echotech.ca> writes:
Hello

Thanks for the responce, you have some interesting points to think about.
Some comments are included in the message.

"Niall Douglas" <Niall_member pathlink.com> wrote in message
news:b02iuk$25gs$1 digitaldaemon.com...
 In article <b01afa$16dn$1 digitaldaemon.com>, Ben Woodhead says...

You are using c++ because its powerful, not because its a nice. You have
learned to like c++, and you did that because of the power. When you
started
do you really think that you were saying stuff like "wow, this is the
best
way to handle strings, and I really like these pointers". You might like
them now.
No 90% of people who use C++ do so because it's the industry standard. I personally would greatly prefer to use something non-OO and functional,
but the
 tools for C++ are extremely mature so it tips the balance in favour. Also,
of
 course, employers want to use the lowest common denominator of technology
so
 they can easily replace their employees.
The reason for c++ becoming the standard is related because of the power of the language. C was able to give you the power of asm in a much simpler way. That does not mean its a simple way, its just easier to work with them asm. C++ adds features to help make code maintainable and organized but keeps the power and most if not all of the speed. Being the most powerful language around for a long time means that if you want to do anything heavy then you will have to use c or c++. So hear we are, so people use c++ because its the standard and its the standard because of the power.
 I have not met one single person who is happy with C++ - everyone has
annoyances
 and gripes - much is through ignorance, low technical ability and poor
 understanding, but some are very real faults too eg; my earlier point
about the
 exception handling system in C++ being fundamentally broken.
I have not met a single person that is happy with anything on a computer, especially programming languages. And you are right, a lot has to do with lack of knowledge. But you know what, things that are intuative in the first place don't have problems with people not understanding them. :)
As it is I have see a few feature that (although needed/wanted by the c++
community) were not in the design that were put in (i.e. templates). I
liked
Walters original plan of not putting it in. Java does fine without it.
I would *not* use Java as a baseline for anything, but then I personally
hate
 the language :). Templates I think were "stolen" from Ada by C++ and while
 they're ok in C++, they really should go a lot further. Generic
programming can
 only be 75% done using C++ style templates, so if D were adopting them,
I'd go
 the full hog and make them completely substitutable ie; leave it to the
compiler
 to determine where it's like a C macro and needs new code each time or
whether
 some code can be centralised.
Java is a different way of thinking. If you start with that language then you will be fine, but coming from C is not going to be fun. I will have to look at the ada templates to comment on the rest but it sounds interesting. All this generic programming could be a solution to a problem with the language. Fix the problem and remove the need for generic programming like templates. This approach worked for Java and walter also didn't think templates were needed.
 This approach would also mean we can get rid of the C preprocessor
parameterised
 macros. Just make everything involving substitution templates.

One possible way to do this, is instead of coming to the list with your
c++
code and saying this is something that is needed, perhaps you should say
"this is what I am trying to do and here is they way I would do it in
c++,
anybody have any ideas on how to do this in D".
I agree with what you're saying completely. However, I would say that C++
does
 have some very useful features which D could learn from. I personally use
 templates, multiple inheritence and exceptions wherever they produce a
better
 project which is quite often.
c++ does have some useful features, as does java and several other languages. It also has a lot of crap, and I have not dought that templates and multi-inheritence helps your project. Both could be needed to fix a problem with c++ but there is always a better way. :)
 However, one must be careful of wearing "C++ goggles" where if it's done
some
 way in C++, that therefore must be the only way. That's hardly true,
especially
 for C++ out of all languages. I would hope D will take the opportunity to
 improve on every single area possible over C++ and effectively become the
 superior choice for a C-style OO language which I think is its design
goal? C++ goggles is what I am worried about. I also hope that D does take the usefull features of c++ and builds on that, as well as java. Although you don't like the language there are things in it that are nice. But I don't want to write c++ code in d.
 Me personally: I think D should have inbuilt strings, dynamic arrays, hash
 tables, lists (linked and vector), fully flexible templates, recursively
 throwable exceptions and optional garbage collection (for this, new and
delete
 allocate from the freestore, but "newgc" has its deletions managed by a GC
 algorithm). My rationale for including all that STL stuff is that very few
 programmers can improve significantly enough on those algorithms and even
if
 they could, they could still always implement their own and use it
manually. Yes, my thoughts exactly. As far as new and delete. I think everything should be created on free stores. The program its self can be stored in conventinal memery, every variable goes in free stores. On the other hand I would not want to limit the ability to create linked lists or what ever.
 The garbage collection debate to my mind is stupid (!) because you can
support
 both very easily with slight syntaxical improvement eg; newgc. Internally
you
 would allocate from two different heaps, one GC'ed and the other not.
Thats interesting.
 Heh, I bet I get significant replies this time! :)
Ya a few, hope it makes sence, its late.:) Goodnight, Ben
 Cheers,
 Niall
Jan 14 2003
next sibling parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
"Ben Woodhead" <zander echotech.ca> wrote in message
news:b02upv$2cm3$1 digitaldaemon.com...
 Java is a different way of thinking. If you start with that language then
 you will be fine, but coming from C is not going to be fun. I will have to
 look at the ada templates to comment on the rest but it sounds
interesting.
 All this generic programming could be a solution to a problem with the
 language. Fix the problem and remove the need for generic programming like
 templates. This approach worked for Java and walter also didn't think
 templates were needed.
You cannot have typesafe containers without language-supported generics. Not unless you want to cut-and-paste all your container code for every new type you wish to put into such a container. Then duplicate all your algorithm code for every container type times the number of types contained therein. The combinatorial explosion happens quickly. People will write a non-typesafe container, or a braindead linear algorithm, rather than do all that work. Non-typesafe containers lead to bugs in user code. If they do make all those classes, they will be unmaintainable. A bug in the original gets copied into all the subsequent classes. Generics are a fundamentally good thing. They allow you to reuse more code than OO does. Write a template algorithm once, and use it on anything that supports the necessary interfaces. It'd be good to explicitly specify those interfaces in the requirements somehow. Self-documentation. It would be super nice if D unified the type system so that one could write a template that would work on either a basic type or a user-defined type without modification. C++ only goes about halfway with this. Sean
Jan 15 2003
parent reply Daniel Yokomiso <Daniel_member pathlink.com> writes:
In article <b039up$2kh4$1 digitaldaemon.com>, Sean L. Palmer says...
"Ben Woodhead" <zander echotech.ca> wrote in message
news:b02upv$2cm3$1 digitaldaemon.com...
 Java is a different way of thinking. If you start with that language then
 you will be fine, but coming from C is not going to be fun. I will have to
 look at the ada templates to comment on the rest but it sounds
interesting.
 All this generic programming could be a solution to a problem with the
 language. Fix the problem and remove the need for generic programming like
 templates. This approach worked for Java and walter also didn't think
 templates were needed.
You cannot have typesafe containers without language-supported generics. Not unless you want to cut-and-paste all your container code for every new type you wish to put into such a container. Then duplicate all your algorithm code for every container type times the number of types contained therein. The combinatorial explosion happens quickly. People will write a non-typesafe container, or a braindead linear algorithm, rather than do all that work. Non-typesafe containers lead to bugs in user code. If they do make all those classes, they will be unmaintainable. A bug in the original gets copied into all the subsequent classes. Generics are a fundamentally good thing. They allow you to reuse more code than OO does. Write a template algorithm once, and use it on anything that supports the necessary interfaces. It'd be good to explicitly specify those interfaces in the requirements somehow. Self-documentation. It would be super nice if D unified the type system so that one could write a template that would work on either a basic type or a user-defined type without modification. C++ only goes about halfway with this. Sean
Hi, Generics is orthogonal to OO when we talk about reuse. OO usually provides class-based inheritance, which is one of the four forms of polimorphism (), but if it allows other kinds of polimorphism it can allow the same amount of reuse. But I agree that they are a Good Thing. What are the current problems on D's type system that it disallows templates be used with both primitives and user-defined types? Best regards, Daniel Yokomiso.
Jan 16 2003
parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
"Daniel Yokomiso" <Daniel_member pathlink.com> wrote in message
news:b06mfi$1ifv$1 digitaldaemon.com...
 In article <b039up$2kh4$1 digitaldaemon.com>, Sean L. Palmer says...
Generics are a fundamentally good thing.  They allow you to reuse more
code
than OO does.  Write a template algorithm once, and use it on anything
that
supports the necessary interfaces.  It'd be good to explicitly specify
those
interfaces in the requirements somehow.  Self-documentation.

It would be super nice if D unified the type system so that one could
write
a template that would work on either a basic type or a user-defined type
without modification.  C++ only goes about halfway with this.

Sean
Hi, Generics is orthogonal to OO when we talk about reuse. OO usually provides class-based inheritance, which is one of the four forms of polimorphism
(), but
 if it allows other kinds of polimorphism it can allow the same amount of
reuse.
 But I agree that they are a Good Thing.
The kind of things OO is good for aren't well solved by templates, and vice versa.
 What are the current problems on D's type system that it disallows
templates be
 used with both primitives and user-defined types?

 Best regards,
 Daniel Yokomiso.
It will currently work... mostly. There are some gotchas though. For one, you can't initialize "any type" properly. To the default maybe, but default means something totally different for ints (zero), floats (NaN!!), and UDT's (pretty much a collection of ints and floats for structs, but you can make your own ctor for classes). You also can't call methods on basic types (though there are some properties masquerading as methods). And you can't overload all the operators on UDT's (assignment for instance). Not a huge deal. There's another hole in D's template system in that it doesn't allow template parameters to be values; they have to be types. Having compile time values as template parameters opens the door to easier compile time template metaprogramming. It can be hacked around inelegantly with the current setup, by making struct types that contain enums or whatever. Doing recursion this way is almost impossible since you can't just make a type like you can a variable. Sean
Jan 16 2003
parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
Hi,

    Comments embedded.


"Sean L. Palmer" <seanpalmer directvinternet.com> escreveu na mensagem
news:b06q50$1klc$1 digitaldaemon.com...
 "Daniel Yokomiso" <Daniel_member pathlink.com> wrote in message
 news:b06mfi$1ifv$1 digitaldaemon.com...
 In article <b039up$2kh4$1 digitaldaemon.com>, Sean L. Palmer says...
Generics are a fundamentally good thing.  They allow you to reuse more
code
than OO does.  Write a template algorithm once, and use it on anything
that
supports the necessary interfaces.  It'd be good to explicitly specify
those
interfaces in the requirements somehow.  Self-documentation.

It would be super nice if D unified the type system so that one could
write
a template that would work on either a basic type or a user-defined
type
without modification.  C++ only goes about halfway with this.

Sean
Hi, Generics is orthogonal to OO when we talk about reuse. OO usually
provides
 class-based inheritance, which is one of the four forms of polimorphism
(), but
 if it allows other kinds of polimorphism it can allow the same amount of
reuse.
 But I agree that they are a Good Thing.
The kind of things OO is good for aren't well solved by templates, and
vice
 versa.
Yes.
 What are the current problems on D's type system that it disallows
templates be
 used with both primitives and user-defined types?

 Best regards,
 Daniel Yokomiso.
It will currently work... mostly. There are some gotchas though. For
one,
 you can't initialize "any type" properly.  To the default maybe, but
default
 means something totally different for ints (zero), floats (NaN!!), and
UDT's
 (pretty much a collection of ints and floats for structs, but you can make
 your own ctor for classes).  You also can't call methods on basic types
 (though there are some properties masquerading as methods).  And you can't
 overload all the operators on UDT's (assignment for instance).
All these are real problems that D template mechanism cannot address. But you can workaround them using templates for these functions (except assignment overloading), so you can have a common template: template TNumericTraits(T) { T zero(); T one(); } And overload template definitions for all primitives and for UDT's. Ugly but it works. About assignment overloading, IMHO C++ design is ugly and very error-prone. Ada provide the same thing, but their solution is simpler. What you think about it? Ada's way can do the deal, or C++ like overloading of assignment is necessary?
 Not a huge deal.

 There's another hole in D's template system in that it doesn't allow
 template parameters to be values;  they have to be types.  Having compile
 time values as template parameters opens the door to easier compile time
 template metaprogramming.  It can be hacked around inelegantly with the
 current setup, by making struct types that contain enums or whatever.
Doing
 recursion this way is almost impossible since you can't just make a type
 like you can a variable.

 Sean
Yes, but Walter changed his mind and will implement some kind of value parameters. I thought you have some other problems with D's template mechanism, but you share the critics with most of us. Or there's something more? Best regards, Daniel Yokomiso. "Daddy, why doesn't this magnet pick up this floppy disk?" --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.443 / Virus Database: 248 - Release Date: 11/1/2003
Jan 17 2003
parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:b0ahk2$o3q$1 digitaldaemon.com...
     All these are real problems that D template mechanism cannot address.
 But you can workaround them using templates for these functions (except
 assignment overloading), so you can have a common template:


 template TNumericTraits(T) {
     T zero();
     T one();
 }
It is a pain to make such things. You almost need a template to help build your template. ;)
     And overload template definitions for all primitives and for UDT's.
Ugly
 but it works. About assignment overloading, IMHO C++ design is ugly and
very
 error-prone. Ada provide the same thing, but their solution is simpler.
What
 you think about it? Ada's way can do the deal, or C++ like overloading of
 assignment is necessary?
I don't know enough about Ada to be able to comment. I have messed around with designs of my own which do everything (copying, construction, conversion, i/o) using assignment. I don't think you really need all the forms that C++ has. For instance creating a new value from nothing would be overloading assignment to object reference from void. Copy construction is assignment from reference to reference of same type. Conversion is assignment to different type. I/O is assignment to or from a stream. Sure makes things conceptually simpler. I, too, am working on a language design, but time constraints make it very slow going. I know it will be very different than C/C++. Hopefully stay closer syntactically but diverge semantically. All the cool languages I've read about have very wierd syntax. All these restrictions on identifier casing, etc. Haskell, OOCaml, Sather; all very strange languages if you come from a C++ background. And it's not the concepts so much as just the look and feel of the language. I love the constructs, I just can't stand to look at the programs source; they just look ugly to me.
     Yes, but Walter changed his mind and will implement some kind of value
 parameters.
That's good. Otherwise very hard to write recursive templates.
     I thought you have some other problems with D's template mechanism,
but
 you share the critics with most of us. Or there's something more?
My main problem with D's template system is the explicit instantiation. I am spoiled by C++'s templates. I also think C++'s templates don't go far enough. You really need language constructs to facilitate working with compile time values, such as "const functions" which have no side effects and rely on no runtime data and given constants as inputs generate a constant output, so are suitable for evaluation at compile time. Sean
Jan 18 2003
parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Sean L. Palmer" <seanpalmer directvinternet.com> escreveu na mensagem
news:b0c878$1o3f$1 digitaldaemon.com...
 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
 news:b0ahk2$o3q$1 digitaldaemon.com...
     All these are real problems that D template mechanism cannot
address.
 But you can workaround them using templates for these functions (except
 assignment overloading), so you can have a common template:


 template TNumericTraits(T) {
     T zero();
     T one();
 }
It is a pain to make such things. You almost need a template to help
build
 your template.  ;)
IIRC Dijkstra once said that you can solve any problem just by adding another level of indirection ;-)
     And overload template definitions for all primitives and for UDT's.
Ugly
 but it works. About assignment overloading, IMHO C++ design is ugly and
very
 error-prone. Ada provide the same thing, but their solution is simpler.
What
 you think about it? Ada's way can do the deal, or C++ like overloading
of
 assignment is necessary?
I don't know enough about Ada to be able to comment. I have messed around with designs of my own which do everything (copying, construction, conversion, i/o) using assignment. I don't think you really need all the forms that C++ has. For instance creating a new value from nothing would
be
 overloading assignment to object reference from void.  Copy construction
is
 assignment from reference to reference of same type.  Conversion is
 assignment to different type.  I/O is assignment to or from a stream.
Sure
 makes things conceptually simpler.

 I, too, am working on a language design, but time constraints make it very
 slow going.  I know it will be very different than C/C++.  Hopefully stay
 closer syntactically but diverge semantically.  All the cool languages
I've
 read about have very wierd syntax.  All these restrictions on identifier
 casing, etc.  Haskell, OOCaml, Sather;  all very strange languages if you
 come from a C++ background.  And it's not the concepts so much as just the
 look and feel of the language.  I love the constructs, I just can't stand
to
 look at the programs source;  they just look ugly to me.
Sometimes when I read functional code it feels very elegant, but almost impossible to understand. I think it's their prediletion to write one character parameter names or truncate names.
     Yes, but Walter changed his mind and will implement some kind of
value
 parameters.
That's good. Otherwise very hard to write recursive templates.
     I thought you have some other problems with D's template mechanism,
but
 you share the critics with most of us. Or there's something more?
My main problem with D's template system is the explicit instantiation. I am spoiled by C++'s templates. I also think C++'s templates don't go far enough. You really need language constructs to facilitate working with compile time values, such as "const functions" which have no side effects and rely on no runtime data and given constants as inputs generate a constant output, so are suitable for evaluation at compile time. Sean
IME explicit instantiation sometimes help you figure out what's going on, but whenever I work on DTL i use more and more aliases ;-) Pure functions also allow equational reasoning and let the compiler reorder expression evaluation, which when combined with cache-hit analysis can improve performance. Maybe they'll be in D after 1.0, unless we convince Walter first. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.443 / Virus Database: 248 - Release Date: 10/1/2003
Jan 18 2003
prev sibling next sibling parent reply Niall Douglas <Niall_member pathlink.com> writes:
In article <b02upv$2cm3$1 digitaldaemon.com>, Ben Woodhead says...

The reason for c++ becoming the standard is related because of the power of
the language. C was able to give you the power of asm in a much simpler way.
That does not mean its a simple way, its just easier to work with them asm.
C++ adds features to help make code maintainable and organized but keeps the
power and most if not all of the speed. Being the most powerful language
around for a long time means that if you want to do anything heavy then you
will have to use c or c++. So hear we are, so people use c++ because its the
standard and its the standard because of the power.
I disagree. There are far more powerful languages out there than C++ eg; Haskell, even Python. I think the main reasons had to do with C++ offering a direct upgrade path for legacy C code. This then begs the question why Objective C didn't win since it also offered backwards compatibility? It's a dynamic system, not static like C++ and thus came with a runtime library. I'm still not quite sure why C++ won because in my mind it was the technically inferior choice, but I'm guessing it had to do with: (a) perceived efficiency (b) an excellent early translator to C (CFront from AT&T) (c) the perception that ObjC was too "out there" coming from NextSTEP as it did
Java is a different way of thinking. If you start with that language then
you will be fine, but coming from C is not going to be fun.
Well that's certainly one way of putting it. I wouldn't agree that if you start with it you're fine - most people I know who did that were bowled over by other OO languages eg; Schema or Smalltalk because Java is just so horribly limited. I find it like programming with my nose only with both hands tied behind my back :)
 I will have to
look at the ada templates to comment on the rest but it sounds interesting.
Err, this is vague memory talking! I could be entirely wrong!
All this generic programming could be a solution to a problem with the
language. Fix the problem and remove the need for generic programming like
templates. This approach worked for Java and walter also didn't think
templates were needed.
You absolutely need templates for any static system like C++ and I think D? They also make quite a lot of programming easier, and I can't see not having them without multiple inheritance being all that viable. You need one or the other for large projects IMHO.
c++ does have some useful features, as does java and several other
languages. It also has a lot of crap, and I have not dought that templates
and multi-inheritence helps your project. Both could be needed to fix a
problem with c++ but there is always a better way. :)
Well I've always been lucky in being able to use everything the language gives me without shooting myself in the foot. One of my early C projects was "pointer nation" because I was basically writing assembler. Ran fine, but not a single other soul could dare alter a line and expect it to continue working - and thus, with hindsight, that was a bad project.
C++ goggles is what I am worried about. I also hope that D does take the
usefull features of c++ and builds on that, as well as java. Although you
don't like the language there are things in it that are nice. But I don't
want to write c++ code in d.
Out of interest, what's nice in java? The VM is the sole thing I can think of personally.
Yes, my thoughts exactly. As far as new and delete. I think everything
should be created on free stores. The program its self can be stored in
conventinal memery, every variable goes in free stores. On the other hand I
would not want to limit the ability to create linked lists or what ever.
Ooo - just had another idea. How about a freestore overload stack? Basically, I'd like an object and everything it calls to use a specific heap so that on destruction I can ignore deleting all my child objects and just delete the heap (and thus all child allocations)? This would greatly improve performance. C++ can do this, but generally you need to chop the code into threads so you can base the seperate heap on thread local storage. Cheers, Niall
Jan 15 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Niall Douglas" <Niall_member pathlink.com> wrote in message
news:b03b5h$2l2s$1 digitaldaemon.com...
 This then begs the question why Objective C didn't win since it also
offered
 backwards compatibility? It's a dynamic system, not static like C++ and
thus
 came with a runtime library. I'm still not quite sure why C++ won because
in my
 mind it was the technically inferior choice, but I'm guessing it had to do
with:
 (a) perceived efficiency (b) an excellent early translator to C (CFront
from
 AT&T) (c) the perception that ObjC was too "out there" coming from
NextSTEP as
 it did
Back in '85 or '86, ObjC and C++ were neck-and-neck as enhancements to C (judging by the volume of messages in their respective newsgroups). At the time, only one implementation of each existed. There was, as I recall, a lot of arguing about which was better. But there was one crucial difference. AT&T was happy to let anyone build a C++ compiler without getting a license from AT&T (yes, I wrote AT&T's lawyers asking, and they said fine, go right ahead!). To do an ObjC clone, you had to get a license from Stepstone, which cost real money. So, I built a C++ compiler (the first native C++ compiler). We made it available inexpensively on the PC, and advertised that our intention was to be 100% AT&T compatible. We shipped a huge number of compilers, and that achieved the critical mass for C++ to gain ascendancy.
Jan 18 2003
parent Evan McClanahan <evan dontSPAMaltarinteractive.com> writes:
Walter wrote:
 Back in '85 or '86, ObjC and C++ were neck-and-neck as enhancements to C
 (judging by the volume of messages in their respective newsgroups). At the
 time, only one implementation of each existed. There was, as I recall, a lot
 of arguing about which was better.
 
 But there was one crucial difference. AT&T was happy to let anyone build a
 C++ compiler without getting a license from AT&T (yes, I wrote AT&T's
 lawyers asking, and they said fine, go right ahead!). To do an ObjC clone,
 you had to get a license from Stepstone, which cost real money.
 
 So, I built a C++ compiler (the first native C++ compiler). We made it
 available inexpensively on the PC, and advertised that our intention was to
 be 100% AT&T compatible. We shipped a huge number of compilers, and that
 achieved the critical mass for C++ to gain ascendancy.
So D could be viewed as an attempt to atone for the damage that you've done in the past :) Evan
Jan 20 2003
prev sibling parent Ilya Minkov <midiclub 8ung.at> writes:
I answer multiple messssages, not sure which.

 I have not met a single person that is happy with anything on a
 computer, especially programming languages. And you are right, a lot
 has to do with lack of knowledge. But you know what, things that are
 intuative in the first place don't have problems with people not
 understanding them. :)
 
Hello, i'm quite happy that i have a computer. :) It might very well be that i have some lack of knowledge. The language I started with was Delphi, and I was perfectly happy. I still can't stand C++ (obviously because of my lack of knowledge :> ). Delphi is quite simple, but pretty efficient and the language design is very clean, so that it helps prevent bugs. Too little to misunderstand. Well, to a certain point. The lack of featues is a source of bugs as well. Such as not having dynamic arrays and such. But as I didn't know other languages besides a bit of C, i was happy. To my opinion, it *IS* the fault of C++ that it is much easier to write bad code in it as in some other languages. I have seen really bad Delphi code only once, and it was written by a kid which abviously didn't have a "real" book or had a bad teacher :> like no identation, and so on. I doubt there would be a big project consisting of bad Delphi code. It is also the choise which each person makes. Noone has ever tried to write clean code in BEFUNGE, because the language has not been designed for it. Take a look at any piece of C code written by an experienced BEFUNGE programmer - it's ready for a world-class obfuscation contest. For the ones who don't know: BEFUNGE programs is a multidirectional array of statements, which can be run in *any* direction. So when you state "goto", you're not only giving a target but also a direction. It's rather a toy in my opinion. Well, D seems to be a solution for me. Though it is based on a dirty language, i think it might just have enough checks to prevent bad technique, filling C and especially C++ code. ---------------------------------
 What is the purpose in generic programming?
 What problems does it solve?
 Is that problem a language problem?
 How does Java live without it?
Generic programming allows you to write code once and use it for many kinds of objects, allowing you to do the same with different objects. Possible ways are: ---- WARNING, DESCRIPTION FOR KIDS! ---- 1. Subclassing. You have a basic "abstract" class which declares methods, for example: - "Get", "Set", "Resize" - virtual or abstract methods, not implemented; - "Insert", "Append", "Sort", and so on, which use the abstract methods to operate the storage, not touching the storage directly. The basic class contains no storage. Then you create another class based on this one, containing storage, and implement your virtual methods, operating on it. The "Insert", "Append", "Sort" start working automatically. Now, for example your storage was an array. You can also make a new subclass managing a linked list. Then you would want to reimplement not only virtuals, but also the rest of the functions because it makes it efficient. But if course, you can also only overload the virtuals, and it will work but probably painfully slow. OK, this is one of the things limiting generic programming, and i don't think it's solved by any system. Let's see another example. You have a class (TSolidList) that stores a list of objects of, for example, TSolid class. If you derive another class, like, TBetterSolid, which behaves the same, but stores data differently, you can also collect instances of TBetterSolid inside TSolidList without changes. The problem which i had with that, was that in Delphi such stored descendants would decay, say TBetterSolid would become a TSolid inside a TSolidList, so that i would have to either subclass the TSlidList to TBetterSolidList, or to cast the TSolid-s back into TBetterSolid-s, which requieres some confidence and is error-prone. QUESTION: does D circumvent this problem? Either someone actually read this far and can answer, or i'll check it myself. I guess it does, because ClassInfo is a part of the root object. 2. Macros C programmers usually have a macro like: #define MIN(a,b) ( ((a)>(b)) ? (b) : (a) ) which would always yield a minimum of two numbers of any type, or even of other types which support comparison. It basically makes text search and replacement, and is error-prone. This is the simplest and probably the oldest type of generic programming. They bloat the code, since they're copied on every occasion, but are thus efficient. But i think an advanced compiler would also inline functions as tiny as that, making them just as efficient. 3. Templates They follow the idea of macros. They take a type name and generate a class or a function or whatever by text or simple parse tree processing. They basically, beyond subclassing features, allow you to use unrelated kinds of underlying storage, which have the operations requiered, but are not derived from any common type. For example, having a template for <something operating on numbers> you can create thus this <something> from types like single, double-precision foating points, or even bignums or such. They solve efficiency problems for very tiny types, like integers or floats, which would become inefficient if packed into a class. Explanation Simple types: +----------+ | Double- | +Precision + |FP Number | +----------+ - can be stored as that in another structore Classes: +----------+ | Pointer |-------+ +----------+ | \./ +----------+ | Pointer |-------> Table of Method pointers +----------+ |something?| +----------+ | Double- | +Precision + |FP Number | +----------+ - only pointers are stored in further structures. Classes are very good for large objects which can also appear at different places, because only the pointer is copied, not necessarily the object itself. Packing such a small type as a number into a class would requiere a significant overhead at every access and during garbage collection. But to my opinion, a compiler could just as well optimize out such small classes to enable tight storage. That is, if a decision is made to make a 100% OO language, and certain limitations are made. Java simply doesn't bother with efficiency. ---------- I personally think that templates are often overused. You can just as well write a basic class, subclass it for basic types which are few, and make the rest with classes. Then strings would have to become a class too. Hmm. Maybe templates are a right decision in D anyway.
Jan 15 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Ben Woodhead" <zander echotech.ca> wrote in message
news:b01afa$16dn$1 digitaldaemon.com...
 As it is I have see a few feature that (although needed/wanted by the c++
 community) were not in the design that were put in (i.e. templates). I
liked
 Walters original plan of not putting it in. Java does fine without it.
You make some excellent points, but one thing I want to stress is D templates were designed by trying to understand what problem C++ templates were trying to solve, and then trying to find a way to do the equivalent with far less complexity than the C++ design. One of the problems is, as you mentioned, one gets so used to doing things in C++ that it gets difficult to imagine doing it any other way. We all suffer from that, and we all repeatedly need to step back now and then and ask ourselves just what problem is <feature X> of C++ trying to solve, and should it be reengineered?
Jan 18 2003