Hi!

Well I'm disappointed that people seem to feel that the preprocessor and templates are not features that are worth having...

I personally miss the preprocessor when I use Java. Otherwise how do we do code tuned for multiple platforms in 1 source? Or to include debugging code and removing at will (not just asserts)? Sometimes it's nice to have an extra level of indirection ^_^.. maybe we need instead is a preprocessor language that can be applied to any/many language(s) when needed.

And templates! Yes they are complex stuff and I wish they were easier but... they allow you to do things that you would otherwise be unable to do, or have to pay dearly for. With templates, apart from the normal usage for providing type-safe functions, they can be used to implement inheritance. Using templates to implement inheritance isn't as fully featured as run-time polymorphism and all that, but they are faster cos they do not need the vtables (ok it's a small cost). And with templates you can write code to generate code - statically compiled code, and that's really groovy. Unfortunately, right now in C++, it is difficult and unintuitive to do, but it is possible (there's a nice book that discusses some of these things, and you'll be amazed at what they can get templates to do - Generative Programming by Krzysztof Czarnecki, and Ulrich W. Eisenecker).

Well that's just my opinion... One of the reasons why I love C++ is because I have this feeling of safety when I use it. Basically I know whatever I want to do, it is possible (ok in very very rare circumstances it probably isn't).

Oh a brighter note, I think it is nice there's an import. At least there's none of that header file nested include nightmare... and I like not having to have another section to define my functions


Johnny

I personally am not a fan of templates, I agree they are powerful but they can lead to problems.  There is no relationship between set<float> and set<int> for instance although sometimes you might want a function to iterate through both types.  To do that you need to templatize the function and so on, the changes tend to cascade.  I think java has a better more elegant solution through rtti, a set class holds a set of references to Objects.  Types are checked on casting.

Having said all this there is 'allways' a trade off beween a 'nice' solution and the theoretically most efficient solution.  Sometimes people want the fastest solution and are prepared to make the sacrifice.

On a performance note I wonder if it might be worth letting the user run the garbage collector if they want to and specify the time its allowed to run. This would result in at least some of the memory freeing up if it doent manage to complete and would make the language suitable in systems such as realtime and computer gaming.

