www.digitalmars.com         C & C++   DMDScript  

D - Favoriate features to remove from D.

reply Bill Cox <bill viasic.com> writes:
Hi, again.  Obviously, I can't sleep.

A real danger to a language like D is falling to the Creepy Feature 
Creature.  This monster eats promising new languages for breakfast.

I've noticed that not only does D have a lot of features, there are a 
LOT of requests for more (like in my last post about the while loops). 
If you had to get rid of anything, what would it be?

Here's a short list of things I could probably live without:

- alias: Never felt like I needed it in Pascal.

- function overloading, other than operator overloading: A good long 
function name never hurt code readability.

- goto statements: Haven't we won this argument yet?  It's been decades 
now...

- break and continue statements: You can use subroutines and return 
statements instead.  Generally the code is more readable in this form.

- Assignments in expressions: I accidently type if(a = b) much too 
often... and when I'm reading code, I often fail to see the assignment.

- Fall through in case statements: Missing break statements can be ugly 
bugs to find.

And here are the two really big one that will forever be debated:

- pointers

I'm a huge speed freak, but I just don't need pointers.  I'm really sick 
of debugging pointer spaghetti.  I haven't seen a good use of ** types 
(pointers to pointers) in years.  Ever debug a function that takes a *** 
argument?  Lots of fun!

- garbage collection

It's already in D, and that's not going to change, but just to continue 
the endless debate...

GC is a good solution to a problem that has a better solution.  Speed 
freaks like me want objects of each class allocated together in memory 
to make better use of cache (or even more advanced memory layouts).  The 
compiler should do that automatically.  The compiled code should compact 
and reclaim memory whenever I ask it to, not whenever it wants.  I just 
want to write 'new' and 'delete', and get awesomely fast and seg-v free 
code.  And, I never want to write my own destructors.  Fix the pointers 
for me.  It requires more from the compiler, and a small addition to the 
language (to specify which children to recursively delete).  It really 
does work.  We do this now where I work.

Here's another major one:

- templates

These things confuse the heck out of my new programmers.  It is the 
single most confusing thing in C++.  That would be OK if they were 
really powerful, but templates simply don't have much power compared to 
full code generators.  Why not add support for code generators to the 
language instead?  Try doing this with a template: stream out all you 
data structures to a file in binary.  Do it with 1 line of code.  A code 
generator can do this, but templates can't.

Bill Cox
Jan 25 2003
next sibling parent Ilya Minkov <midiclub 8ung.at> writes:
Bill Cox wrote:

 Hi, again.  Obviously, I can't sleep.
 
 A real danger to a language like D is falling to the Creepy Feature 
 Creature.  This monster eats promising new languages for breakfast.
 
 I've noticed that not only does D have a lot of features, there are a 
 LOT of requests for more (like in my last post about the while loops). 
 If you had to get rid of anything, what would it be?
 
 Here's a short list of things I could probably live without:



Ho ahead and hack Sather. It lacks of most things you hate so much! You 
simply have to shut off its GC and there you go!!!
Jan 25 2003
prev sibling next sibling parent reply Garen Parham <garen_nospam_ wsu.edu> writes:
Hi Bill, thought you might like a reply.

Bill Cox wrote:
...

 If you had to get rid of anything, what would it be?


I mentioned it earlier in another post, but it would mainly be some of the
pointer-usage/declarator syntax still in D.  With arrays being a more first
class notion in D I don't think anything more than one level of indirection
(via * or whatever) is necessary.


 
 Here's a short list of things I could probably live without:
 
 - alias: Never felt like I needed it in Pascal.
 


I like this one.  I'd bet they could also play a more important role when/if
D gets a more worked-out template/generics implementation.


 - function overloading, other than operator overloading: A good long 
 function name never hurt code readability.
 


Really have to disagree strongly with this one.  Ever looked at the GTK API
versus QT?  They have
lots_of_very_long_function_names_that_do_specialized_things_that_make_it_hard_to_keep_track_of_everything_that_you_are_doing.
:)  Probably something that becomes more of a necessity in libraries/APIs
etc.


 - goto statements: Haven't we won this argument yet?  It's been decades 
 now...
 


It's certainly not any good substitute for control flow.  Technically the
only good argument for it left in C/C++ IMO was breaking out of big nested
loops, which is solved in D by "break <identifier>."  I've heard from some
performance die-hards that they sometimes use it in critical codepaths
where the optimizer didn't do a good job, but these days thats probably of
very little importance.


 - break and continue statements: You can use subroutines and return 
 statements instead.  Generally the code is more readable in this form.


