|
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
|
|
|
|
|
I would say Bjarne is wrong, He invented C++, thats cool but that does notmean that he would expect developers to design software or use C++ in such a way that he would like it.
If the program compiles with C++ compiler, the program works, but if the program crashes or gives wrong output, thats another matter.
-prakash
|
|
|
|
|
There are plenty of ways of writing correct programs in any programming language but this does not mean that all ways are equally recommended. Good programmers generally follow the recommemded idioms of whatever language they are using unless there are special reasons for departing from them. This is especially so when writing code that must be maintained by others. In my experience most actual C++ is pretty awful, not necessarily because of C++, but because most programmers are mediocre and then the complexity of C++ makes matters worse than they would be in a less complex language
Kevin
|
|
|
|
|
Xp3ll3d wrote:
Well i love C++'s ability to do anything. but i absolutely hate the way it handles pointers.
How so?
|
|
|
|
|
PaulMdx wrote:
Well i love C++'s ability to do anything. but i absolutely hate the way it handles pointers.
How so?
Curious about that myself. As an old time ASM programmer pointers were basically the same as in C or C++ with minor exceptions. I much prefer to access ALL data thru pointers but that is just my way of doing things and not to be taken as Gospel but I am curious as to how any pointer usage could be more robust or simple than that used in C or C++.
Richard
"Under certain circumstances, profanity provides a relief denied even to prayer
--Mark Twain (1835 - 1910)
|
|
|
|
|
Richard Stringer wrote:
I much prefer to access ALL data thru pointers but that is just my way of doing things and not to be taken as Gospel
This is fine if you're doing C but not recommended if you're doing C++. See Stroustrup's many comments on this issue.
Kevin
|
|
|
|
|
What is the Set feature in Pascal...?
--
Weiter, weiter, ins verderben.
Wir müssen leben bis wir sterben.
I blog too now[^]
|
|
|
|
|
A set is a collection that doesn't allow duplicate entries.
There's at least one CP Article[^] available on creating sets support in C#.
Grim (aka Toby) MCDBA, MCSD, MCP+SB
SELECT * FROM user WHERE clue IS NOT NULL
GO
(0 row(s) affected)
|
|
|
|
|
 I think Jörgen knows about sets, given the fact he holds a MSCS degree. The question was IMHO, why Pascal sets in particular?
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
That's something that should reside in a (standard) library rather than the language itself IMO.
A feature should only be included in the language if and only if it is required in some way. I am not a Pascal wiz, but I don't see anything in the Pascal language that requires a set. Or in any other imperative language for that matter.
--
Weiter, weiter, ins verderben.
Wir müssen leben bis wir sterben.
I blog too now[^]
|
|
|
|
|
I agree the concept, but I feel the cause and the effect had been reversed.
Pascal was definied to be "strongly typed". In it, operation like AND or OR were for BOOL only. A group of flag was mandatory to be at least an array of bool, and that was SET, as firstly implelemted: given an enumeral, a set of myenumeral was a bit array with each bit indicating the presence of a value in the set.
Further pressions from many programmers causes Pascal to "degenerate" into more efficient C-like operation on bits and integers. Thus & and | where also for int, like in C.
At thet point, set looses the most of its attractive, expecially between windows programmers, also considering the the most of the windows API makes uses of integer manifest constants (not enums or bit fields) to define flags.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