"Johnny Lai" <bl12@uow.edu.au> wrote in message news:9lgki2$24sf$1@digitaldaemon.com...
> Hi!
>
> Well I'm disappointed that people seem to feel that the preprocessor and templates are not features that are worth having...
>
> I personally miss the preprocessor when I use Java. Otherwise how do we do code tuned for multiple platforms in 1 source? Or to include debugging
code
> and removing at will (not just asserts)? Sometimes it's nice to have an extra level of indirection ^_^.. maybe we need instead is a preprocessor language that can be applied to any/many language(s) when needed.
>
> And templates! Yes they are complex stuff and I wish they were easier
but...
> they allow you to do things that you would otherwise be unable to do, or have to pay dearly for. With templates, apart from the normal usage for providing type-safe functions, they can be used to implement inheritance. Using templates to implement inheritance isn't as fully featured as
run-time
> polymorphism and all that, but they are faster cos they do not need the vtables (ok it's a small cost). And with templates you can write code to generate code - statically compiled code, and that's really groovy. Unfortunately, right now in C++, it is difficult and unintuitive to do,
but
> it is possible (there's a nice book that discusses some of these things,
and
> you'll be amazed at what they can get templates to do - Generative Programming by Krzysztof Czarnecki, and Ulrich W. Eisenecker).
>
> Well that's just my opinion... One of the reasons why I love C++ is
because
> I have this feeling of safety when I use it. Basically I know whatever I want to do, it is possible (ok in very very rare circumstances it probably isn't).
>
> Oh a brighter note, I think it is nice there's an import. At least there's none of that header file nested include nightmare... and I like not having to have another section to define my functions
>
>
> Johnny
>
>
>

"Nathan Matthews" <nedthefed@nospam.hotmail.com> wrote:
> I personally am not a fan of templates, I agree they are powerful but they can lead to problems.

  Pointers are powerfull but they can lead to problems.
  Exceptions are powerful but they can lead to problems.
  Macros are powerful, but they can lead to problems.
  ...

>                        There is no relationship between set<float> and
> set<int> for instance

  Of course, there is: To implement it by hand, you
  would write the exactly same code twice.

>                       although sometimes you might want a function to
> iterate through both types.

  Then you want two functions with exactly the same
  code that iterate through thier approriate sets.
  Isn't it amazing that there's a mechanism that
  allows you to do this by writing the function only
  once?

>                              To do that you need to templatize the function
> and so on, the changes tend to cascade.

  Yeah, in that is is like forgetting a 'const'
  somewhere in a header file. Adding it will yield
  another place where a 'const' is missing, this forces
  another 'const'.
  Such is the benefit of design errors. ;^>

  (Whenever I entered a project I quickly found myself
  spending hours adding missing 'const's all over the
  code. At the end of the day, those who had been in
  the project for a long time had stopped laughing
  about me wasting precious time because they were busy
  fixing their bugs which I found this way.)

>                                          I think java has a better more
> elegant solution through rtti, a set class holds a set of references to
> Objects.  Types are checked on casting.

  First: If you want to generalize a function within
  this model, you have to go through the exactly same
  painful process of generalizing all functions it
  depends on.
  Second: Such libraries exist in C++. For many many
  years. Many many libraries. Yet, STL came and
  conquered. What do you think why that happened?

> [...]

  Schobi

--
SpamTrap@gmx.de is never read
I'm hschober at gmx dot de

P.S.: Ich suche einen Job in Berlin.

In article <9lgki2$24sf$1@digitaldaemon.com>, Johnny Lai wrote:
> 
> Well I'm disappointed that people seem to feel that the preprocessor and templates are not features that are worth having...

Ok, these are reasons to look at.  Maybe not valid, but they are there...


> I personally miss the preprocessor when I use Java. Otherwise how do we do code tuned for multiple platforms in 1 source? Or to include debugging code and removing at will (not just asserts)? Sometimes it's nice to have an extra level of indirection ^_^.. maybe we need instead is a preprocessor language that can be applied to any/many language(s) when needed.

So much in such a small paragraph.  I'll try to address these all in sequence.

First, using a preprocessor to tune/port source to multiple platforms is a *VERY* bad idea.  As someone who as worked at porting various things to many different platforms, I can attest to that.  (10+ platforms, 2 huge products, 5.5M+ lines of source)

Having said that, an extra level of indirection is very nice to have. It is very usefull in debugging things quickly, and in hacking things up for various purposes.  It is however in direct conflict with writing production source.

A preprocessor exists with such a goal (at least under *nix), it is called m4.  It is not pretty, nor is it easy to learn, but it does do what you asked for...


> And templates! Yes they are complex stuff and I wish they were easier but... they allow you to do things that you would otherwise be unable to do, or have to pay dearly for. With templates, apart from the normal usage for providing type-safe functions, they can be used to implement inheritance.  Using templates to implement inheritance isn't as fully featured as run-time polymorphism and all that, but they are faster cos they do not need the vtables (ok it's a small cost). And with templates you can write code to generate code - statically compiled code, and that's really groovy.  Unfortunately, right now in C++, it is difficult and unintuitive to do, but it is possible (there's a nice book that discusses some of these things, and you'll be amazed at what they can get templates to do - Generative Programming by Krzysztof Czarnecki, and Ulrich W. Eisenecker).

Templates are an interesting idea.  I think that the fundamental problem with templates is that they went about solving the generic programming the wrong way.  (Of course, everybody has a different idea on this). The problem is one of the following (in C++):

int add2(int x, int y){
	return x+y;
}

long add2(long x, long y){
	return x+y;
}

This is the first type of generic programming.  Here two "compatible" types are being done an operation to.  In some sense, the exact same code is being produced (at least if int == long) for both of these functions.  It would be nice to be able to write the function once, and use it for both (in this case you can, int promotes to long).

In one sense, generic programming is about coallescing functions that are the same (at the binary level), or compiling to functions that are a little more generic, and thereby making more functions equivelant, and then collapsing them.


The other generic programming idea is one of where you write code
in a high-level language, and have the compiler generate different
code, which depends on the type(s) within the function.  This one is
harder to solve in the traditional edit-compile-link-run cycle of these
traditional languages.  The problem is one of not knowing ahead of time
what type(s) are going to be in every possible instantiation of the
function.  I can see two ways of solving this:

1) Every type is an object, and you generate a generic function, using the base object as the type.  In this way the generic function can always be used, but more specialized generated functions (for speed, etc) can also be explicitly generated at compile time.

2) Make the compile-link section be a loop, which loops until there are
no undefined symbols (generic functions) left to compile.  This breaks
the library encapsulation abstraction, as source (of some sort) for the
generic libraries would have to be available (user defined types will
need a new version of generic routines compiled from library source).


Given these constraints, I can see a good reason not to include templates in the current design of the language.  Instead forcing the writer of the library (or other sourcecode) to write "generic" functions in a manner more consistent with proceedural languages.  This is not always such a bad thing...


> Well that's just my opinion... One of the reasons why I love C++ is because I have this feeling of safety when I use it. Basically I know whatever I want to do, it is possible (ok in very very rare circumstances it probably isn't).