I use these sparingly and haven't ever noticed any readability problems. 
Could be an ingrained thing though.


 
 - Assignments in expressions: I accidently type if(a = b) much too 
 often... and when I'm reading code, I often fail to see the assignment.
 


What would you suggest instead? ":="?


 - Fall through in case statements: Missing break statements can be ugly 
 bugs to find.


I agree.  Haven't personally had to chase many bugs of that kind though.


 
 And here are the two really big one that will forever be debated:
 
 - pointers
 
 I'm a huge speed freak, but I just don't need pointers.  I'm really sick 
 of debugging pointer spaghetti.  I haven't seen a good use of ** types 
 (pointers to pointers) in years.  Ever debug a function that takes a *** 
 argument?  Lots of fun!
 


Agreed++;  See earlier comment on indirection.  Btw, take a look at the D
front-end, there are a number of **'s in there.  If it was rewritten in D I
bet they could go away.


 - garbage collection
 
 It's already in D, and that's not going to change, but just to continue 
 the endless debate...
 
 GC is a good solution to a problem that has a better solution.  Speed 
 freaks like me want objects of each class allocated together in memory 
 to make better use of cache (or even more advanced memory layouts).  The 
 compiler should do that automatically.  The compiled code should compact 
 and reclaim memory whenever I ask it to, not whenever it wants.  I just 
 want to write 'new' and 'delete', and get awesomely fast and seg-v free 
 code.  And, I never want to write my own destructors.  Fix the pointers 
 for me.  It requires more from the compiler, and a small addition to the 
 language (to specify which children to recursively delete).  It really 
 does work.  We do this now where I work.


Would be nice if you could selectively disable GC for small sections that
really need it.


 
 Here's another major one:
 
 - templates
 
 These things confuse the heck out of my new programmers.  It is the 
 single most confusing thing in C++.  That would be OK if they were 
 really powerful, but templates simply don't have much power compared to 
 full code generators.  Why not add support for code generators to the 
 language instead?  Try doing this with a template: stream out all you 
 data structures to a file in binary.  Do it with 1 line of code.  A code 
 generator can do this, but templates can't.
 


That kinda surprises me.  In C++ I use templates a lot and they're the most
powerful feature in the language I think.  My biggest complaint would be
the lack of a native way to specify constraints -- I hate seeing huge piles
of error messages spilled out in front of me.  (A huge problem when you use
something like MSVC6, which is well known for being such a POS C++
compiler.  Witness the proliferation of "c++filt" scripts/programs).  I

template declaration to specify what valid inputs are.

Not sure what to say about your code generator comment...  templates aren't
that, so I don't see how they can be compared.
Jan 25 2003
parent reply Bill Cox <bill viasic.com> writes:
Thanks for the reply.  Reasonable points of view...  To answer your 
questions:


- Assignments in expressions: I accidently type if(a = b) much too 
often... and when I'm reading code, I often fail to see the assignment.


 
 
 What would you suggest instead? ":="


I don't like to write assignments anywhere but in a variable declaration 
or an assignment statement.  If I could convince everyone to program 
like me, I'd simply make the following syntax illegal:

     if(x = y)

Of course, these kinds of things are minor issues, and nothing to get 
worked up about.


- templates
These things confuse the heck out of my new programmers.  It is the 
single most confusing thing in C++.  That would be OK if they were 
really powerful, but templates simply don't have much power compared to 
full code generators.  Why not add support for code generators to the 
language instead?  Try doing this with a template: stream out all you 
data structures to a file in binary.  Do it with 1 line of code.  A code 
generator can do this, but templates can't.


 
 
 That kinda surprises me.  In C++ I use templates a lot and they're the most
 powerful feature in the language I think.  My biggest complaint would be
 the lack of a native way to specify constraints -- I hate seeing huge piles
 of error messages spilled out in front of me.  (A huge problem when you use
 something like MSVC6, which is well known for being such a POS C++
 compiler.  Witness the proliferation of "c++filt" scripts/programs).  I

 template declaration to specify what valid inputs are.
 
 Not sure what to say about your code generator comment...  templates aren't
 that, so I don't see how they can be compared.


Templates are a simple form of code generation: they let you generate 
new class code with some names substituted. You can do that in C++ with 
the preprocessor (yuk!).

