|
Don Clugston wrote:
late-1980's C++ templates.
Actually the first C++ compiler to support templates was Cfront 3.0, released in 1991. 
As for generics, I like the way they solve source code organization problem, but in general I agree with you 
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Don Clugston wrote:
Not impressed by .NET generics, [..] they are less powerful than late-1980's C++ templates.
IMO a wise decision.
I've long upheld that the STL is a good library, but a bad standard library. It is too complex, and compiler support to archaic, a "programming engineer" will barely go beyond the "std::vector for arrays" level, and as array class, std::vector is a pain.
Templates rock. You can do crazy sh*t with them.
What would happen if you could write something like lokis policy based smart pointer in C#?
Of course everybody would start to contribute cool template magic, and soon fundamental C# libraries would be ununderstandable for the "programming engineer" mentioned above. C# shines at making programming simpler, C++ - style templates could kill that in an instant.
we are here to help each other get through this thing, whatever it is Vonnegut jr.
boost your code || Fold With Us! || sighist | doxygen
|
|
|
|
|
> Templates rock. You can do crazy sh*t with them.
Oh yeah!! I've not had so much fun since the days of the Z80. I'm hanging out for typedefs with partial template specialisation.
> C# shines at making programming simpler, C++ - style templates could kill that in an instant.
I'm looking forward to watching the impending war between C# and Herb Sutter's C++/CLI for control of .NET. If he's even partly successful in making C++ the preferred language for .NET, so that C# has to be compatible with C++, rather than vice versa, things could get very interesting.
I'll be watching from a distance 
|
|
|
|
|
I agree that generic programming is important, but I believe that templates are a poor attemt at it.
If you look at the boost library (or the likes of it), its obvious that templates are more of a language opening for any kind of extension (almost like lamba calculus) at often horrendous syntax (no crititisism to the writers of boost etc. C++ just doesn't allow for more).
As such templates are much more evil than macros. You can really mess up the language. Templates are definitly the dark side of the power (which doesn´t mean they can´t be fun).
But as for generics, I´d prefer the subtype polymorphism as presented in several modern database languages (you specify your minimal type reqirement in a type-hierarchy and you get _one_ function that works on all compatible types.
Wolfgang Reichl
|
|
|
|
|
WoR wrote:
As such templates are much more evil than macros.
Donno man... i've seen some pretty evil macros. 
"The time has come," the Walrus said,
"To talk of many things..."
|
|
|
|
|
const is one of the most useful keywords.
It helps you alot finding bugs at compliation time.
It also states what is the scope of a variable.
It's a shame that C# and the other .NET languages don't support it.
Ami
|
|
|
|
|
private const int RB_SCALETYPE = 0;
Is this not the C# const we are talking about?
<signature>
It's good to live,
Josef Wainz
Software Developer
|
|
|
|
|
|
|
There are no methods in C++, they are called member functions.
|
|
|
|
|
Meaning the parameter is immutable?
<signature>
It's good to live,
Josef Wainz
Software Developer
|
|
|
|
|
Const was deliberately left out [I have had a good number of discussions with internal MS developer on this topic]!
The rational is that you really need to carry the info with each reference, otherwise there are loopholes. This would increase the size of each reference significantly (25% to 100%) and result in significantly larger memory footprints.
There are a number of design patterns and strategies which can achieve the same level of safety, but are not as syntatically convenient. For those of us who want references to mutable objects where modification is blocked for that specific reference, then this is the best we can to for noew and the forseeable future.....
david@dynamicconcepts.us
|
|
|
|
|
Set support (as in Pascal) - nice to have, but not a big deal.
The goto statement - a must-have. Unconditional jump is a fundamental thing in computing
PERL's tuple returning (($a, $b, $c) = $function()) - nice, but it can be in a library as well. See The Boost Tuple Library[^]
Operator overloading - very important, especially for numerics.
Optional parameters - nice to have, but not a big deal if function overloading is supported
Garbage collection - if optional and per-object, very good. If mandatory and/or per type, very bad.
Attribution / Reflection - Personaly I don't like it at all, but I may be biased. I just love static type system, and this is too "dynamic" for my taste.
Exception handling - very important.
Templates / Generics - a must!!! (except for dynamic languages of course). Casting down every single time one uses a collection is totally unacceptable.
Other features I would like in an "ideal" language:
-multiple inheritance, or some other mechanism for mix-ins
-deterministic finalization and support for RAII
-value semantics (including creating objects on stack)
-not too expressive syntax (Pascal-like, rather than C-like)
-built-in support for modules/components (I really miss it in C++)
-support for multiple paradigms (free methods, aspects, generics...)
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Nemanja Trifunovic wrote:
-multiple inheritance, or some other mechanism for mix-ins
-deterministic finalization and support for RAII
Two must haves.
|
|
|
|
|
The scale should be something like +5 to -5. The respondents could then show the importance of some features and also indicate features that should be excluded from languages. So templates could be a +5, and garbage collection could be a -5.
|
|
|
|
|
GC -5 ?!?!? Why?
templates +5?!?!? Why?
-prakash
|
|
|
|
|
I guess it is the nature of the type of development work that I do. Which is mostly embedded real-time applications.
Any language that allows or requires you to randomly spend an unknown amount of time doing something that the developer should have done right in the first place is just plain evil
Templates have allowed me to create a collection of functions that are compiled inline in the code, are type specific, and can be optimized along with the function that they are used in. Most of the platforms I work on I'm limited by performance and not by code space so for me this is a very worth while trade off.
|
|
|
|
|
I think you're being a little too negative here.
In my view, the big problem with gc is not performance, but rather the way it mucks up RAII.
I've got no problem with gc, as long as it is optional.
If anyone tries to make gc compulsary, then I'm with you 100%.
Bear in mind that in C++, you can always use the Hans-Boehm garbage collector if you ever manage to find a legitimate use for gc (which personally I never have, but I'm told on good authority that they do exist).
|
|
|
|
|
Maybe I am being negative, but in my experience even if it is just optional, some nitwit that does not know what they are doing or is just to lazy to write it correctly the first time will use it "just this once" and all bets are off.
Working with an “Expert” a few years ago, we ran into a problem where a piece of his code was causing the system to fail randomly. He argued that his one little harmless routine could not possibly cause a failure like we were having. Yet when we profiled the entire system in a production sitting, his harmless little routine was locking the task dispatcher and then running for 100ms or longer. We had a maximum latency of 10ms on one task. Now when you cause a production system that 1000s of employees are using to crash people have a tendency to get a little upset
There are places where the GC may have its legitimate uses, but you will always have a fierce battle to get me to include it or allow it in any system I'm working on.
|
|
|
|
|
Don Clugston wrote:
I've got no problem with gc, as long as it is optional.
If anyone tries to make gc compulsary, then I'm with you 100%.
Amen. There are good uses of GC (ie. in case of shared ownership of an object), but if you know your object's lifetime in advance, GC is more than unnecessary - it is just bad because it makes management of non-memory resources more complicated.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Raymond Rogers wrote:
garbage collection could be a -5
Agreed. Garbage collection was created by Satan to seduce the ignorant and gullible.
Garbage collectors are inappropriate in any environment where resources are constrained, performance is important, or software correctness must be provable. In other words, any programming environment at all.
Software Zen: delete this;
|
|
|
|
|
Well i love C++'s ability to do anything. but i absolutely hate the way it handles pointers. So when i learnt Java it was a godsend, auto garbage collection!! but i still prefer to do all of my projects in C++ pointers are just something i have to live with ='(
|
|
|
|
|
Java is not godsend. Its an answer to all the bad programmers who dont know how to work with pointers.
-prakash
|
|
|
|
|
Original poster mentioned Java, bt his point was GC.
IMO, GC is a good thing. Bt sometimes poor programmers don't care about resources (We have garbage collection, so what), instead of learning how GC works and how to use it as advantage. Like we say, it's a good friend, bt bad master. Basically, I agree with you, I just want to show the second side.
btw I don't work with Java 
David
Never forget: "Stay kul and happy" (I.A.)
|
|
|
|
|
Mr.Prakash wrote:
Java is not godsend. Its an answer to all the bad programmers who dont know how to work with pointers
The fact of the matter is that even good programmers will make mistakes with memory management. And this is acknowledged by the likes of Bjarne Stroustrup, the inventor of C++, who is constantly criticising C++ developers for faffing around with pointers and low-level techniques in general instead of using the modern abstraction mechanisms of Standard C++.
Kevin
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
