|
I really like the work you have done with your classes; they are very well thought out and designed. I am just waiting to use it in a real app. Most likely this will be a directdraw high resolution medical image viewing application.
John
|
|
|
|
|
One of the things I really appreciate with some the new languages such as Java, C# and the rest of .Net is the class library docs are much more clear than say, than the old documentation for earlier versions of C++.
|
|
|
|
|
There is great "old documentation" for earlier versions of C++ ... maybe not from Microsoft, but documentation is not really a language issue -- it's the documenter's issue, compiler's issue, or tutorial book's issue.
|
|
|
|
|
|
I think partial specialization intorduced by .NET Framework 2003 is the best feature added to C++ don't you?
|
|
|
|
|
Partial specialization is not a .NET thing or even a Microsoft thing. It was standardized as a part of C++ in 1998 (and introduced by some even earlier). It is a shame it took Microsoft 4+ years to support it.
|
|
|
|
|
Anonymous wrote:
It is a shame it took Microsoft 4+ years to support it.
I agree. And there should have been a service pack to VC6 that adds it.
John
|
|
|
|
|
Sorry!
But I faced that first time in .NET!
I shouldn't have made the mistake.
Anyway thanks for correcting me;)
|
|
|
|
|
I think with C++ I have everything I want from that list.
Even so, C++ is *far* from perfect.
What I would really like is to be able to move even more stuff to compile time.
When I have to use VBA (far too often), the thing that annoys me the most is that it will happily compile code with appalling logical errors. Why anyone thinks VB is an "easy language" is beyond my comprehension.
C++ templates are the best we've got at the moment, but they're still a bit limited and too obscure (and error checking is a real problem).
Not impressed by .NET generics, in some ways (eg absence of specialisation) they are less powerful than late-1980's C++ templates.
|
|
|
|
|
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. ![Wink | ;)](https://codeproject.freetls.fastly.net/script/Forums/Images/smiley_wink.gif)
|
|
|
|
|
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
|
|
|
|