Code generators in a program like the Rational Rose class diagram editor 
or DataDraw have a representation of the program's data structures and 
are able to generate all kinds of things.  The simple example is a 
linked list with the next pointer embedded in the child class.  Another 
is recursive destructor functions.

I'm curios to know how you use templates.  Are you just using the 
standard template library, or do you often write your own templates.  If 
you do, what problems are you solving with them?

Bill Cox
Jan 25 2003
next sibling parent reply Nicolas Fleury <nid_oizo yahoo.com_remove_the_> writes:
Bill Cox wrote:

 Templates are a simple form of code generation: they let you generate 
 new class code with some names substituted. You can do that in C++ with 
 the preprocessor (yuk!).


The most important thing about templates is that they create different 
types.  Its also a compile-time strategy.  Yes, I create my own classes 
that has traits, you want a code generator to place traits and policies 
in your classes and make a different type?  That would look more complex 
than C++ I think.  Look at the STL quick sort algorithm, using functors 
it's faster than any configurable C implementation, since the functor 
call can be inlined.  I can't a tool to generate that code without 
thinking about something even more-tool based than VB.  That's not what 
D is intended to be I think.


 Code generators in a program like the Rational Rose class diagram editor 
 or DataDraw have a representation of the program's data structures and 
 are able to generate all kinds of things.  The simple example is a 
 linked list with the next pointer embedded in the child class.  Another 
 is recursive destructor functions.
 
 I'm curios to know how you use templates.  Are you just using the 
 standard template library, or do you often write your own templates.  If 
 you do, what problems are you solving with them?


I don't know for Garen, but where I work we use templates a lot. 
Implementation of the Multicast pattern (a type-safe event system is 
something I consider important), compile-time policies and traits, 
template restrictions (D could have that built-in in language), 
type-safe containers (even Java is adding generics).  Most of our 
template uses are done in the basic libraries and applications code 
contains usually no templates.  I suggest you to look at Alexandrescu's 
Modern C++ Design, while this book might show the most complicated use 
of templates, it also shows that templates are not only what you seem to 
think.

Regards,

Nicolas
Jan 26 2003
parent reply Bill Cox <bill viasic.com> writes:
Hi, Nicolas.


 Templates are a simple form of code generation: they let you generate 
 new class code with some names substituted. You can do that in C++ 
 with the preprocessor (yuk!).


 
 
 The most important thing about templates is that they create different 
 types.  Its also a compile-time strategy.  Yes, I create my own classes 
 that has traits, you want a code generator to place traits and policies 
 in your classes and make a different type?  That would look more complex 
 than C++ I think.  Look at the STL quick sort algorithm, using functors 
 it's faster than any configurable C implementation, since the functor 
 call can be inlined.  I can't a tool to generate that code without 
 thinking about something even more-tool based than VB.  That's not what 
 D is intended to be I think.
 

 Code generators in a program like the Rational Rose class diagram 
 editor or DataDraw have a representation of the program's data 
 structures and are able to generate all kinds of things.  The simple 
 example is a linked list with the next pointer embedded in the child 
 class.  Another is recursive destructor functions.

 I'm curios to know how you use templates.  Are you just using the 
 standard template library, or do you often write your own templates.  
 If you do, what problems are you solving with them?


 
 
 I don't know for Garen, but where I work we use templates a lot. 
 Implementation of the Multicast pattern (a type-safe event system is 
 something I consider important), compile-time policies and traits, 
 template restrictions (D could have that built-in in language), 
 type-safe containers (even Java is adding generics).  Most of our 
 template uses are done in the basic libraries and applications code 
 contains usually no templates.  I suggest you to look at Alexandrescu's 
 Modern C++ Design, while this book might show the most complicated use 
 of templates, it also shows that templates are not only what you seem to 
 think.


As was mentioned in an earlier post, templates and code generators are 
really different animals.  I've erred in comparing them so directly. 
However, the use of the code generator I currently use eliminates the 
most common use of templates I see: type-safe container classes.  More 
importantly, it generates better code, since both the parent and child 
classes are modified, not just the parent.

I'm really happy with what I get with the code generators.  I get: 
virtually no dangling pointers (auto-generated bug-free recursive 
destructures); really efficient and type safe containers (really more 
like relationships - the name container implies the enclosed object is 
not really collaborating); automatic and truely outstanding memory 
management; extensive debugging support such as checking each memory 
access (much like running under Purify, but not as complete); 
auto-generated itterators with foreach syntax; and VERY importantly - 
highly efficient dynamic class extensions (dynamic inheritance?).  The 
dynamic class extensions is huge for us, since our code runs off of a 
common database, and we often need to extend objects in the database 
that already have been constructed.  Dynamic extensions are probably 
about 10x more common in our code than static inheritance.