Almost any language has this property.


-- 
Tobias Weingartner |        Unix Guru, Admin, Systems-Dude
Apt B 7707-110 St. |        http://www.tepid.org/~weingart/
Edmonton, AB       |-------------------------------------------------
Canada, T6G 1G3    | %SYSTEM-F-ANARCHISM, The OS has been overthrown

Hendrik Schober wrote:

> "Nathan Matthews" <nedthefed@nospam.hotmail.com> wrote:
> > I personally am not a fan of templates, I agree they are powerful but they can lead to problems.

C++ Templates suck.  They suck solely because it is trying to support the
ancient C/C++ cruft.  The syntax
is horrific and awkward.  The old C types is the reason you need to explicitly
specify template parameters.

The template problem  should be solved.  I have typed an implementation of a
circularly linked list in C so
many times that I can disengage my brain and type a whole 150+ lines of code.

What's wrong with templates like this:

a' max (a' left, a' right)
{
     if (left > right) return left;
     return right;
}

In Standard ML, a' would be a type variable (in D, this would probably conflict
with the character-quoting operator, but for demonstration purposes...).  You
are telling the compiler that left and right are of the same
type and the function returns the same type.  There would be an expansion error
if you tried to use max with
a set of types that didn't support bool operator > ('a, 'a).  You could provide
specializations just by
explicitly specifying types.  I'm not sure that specializations are really
necessary.  No C++ pointer specialization junk, for sure.

If you wanted to do a lot of work on the language but make something really
cool, the function should be
declared like this:

max (left, right)
{
   if (left > right) return left;
   return right;
}

If you think about it, if the compiler can't infer a type restriction on the
arguments or the return value based on how they are used or returned from the
function, there is no reason for there to be one.  The compiler can
infer that the return type of the function must be the type of left, etc.

Okay, back to reality.  Think about this:

class a' list {
   void add (a' newelem) {
   }
   void remove (a' oldelem) {
   }
   int count () {
   }
};

int list i = new int list;
i.add(1);
i.add(2);

Not anywhere near so bad as C++, eh?  And we still solve a whole slew of
generalized programming issues
that we can't otherwise solve.  Look at Standard ML and Objective CAML for more
info.  I've wrote a few
programs in both (I do a lot of languages -- sort of my hobby along with
compiler/parser theory) -- I _love_
their type system but _hate_ the language syntax.

-Jay 'Eraserhead' Felice

"Johnny Lai" <bl12@uow.edu.au> wrote in message news:9lgki2$24sf$1@digitaldaemon.com...
> Well I'm disappointed that people seem to feel that the preprocessor and templates are not features that are worth having...

I expected heat about templates, but less so about the preprocessor.


> I personally miss the preprocessor when I use Java. Otherwise how do we do code tuned for multiple platforms in 1 source? Or to include debugging
code
> and removing at will (not just asserts)? Sometimes it's nice to have an extra level of indirection ^_^.. maybe we need instead is a preprocessor language that can be applied to any/many language(s) when needed.

I've dealt with much code over the years tuned for multiple platforms with #ifdef's. Inevitably, they turn into a hopeless snarl. I've since reached the conclusion that platform dependencies should be isolated to separate files and then write a new file for the different platforms.

Inserting and removing debugging code at will is ably handled with the debug attribute and debug statement. Asserts are not really debug code, but are part of the design by contract stuff.


