|
Re: Why? Language Archaeology ... and Metaprogramming
|
Posted: Jun 29, 2009 7:45 AM
|
|
> > > > C++ does not have flaws because of compatibility > with > > > C. > > > > C++ has flaws because it was not thought out well. > > > > > > This is precisely what I'm arguing against. If you > had > > > been there as I was, you would have seen very smart > > people > > > excruciatingly going over each decision, discovering > > all > > > the problems before adding features. It was thought > out > > > *extremely* well, and the reason the language is > > difficult > > > is precisely because of C compatibility. > > > > > > Oh. Wait. You're trolling, aren't you. You got me. > Good > > > for you. > > > > No, I am not trolling at all. Having worked with C++ > for > > the last 11 years, and having used every feature of the > > language, I know that there are alternatives that could > > have been chosen that could have made the language much > > better. > > > > Some examples: > > > > 1) the distinction between classes and non-classes > types. > > All types could have been classes, even primitives. > > you are referencing another language's paradigm: > types=classes=primatives is just not the paradigm used in > C++ -- deal with it!
Why primitives not be classes? ask yourself. Wouldn't it be beautiful if all types where classes?
> > > > > > 2) uninitialized variables. Variables should always > have > > been initialized to their default value. If there was a > > performance issue, then the programmer should have a > > keyword in his disposal telling the compiler to > allocate > > memory for the variable but not initialize it. > > again, just not the way it's done in C/C++ for whatever > reason, so what? languages shouldn't be designed around a > software engineer's laziness or ignorance of the > programming language. you should know a little bit more > about what goes on "under the hood" when you code in any > programming language, and not just C/C++. For example, in > Java and the .Net languages, do you know how the virtual > machines handle deallocation of memory, their threading > model, etc; do you think you should?
Have you worked with large teams of programmers in very large programs? it's very easy to forget to initialize a variable, especially in large projects. Programming languages are supposed to help.
There is nothing wrong with automatic initialization. The compiler should have a keyword to disable automatic initialization, but the default should have been to automatically initialize a variable.
> > > > > > > 3) default values for parameters only at the end of the > > parameter list. A function could have default values in > > any of its parameters, not only in the parameters of > the > > left side of the parameter list. > > the use of default parameters is a convenience to the > programming language; and i am sure it presents some > headaches to compilers and interpreters.
No, there is no headache involved.
> > > > 4) lack of pass-by-name parameters. Why C++ doesn't > have > > it? there is nothing that has to do with C > combatibility. > > > pass-by-name? C/C++ have function pointers which can be a > very powerful tool in one's software engineering toolbag.
Function pointers are not a substitute for pass-by-name variables. They are unrelated things.
> > > > > > 5) the choice of angle brackets for template > parameters. > > This was a mistake that made the grammar a lot more > > ambiguous than what it was. > > aren't we being a little picky here when it comes to > symbology and language syntax friend? there is only one > or two gotchas when it comes to template programming that > i am aware of... and for the most part you don't need to > use templates, if you don't wish to...
Stroustrup himself said so. The presence of angle brackets makes the language grammar ambiguous, and this makes things like intellisense or refactoring very difficult to create.
> > > > > 6) the choice of syntax '= 0' for abstract methods, > > because of fear of introducing another keyword. Nothing > to > > do with compatibility with C. > > that's just an easy way to identify the difference between > pure virtual and virtual... most students easily > understand the concept and easily recognize its use. the > other's end up taking business courses or something less > challenging. i never saw that as a flaw or a shortcoming > in the language.
It's not very important, I agree. It was just an example of something not being affected by C compatibility.
> > > > > > > > 7) lack of anonymous functions. They could be very > simple, > > i.e. not be closures, not capture the environment. They > > could be localized parametrized pieces of code that > refer > > to hardcoded addresses (so there is no need for the > extra > > data pointer). Again, nothing to do with C > compatibility. > > this is more of a convenience in other languages, and I > never see the need when i code in C or C++.
Lambda functions is the greatest tool for reducing code bloat.
> > > > 8) lack of tail call optimization. Again, nothing to do > > with C compatibility. > > really not needed for most applications; choose the > language that best suits your needs... maybe python is > more applicable?
Tail call optimization is not something I need every day, but it would be nice to have. Again, it's something that C compatibility does not affect.
> > > > > > > 9) lack of compile-time introspection of classes > > properties (class names, class members, class member > > types, class member names, etc). Again, nothing to do > with > > C, but it would greatly simplify a lot of code. > > IMHO, introspection violates the core principals of OO > programming encapsulation, polymorphism, inheritance, > etc... objects don't need to know type/RTTI > information... properties violate encapsulation and data > hiding...there shouldn't be a need to access attributes > directly... if so, why not write your code in C or some > other procedural language?
There is a great need for introspection. Many algorithms are simplified using introspection; for example, a generic object-based I/O framework.
It's very tedious to have to manually program those things that the compiler can easily provide.
> > > > > > > 10) initializer lists. They could have been part of the > > constructor code. > > why? is it necessary or just a convenience? should > "convenience" functionality be included in any language? > or is that what user defined libraries are for?
Most classes have more than one constructor. Initializing code has then to be repeated for each constructor. This creates a major problem when refactoring code.
> > > > > 11) lack of static initialization of class members as a > > separate function. The same code must be repeated over > and > > over in each constructor. > > have to explain this one in more detail, provide an > example.
class Foo { int x;
//implicitly called before constructors init() { x = 0; } }
> > > > > > 12) uniform construction syntax. Again, nothing to do > with > > C. C(a) and C = a should have been equal. C++0x solves > > this with C{}. > > object creation and assignment are different.
Yes, indeed. C a = b is construction, not assignment.
|
|