The code generators we use at work are a major impact on every day 
coding.  There's just less work to do, and fewer ways to shoot yourself 
in the foot.

Last time I read a linked list template class in full detail (Rogue-Wave 
in the late 90's), adding an element to a linked list generated a call 
to malloc (yuk!).  A linked list should have a next pointer embedded in 
the child.  The majority of one-to-many relationships need data embedded 
in the child.  How can templates help with that?

Bill Cox
Jan 26 2003
next sibling parent Nicolas Fleury <nid_oizo yahoo.com_remove_the_> writes:
Bill Cox wrote:

 Last time I read a linked list template class in full detail (Rogue-Wave 
 in the late 90's), adding an element to a linked list generated a call 
 to malloc (yuk!).  A linked list should have a next pointer embedded in 
 the child.  The majority of one-to-many relationships need data embedded 
 in the child.  How can templates help with that?


By using something like boost::array (if I understand your question 
correctly).

Templates are used to make decisions at compile-time.  You talk about 
code generation and dynamic inheritance; I don't see the relation since 
code generation is decisions you take at compile-time, right?  If you 
take the decision at compile-time, you can do it with templates.  The 
boost::MPL library is a good example.

By code generation, do you also mean data-driven programs?  If so, I 
totally agree that they provide many useful features.  Using languages 
like Python in a C++/D program is also an interesting alternative.  But 
still, I see D as a language under the hood of what you're talking about 
and at that level templates have a high value.

Regards,

Nicolas
Jan 26 2003
prev sibling parent reply Ilya Minkov <midiclub tiscali.de> writes:
You're right, flexible code generator is a way to go. This is a common 
solution for template-like things, as well as implementing new syntactic 
constructs. This is what i am going to adress. It would also allow 
writing compilers for other languages, using D as a back end.

Bill Cox wrote:

 Hi, Nicolas.
 

 Templates are a simple form of code generation: they let you generate 
 new class code with some names substituted. You can do that in C++ 
 with the preprocessor (yuk!).




 The most important thing about templates is that they create different 
 types.  Its also a compile-time strategy.  Yes, I create my own 
 classes that has traits, you want a code generator to place traits and 
 policies in your classes and make a different type?  That would look 
 more complex than C++ I think.  Look at the STL quick sort algorithm, 
 using functors it's faster than any configurable C implementation, 
 since the functor call can be inlined.  I can't a tool to generate 
 that code without thinking about something even more-tool based than 
 VB.  That's not what D is intended to be I think.


 Code generators in a program like the Rational Rose class diagram 
 editor or DataDraw have a representation of the program's data 
 structures and are able to generate all kinds of things.  The simple 
 example is a linked list with the next pointer embedded in the child 
 class.  Another is recursive destructor functions.

 I'm curios to know how you use templates.  Are you just using the 
 standard template library, or do you often write your own templates.  
 If you do, what problems are you solving with them?




 I don't know for Garen, but where I work we use templates a lot. 
 Implementation of the Multicast pattern (a type-safe event system is 
 something I consider important), compile-time policies and traits, 
 template restrictions (D could have that built-in in language), 
 type-safe containers (even Java is adding generics).  Most of our 
 template uses are done in the basic libraries and applications code 
 contains usually no templates.  I suggest you to look at 
 Alexandrescu's Modern C++ Design, while this book might show the most 
 complicated use of templates, it also shows that templates are not 
 only what you seem to think.


 
 
 As was mentioned in an earlier post, templates and code generators are 
 really different animals.  I've erred in comparing them so directly. 
 However, the use of the code generator I currently use eliminates the 
 most common use of templates I see: type-safe container classes.  More 
 importantly, it generates better code, since both the parent and child 
 classes are modified, not just the parent.
 
 I'm really happy with what I get with the code generators.  I get: 
 virtually no dangling pointers (auto-generated bug-free recursive 
 destructures); really efficient and type safe containers (really more 
 like relationships - the name container implies the enclosed object is 
 not really collaborating); automatic and truely outstanding memory 
 management; extensive debugging support such as checking each memory 
 access (much like running under Purify, but not as complete); 
 auto-generated itterators with foreach syntax; and VERY importantly - 
 highly efficient dynamic class extensions (dynamic inheritance?).  The 
 dynamic class extensions is huge for us, since our code runs off of a 
 common database, and we often need to extend objects in the database 
 that already have been constructed.  Dynamic extensions are probably 
 about 10x more common in our code than static inheritance.
 
 The code generators we use at work are a major impact on every day 
 coding.  There's just less work to do, and fewer ways to shoot yourself 
 in the foot.
 
 Last time I read a linked list template class in full detail (Rogue-Wave 
 in the late 90's), adding an element to a linked list generated a call 
 to malloc (yuk!).  A linked list should have a next pointer embedded in 
 the child.  The majority of one-to-many relationships need data embedded 
 in the child.  How can templates help with that?
 
 Bill Cox
Jan 27 2003
parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
D would make an excellent back-end language.  C makes a good back end, but
it's really showing its age.  D is more powerful in some ways and safer.

What I would like is for D to also be an excellent front-end language!!  ;)

Sean

"Ilya Minkov" <midiclub tiscali.de> wrote in message
news:b135kt$1u11$1 digitaldaemon.com...

 You're right, flexible code generator is a way to go. This is a common
 solution for template-like things, as well as implementing new syntactic
 constructs. This is what i am going to adress. It would also allow
 writing compilers for other languages, using D as a back end.
Jan 27 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
news:b13tup$2b8s$1 digitaldaemon.com...

 D would make an excellent back-end language.  C makes a good back end, but
 it's really showing its age.  D is more powerful in some ways and safer.


Several times I considered making D output C code, but there are just a lot
of problems making it work (such as no exception handling in C).
Mar 06 2003
next sibling parent "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
I think you misunderstood my point here... I was saying new 5GL's could use
D as a backend intermediate language, instead of C or ASM.  ;)  D is
feature-rich relative to C, yet still efficient... and safer.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:b49alu$19vu$1 digitaldaemon.com...

 "Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
 news:b13tup$2b8s$1 digitaldaemon.com...

 D would make an excellent back-end language.  C makes a good back end,




but

 it's really showing its age.  D is more powerful in some ways and safer.


 Several times I considered making D output C code, but there are just a


lot

 of problems making it work (such as no exception handling in C).
Mar 06 2003
prev sibling parent reply Kublai Kahn <Kublai_member pathlink.com> writes:
In article <b49alu$19vu$1 digitaldaemon.com>, Walter says...

"Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
news:b13tup$2b8s$1 digitaldaemon.com...

 D would make an excellent back-end language.  C makes a good back end, but
 it's really showing its age.  D is more powerful in some ways and safer.


Several times I considered making D output C code, but there are just a lot
of problems making it work (such as no exception handling in C).


If not making D output C code you can make D output C++ code.

D Rocks!!!
---------------------------------------
http://www.digitalmars.com/d/index.html
Mar 07 2003
parent "Walter" <walter digitalmars.com> writes:
"Kublai Kahn" <Kublai_member pathlink.com> wrote in message news:b4b0h0

 If not making D output C code you can make D output C++ code.


True, but there are more problems there (like no nested functions).


 D Rocks!!!


True. <g>
Mar 07 2003
prev sibling parent reply Garen Parham <garen_nospam_ wsu.edu> writes:
Bill Cox wrote:

 I don't like to write assignments anywhere but in a variable declaration 
 or an assignment statement.  If I could convince everyone to program 
 like me, I'd simply make the following syntax illegal:
 
      if(x = y)
 
 Of course, these kinds of things are minor issues, and nothing to get 
 worked up about.
 


Ah, yeah I do the same thing.  As a general rule of thumb, I think its more
readable to write out your code in smaller, simpler steps instead of
combining them into big heaps of compound expressions.  


 
 Templates are a simple form of code generation: they let you generate 
 new class code with some names substituted. You can do that in C++ with 
 the preprocessor (yuk!).
 


For the really basic templates you could perhaps write macros for them, but
for more sophisticated ones that rely on some kind of compile-time decision
making, they're out -- assuming you want a single interface.  (C++ went so
far to make the preprocessor unnecessary it would have been nice if they
officially deprecated much of its use).


 
 I'm curios to know how you use templates.  Are you just using the 
 standard template library, or do you often write your own templates.  If 
 you do, what problems are you solving with them?
 