> And templates! Yes they are complex stuff and I wish they were easier
but...
> they allow you to do things that you would otherwise be unable to do, or have to pay dearly for. With templates, apart from the normal usage for providing type-safe functions, they can be used to implement inheritance. Using templates to implement inheritance isn't as fully featured as
run-time
> polymorphism and all that, but they are faster cos they do not need the vtables (ok it's a small cost). And with templates you can write code to generate code - statically compiled code, and that's really groovy. Unfortunately, right now in C++, it is difficult and unintuitive to do,
but
> it is possible (there's a nice book that discusses some of these things,
and
> you'll be amazed at what they can get templates to do - Generative Programming by Krzysztof Czarnecki, and Ulrich W. Eisenecker).

Clearly, people like templates a *lot*. I'm going to have to think a lot more about this.

I agree with you. Templates are a great idea, but there's *got* to be a better way. I intend to find it <g>.

"Jason M. Felice" <jfelice@cronosys.com> wrote in message news:3B7C0A1E.35920B77@cronosys.com...
> Hendrik Schober wrote:
>
> > "Nathan Matthews" <nedthefed@nospam.hotmail.com> wrote:
> > > I personally am not a fan of templates, I agree they are powerful but
they
> > > can lead to problems.
>
> C++ Templates suck.  They suck solely because it is trying to support the
> ancient C/C++ cruft.  The syntax
> is horrific and awkward.  The old C types is the reason you need to
explicitly
> specify template parameters.
>
> The template problem  should be solved.  I have typed an implementation of
a
> circularly linked list in C so
> many times that I can disengage my brain and type a whole 150+ lines of
code.
>
> What's wrong with templates like this:
>
> a' max (a' left, a' right)
> {
>      if (left > right) return left;
>      return right;
> }
>
> In Standard ML, a' would be a type variable (in D, this would probably
conflict
> with the character-quoting operator, but for demonstration purposes...).
You
> are telling the compiler that left and right are of the same
> type and the function returns the same type.  There would be an expansion
error
> if you tried to use max with
> a set of types that didn't support bool operator > ('a, 'a).  You could
provide
> specializations just by
> explicitly specifying types.  I'm not sure that specializations are really
> necessary.  No C++ pointer specialization junk, for sure.
>
> If you wanted to do a lot of work on the language but make something
really
> cool, the function should be
> declared like this:
>
> max (left, right)
> {
>    if (left > right) return left;
>    return right;
> }
>
> If you think about it, if the compiler can't infer a type restriction on
the
> arguments or the return value based on how they are used or returned from
the
> function, there is no reason for there to be one.  The compiler can infer that the return type of the function must be the type of left, etc.
>
> Okay, back to reality.  Think about this:
>
> class a' list {
>    void add (a' newelem) {
>    }
>    void remove (a' oldelem) {
>    }
>    int count () {
>    }
> };
>
> int list i = new int list;
> i.add(1);
> i.add(2);
>
> Not anywhere near so bad as C++, eh?  And we still solve a whole slew of
> generalized programming issues
> that we can't otherwise solve.  Look at Standard ML and Objective CAML for
more
> info.  I've wrote a few
> programs in both (I do a lot of languages -- sort of my hobby along with
> compiler/parser theory) -- I _love_
> their type system but _hate_ the language syntax.
>
> -Jay 'Eraserhead' Felice
>

> I've dealt with much code over the years tuned for multiple platforms with #ifdef's. Inevitably, they turn into a hopeless snarl. I've since reached the conclusion that platform dependencies should be isolated to separate files and then write a new file for the different platforms.

Yes, agree. One way we did this in a project was to specify class objects that were global, across the platforms, and the implementation files then had implementations for each platform, included via makefiles. That makes me wonder if this could be done in D in case the header files are gone, and we are dealing with modules, so it would be nice to somehow indicate the implementation detail (or then write multiple modules for each platform...). --Kent

"Kent Sandvik" <sandvik@excitehome.net> wrote in message news:9lho7p$as5$1@digitaldaemon.com...
> > I've dealt with much code over the years tuned for multiple platforms
with
> > #ifdef's. Inevitably, they turn into a hopeless snarl. I've since
reached
> > the conclusion that platform dependencies should be isolated to separate files and then write a new file for the different platforms.
>
> Yes, agree. One way we did this in a project was to specify class objects that were global, across the platforms, and the implementation files then had implementations for each platform, included via makefiles. That makes
me
> wonder if this could be done in D in case the header files are gone, and
we
> are dealing with modules, so it would be nice to somehow indicate the implementation detail (or then write multiple modules for each platform...). --Kent

I think it would fall naturally out of D. A switch to the compiler tells it where to look for the imports for the target platform.

Walter wrote:
> 
> "Kent Sandvik" <sandvik@excitehome.net> wrote in message news:9lho7p$as5$1@digitaldaemon.com...
> > > I've dealt with much code over the years tuned for multiple platforms
> with
> > > #ifdef's. Inevitably, they turn into a hopeless snarl. I've since
> reached
> > > the conclusion that platform dependencies should be isolated to separate files and then write a new file for the different platforms.
> >
> > Yes, agree. One way we did this in a project was to specify class objects that were global, across the platforms, and the implementation files then had implementations for each platform, included via makefiles. That makes
> me
> > wonder if this could be done in D in case the header files are gone, and
> we
> > are dealing with modules, so it would be nice to somehow indicate the implementation detail (or then write multiple modules for each platform...). --Kent
> 
> I think it would fall naturally out of D. A switch to the compiler tells it where to look for the imports for the target platform.

I nearly jumped for joy upon seeing D's "debug" attribute. At the risk of getting stomped on for proposing a new keyword, how about adding a "config" attribute, with an identifier:

   config (MacOSX)
   {
      // do OS X specific stuff
   }
   config (Win32)
   {
      // do Win32 specific stuff
   }
   config (PalmOS)
   {
      // do PalmOS specific stuff
   }

again, with compiler switches to pass in the identifier?