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