At first I just made cursory use of them with the library.  Later when I got
curious to see how the stuff was implemented I looked through the source
and saw how it worked and then started building my own stuff.  Now I notice
that in general when I "refactor" code it tends to go into templates.  I
don't think there's any kind of specific problems that I tend to solve with
them; just whenever I happen to notice some repetitive pattern, I move it
into a template.

In another post I see someone recommended Andre's book -- that one is pretty
good, but I'd recommend "C++ Templates: The Complete Guide" by Josuttis &
Vandevoorde (new book) over it.  I just finished reading it and it covers
all the basics and has a tour through some well known techniques in a
tutorial/example style. Some of the more "advanced" techniques that aren't
so obvious are probably best to be avoided for the sake of clarity.
Jan 26 2003
parent reply Ilya Minkov <midiclub tiscali.de> writes:
IMO,

if (a=b) {}

is a clear bug, i've stumbled over more than a couple of times. And it's 
not necessarily easy to track down. Likewise:

int j;
for (int i=1; 1<=max; j++) {}

Well, this is the most stupid example, but it illustrates several things 
which may actually happen when editing a piece of code a number of 
times. Well, this example "for" is no use at all and should have no 
forgiving.

Basically, "dirty constructs" like this are to issue warnings. If 
someone does this on purpose, a keyword should exist, like "violate" or 
"crude", which would simply shut off a warning. This could considerably 
bloat a semantic analyzer though.

