View mode: basic / threaded / horizontal-split · Log in · Help
August 16, 2001
*sigh*
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
August 16, 2001
Re: *sigh*
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
>
>
>
August 16, 2001
Re: *sigh*
"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.
August 16, 2001
Re: *sigh*
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
August 16, 2001
Re: *sigh*
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
August 16, 2001
Re: *sigh*
"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.
August 16, 2001
Re: *sigh*
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
>
August 17, 2001
Re: *sigh*
> 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
August 17, 2001
Re: *sigh*
"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.
August 17, 2001
Re: *sigh*
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?
« First   ‹ Prev
1 2 3 4
Top | Discussion index | About this forum | D home