A keyword is also some typing, and should slowly discourage even the 
most eager fans of these dirty tricks.

Some systems use something like a pragma, which shuts all warnings or 
certain classes of warnings off, and then there usually exists an 
opposite one to turn them on back again. But IMO this would have no 
teaching efect, since people would be tempted to turn the warnings off 
and never turn them on again.




Garen Parham wrote:

 Bill Cox wrote:
 

I don't like to write assignments anywhere but in a variable declaration 
or an assignment statement.  If I could convince everyone to program 
like me, I'd simply make the following syntax illegal:

     if(x = y)

Of course, these kinds of things are minor issues, and nothing to get 
worked up about.


 
 
 Ah, yeah I do the same thing.  As a general rule of thumb, I think its more
 readable to write out your code in smaller, simpler steps instead of
 combining them into big heaps of compound expressions.  
 
 

Templates are a simple form of code generation: they let you generate 
new class code with some names substituted. You can do that in C++ with 
the preprocessor (yuk!).


 
 
 For the really basic templates you could perhaps write macros for them, but
 for more sophisticated ones that rely on some kind of compile-time decision
 making, they're out -- assuming you want a single interface.  (C++ went so
 far to make the preprocessor unnecessary it would have been nice if they
 officially deprecated much of its use).
 
 

I'm curios to know how you use templates.  Are you just using the 
standard template library, or do you often write your own templates.  If 
you do, what problems are you solving with them?


 
 
 At first I just made cursory use of them with the library.  Later when I got
 curious to see how the stuff was implemented I looked through the source
 and saw how it worked and then started building my own stuff.  Now I notice
 that in general when I "refactor" code it tends to go into templates.  I
 don't think there's any kind of specific problems that I tend to solve with
 them; just whenever I happen to notice some repetitive pattern, I move it
 into a template.
 
 In another post I see someone recommended Andre's book -- that one is pretty
 good, but I'd recommend "C++ Templates: The Complete Guide" by Josuttis &
 Vandevoorde (new book) over it.  I just finished reading it and it covers
 all the basics and has a tour through some well known techniques in a
 tutorial/example style. Some of the more "advanced" techniques that aren't
 so obvious are probably best to be avoided for the sake of clarity.
Jan 27 2003
next sibling parent Garen Parham <garen_nospam_ wsu.edu> writes:
Ilya Minkov wrote:


 IMO,
 
 if (a=b) {}
 
 is a clear bug, i've stumbled over more than a couple of times. And it's 
 not necessarily easy to track down. Likewise:


Definately.  The compilers I use usually warn about that though, and I don't
think I've ever made that mistake myself.


 
 int j;
 for (int i=1; 1<=max; j++) {}
 
 Well, this is the most stupid example, but it illustrates several things 
 which may actually happen when editing a piece of code a number of 
 times. Well, this example "for" is no use at all and should have no 
 forgiving.


That one is probably an error.  If so, probably not easy to catch or for a
compiler to notice.  I had to look at that twice to notice the problem.  It
doesn't help that the characters 1, i and l look pretty similar (at least
in the font I'm using).


 
 Basically, "dirty constructs" like this are to issue warnings. If 
 someone does this on purpose, a keyword should exist, like "violate" or 
 "crude", which would simply shut off a warning. This could considerably 
 bloat a semantic analyzer though.
 
 A keyword is also some typing, and should slowly discourage even the 
 most eager fans of these dirty tricks.
 
 Some systems use something like a pragma, which shuts all warnings or 
 certain classes of warnings off, and then there usually exists an 
 opposite one to turn them on back again. But IMO this would have no 
 teaching efect, since people would be tempted to turn the warnings off 
 and never turn them on again.
 


I really hate it when I see some pragma to disable a warning that just
includes some magic number.  I have no idea which thing it is trying to
disable and have little desire to stop suddenly to go look it up.  I much
prefer the long syntax the gnu compiler uses (-fnowhatever) but that can
get unwieldy too I guess.
Jan 28 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Ilya Minkov" <midiclub tiscali.de> wrote in message
news:b136sj$1ufm$1 digitaldaemon.com...

 IMO,

 if (a=b) {}

 is a clear bug, i've stumbled over more than a couple of times. And it's
 not necessarily easy to track down. Likewise:


D will give you a syntax error on that.
Mar 07 2003
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Bill Cox wrote:


 - alias: Never felt like I needed it in Pascal.


I'm not (directly) a fan of alias.  However, I *am* a fan of typechecked
typedefs.  That is, if you do this:
    typedef uint myTypedef;
then you shouldn't be able to do implicit casts between uint and myTypedef.

In that context, I think alias is necessary because it allows you to create
a non-checked typedef.  Like what I almost always do in my D programs:
    alias bit bool;
or
    alias int s32;
    alias uint u32;
Stuff like that.


 - goto statements: Haven't we won this argument yet?  It's been decades
 now...


Did you read the link that referred to the Linux argument about goto?
Sometimes, judiciously used, goto's are MORE readable than looping syntax.
Like if you want to jump into the middle of a while loop, rather than start
at the beginning.


 - Assignments in expressions: I accidently type if(a = b) much too
 often... and when I'm reading code, I often fail to see the assignment.


Right.  D++ should REQUIRE bool's as inputs into if(), for(), while(),
etc...


 - Fall through in case statements: Missing break statements can be ugly
 bugs to find.


Hear, hear!


 - pointers

 I'm a huge speed freak, but I just don't need pointers.  I'm really sick
 of debugging pointer spaghetti.  I haven't seen a good use of ** types
 (pointers to pointers) in years.  Ever debug a function that takes a ***
 argument?  Lots of fun!


I agree that pointers can be misused.  But if you don't use them, then how
are you going to interface with C?


 - garbage collection

 It's already in D, and that's not going to change, but just to continue
 the endless debate...

 GC is a good solution to a problem that has a better solution.  Speed
 freaks like me want objects of each class allocated together in memory
 to make better use of cache (or even more advanced memory layouts).  The
 compiler should do that automatically.  The compiled code should compact
 and reclaim memory whenever I ask it to, not whenever it wants.  I just
 want to write 'new' and 'delete', and get awesomely fast and seg-v free
 code.  And, I never want to write my own destructors.  Fix the pointers
 for me.  It requires more from the compiler, and a small addition to the
 language (to specify which children to recursively delete).  It really
 does work.  We do this now where I work.


I agree:
The compiler should include mechanisms (weak pointers, perhaps) that allow a
garbage object to be "returned to the pool" rather than deleted.  :Likewise,
you don't want the GC to run just anywhere...but that's already possible
with gc.disable() and gc.enable().  Also, remember that the GC *only runs*
because of a new operator...so if you're so worried about performance in an
area, don't try to allocate memory there!

I disagree:
That GC is fundamentally flawed.  By the "speed freak" argument we all
should abandon new and malloc as well.  Heck, let's go back to assembly and
write our heaps by hand, if that's the kind of speed you want.

The GC can be turned off.  If you don't want it, don't use it.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Jan 27 2003
parent reply Bill Cox <bill viasic.com> writes:
Hi, Russ.

Russ Lewis wrote:

 Bill Cox wrote:
 
 

- alias: Never felt like I needed it in Pascal.


 
 
 I'm not (directly) a fan of alias.  However, I *am* a fan of typechecked
 typedefs.  That is, if you do this:
     typedef uint myTypedef;
 then you shouldn't be able to do implicit casts between uint and myTypedef.
 
 In that context, I think alias is necessary because it allows you to create
 a non-checked typedef.  Like what I almost always do in my D programs:
     alias bit bool;
 or
     alias int s32;
     alias uint u32;
 Stuff like that.


Yes, that's a nice use for aliases.  I guess I'd miss it if it weren't 
there.

BTW, your example reminds me that there has been some discussion of 
variable size int type with proposed syntax like int:32, but I don't 
think Walter likes the look, or the additional compiler complexity.  How 
about having the lexer directly recognise int24 as an Bison KINT token, 
with lval.intVal of 24?  That's how I did it in a fun little compiler I 
wrote.


- goto statements: Haven't we won this argument yet?  It's been decades
now...


 
 
 Did you read the link that referred to the Linux argument about goto?
 Sometimes, judiciously used, goto's are MORE readable than looping syntax.
 Like if you want to jump into the middle of a while loop, rather than start
 at the beginning.


Jumping into a while loop :-O!  I think I'll just continue to be anal 
and keep the gotos out.  Actually, a reasonable use of goto's I've seen 
is in C where you don't have the finally keyword with setjmp/longjmp. 
Without the goto, you often duplicate a modules clean-up code.  Still, I 
find life simpler in a group programming environment if you just make 
concrete rules, like no gotos, and live with them.


- Assignments in expressions: I accidently type if(a = b) much too
often... and when I'm reading code, I often fail to see the assignment.


 
 
 Right.  D++ should REQUIRE bool's as inputs into if(), for(), while(),
 etc...


Definately.


- Fall through in case statements: Missing break statements can be ugly
bugs to find.


 
 
 Hear, hear!
 
 

- pointers

I'm a huge speed freak, but I just don't need pointers.  I'm really sick
of debugging pointer spaghetti.  I haven't seen a good use of ** types
(pointers to pointers) in years.  Ever debug a function that takes a ***
argument?  Lots of fun!


 
 
 I agree that pointers can be misused.  But if you don't use them, then how
 are you going to interface with C?


It's hard.  Where I work, we allow pointers to be used in exactly three 
ways:

1) Interfacing to C libraries (mostly just char *'s)
2) Multiple return values.  D eliminates this one.
3) Function pointers for callback routines.

Under no circumstances to we allow **'s.

All other uses of pointers are hidden under the hood by the database 
code generators.  Mosly, they just get typedef-ed away, but there really 
still there.  D does a find job of hiding these pointers automatically.


- garbage collection

It's already in D, and that's not going to change, but just to continue
the endless debate...

GC is a good solution to a problem that has a better solution.  Speed
freaks like me want objects of each class allocated together in memory
to make better use of cache (or even more advanced memory layouts).  The
compiler should do that automatically.  The compiled code should compact
and reclaim memory whenever I ask it to, not whenever it wants.  I just
want to write 'new' and 'delete', and get awesomely fast and seg-v free
code.  And, I never want to write my own destructors.  Fix the pointers
for me.  It requires more from the compiler, and a small addition to the
language (to specify which children to recursively delete).  It really
does work.  We do this now where I work.


 
 
 I agree:
 The compiler should include mechanisms (weak pointers, perhaps) that allow a
 garbage object to be "returned to the pool" rather than deleted.  :Likewise,
 you don't want the GC to run just anywhere...but that's already possible
 with gc.disable() and gc.enable().  Also, remember that the GC *only runs*
 because of a new operator...so if you're so worried about performance in an
 area, don't try to allocate memory there!


Darn... Thought I'd read everything about D carefully enough.  I missed 
gc.enable() and gc.dissable().


 I disagree:
 That GC is fundamentally flawed.  By the "speed freak" argument we all
 should abandon new and malloc as well.  Heck, let's go back to assembly and
 write our heaps by hand, if that's the kind of speed you want.
 
 The GC can be turned off.  If you don't want it, don't use it.


Hmmm... Fair enough.


I have to admit that I was having trouble sleeping and though this post 
would generate some interesting discussion (which I think it has).  I 
don't actually expect Walter to delete any features that he's already 
worked hard to add to D.  These are just some features I might have left 
out if I had written D.

I kind of wanted to make the point that D is already VERY feature rich, 
and that it may be leaning a bit on the heavy side.  This discussion 
group generates new feature requests at least daily.  I hope this adds a 
bit of a counter-blance to all the feature requests.

Bill Cox
Jan 27 2003
parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Bill Cox wrote:


 I kind of wanted to make the point that D is already VERY feature rich,
 and that it may be leaning a bit on the heavy side.  This discussion
 group generates new feature requests at least daily.  I hope this adds a
 bit of a counter-blance to all the feature requests.


A very worthwhile goal.  Welcome to the group!

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Jan 27 2003