auto variable declarations1, and anonymous functions. I don't care so much about proper lambdas, I just want to use for_each without jumping through hoops. And yes, for any non-trivial cases boost::lambda is jumping through hoops.
That's really it. I suspect that neither of those would be terribly useful in C, and I don't know enough C# to comment.
AllTheLuck: (1) through (4) go a long way towards making C into C++, which I'm sure we can all agree is not a good idea. (5) is not a language feature, whatever Java and C# would have you believe. (6) is completely retarded, and (7) is half-way provided already [no floating point types, and no 128-bit integer support out of the box].
CM
1 *edit: Just so there is no confusion, I'm refering to real, strong type declarations that the compiler implies on its own, not some sort of variant type like those found in VB and a few other languages.
Things you could modify about C/C++/C#
Quote:Original post by AllTheLuck
6. Standard Graphics API based on OpenGL
I've heard of this. You can get it as a library for C or C++, as well as a few other languages. It's really quite popular, you should check it out. I froget the exact name though... OpenLG? GLOpen? GOpenL?
My list is along the linse of:
1) Templated typedefs.
2) auto (same one as Conner McCloud)
3) Multiple Dispatch.
Much more than that and you're looking at a new language. Which is not something I'm opposed to I might add, it's just that such a system would be better built without the C/C++ heritage of mistakes.
Just a heads up... C# will get "auto" variables, better known as "implicit types" as well as lamda functions and a few more fancy bits see the C# 3.0 working spec
Quote:Original post by Azh321
I dont see much purpose in nameless functions or coroutines. I will probaly do variants though, cmon guys tell me what you really like about C# that you wish C++ had, tell me what you wish C++ had/didnt have!
Properties(get/set) that doesn't interfer with functions
a for_each clasue
dot for accesing classes/variables/names in the namespace
New stuff:
syntax, easy enough so it is easy to convert existing C/C++ code to the new one. perhaps providing a converter ;)
the function returning for than one value
the abiliy to define other operators than the standard operators
sending the compiler a file that tells how to handle the text-input(essential a lexer). Could be a simple as banning different names in different contexts(like a class must have a large letter and no underscore, and constants should be written with only large letters), or as complex and let the user define what an if looks like(perhaps If or something in there language - to help newbies?).
preprocessor type checking, like
/*The main difference between a stament and a value is thatthe value can be assigned, the statement can not*/// statement is a executing statement, like print("") or perhaps i = 2macro: statement myMacro(bool val, statement a, statement b) { if( val ) { val = false; return a; } else { return b; }}// now the statement represents a float, like 5.0f+2.0f, or sqrt(9.0f)macro: statement<float> myMacro(bool val, statement<float> a, statement<float> b) { if( val ) { return a; } else { return b; }}// useless function, but you get the point ;)void useMacro(bool val, float& of) { macro:myMacro( val, print("hello"), of=2.0f ); of += macro:myMacro( val, sqtr(of), log(of) );}This may be related to hygienic macros. I understood nada of those scheme-pages that I got from google.
Tuples. Not as a data type, but as a form of expression. For example
Anonymous functions just like those in Lua would be a huge improvement to any language.
ISO C99-style structure initialisers.
No more need for forward declarations. Members of a class can be used before they are defined, so why not extend this to an entire file?
Be able to declare inheritance when declaring classes (not just when defining them). For example
Ability to make members of a class private, but visible publicly as const.
float, float GetXY() // tuple return type{ return 4.0, 7.3;}int main(){ float x, y; x, y = GetXY(); // tuple assignment return 0;}Anonymous functions just like those in Lua would be a huge improvement to any language.
ISO C99-style structure initialisers.
No more need for forward declarations. Members of a class can be used before they are defined, so why not extend this to an entire file?
Be able to declare inheritance when declaring classes (not just when defining them). For example
class class1 {public: class1(){} float a;};class class2 {public: class2(){} float b;};class class 3: public class1, public class2; // class3 is defined elsewhereAbility to make members of a class private, but visible publicly as const.
class MyClass{public: MyClass();private public const: float a;};
Hello,
I have a couple of remarks about what has already been said.
That's a clever way to break one of the most important OOP design principle - the "open Closed Principle". As a consequence, it also provide a cool way to break the "Liskov Substitution Principle". Code like this should not exist because it cannot be extended without modification. The correct way to implement this is to create a virtual function in the base class and to override this function definition in ClassA and ClassB. Thus, I think that adding this functionnality to the language is not really a good idea.
One thing I'd find cool in a C++ compiler is type-safe enumerations. I'm not sure about that auto keyword - in fact, I fear badly writtent code that will use auto everywhere - thus making the code barely readable (no, you don't have to know what is the type of this variable. It is auto).
I can't see how you can implement this. there is no real advantages in
You can already write this in C++
Not to mention that the calling code would be weird :)
Thirded. An interface or a code construction to create properties would be a nice thing, as well as a mecanism to enumerate these properties at run time.
Another possible area of improvement is definitely the libraries that would come with such language.
Default (2/3/4)D matrix, (2/3/4)D vector types would also be nice (the code generated by the compiler would take advantage of this).
Regards,
I have a couple of remarks about what has already been said.
Quote:Original post by Nypyren
I would add a feature to let you reduce this:
(snip stuff about synamic_cast<> and dynamicswitch)
Sure, there are invasive ways to add this to existing classes so that you can switch on a member variable defined in the base class, but why waste space when you probably have a vtable pointer anyway?
That's a clever way to break one of the most important OOP design principle - the "open Closed Principle". As a consequence, it also provide a cool way to break the "Liskov Substitution Principle". Code like this should not exist because it cannot be extended without modification. The correct way to implement this is to create a virtual function in the base class and to override this function definition in ClassA and ClassB. Thus, I think that adding this functionnality to the language is not really a good idea.
One thing I'd find cool in a C++ compiler is type-safe enumerations. I'm not sure about that auto keyword - in fact, I fear badly writtent code that will use auto everywhere - thus making the code barely readable (no, you don't have to know what is the type of this variable. It is auto).
Quote:Original post by sirGustav
the function returning for than one value
I can't see how you can implement this. there is no real advantages in
return (x, y);You can already write this in C++
return point(x, y);Not to mention that the calling code would be weird :)
Quote:Original post by Saruman
Definately a nice native interface for properties in C++ as said above.
Thirded. An interface or a code construction to create properties would be a nice thing, as well as a mecanism to enumerate these properties at run time.
Another possible area of improvement is definitely the libraries that would come with such language.
Default (2/3/4)D matrix, (2/3/4)D vector types would also be nice (the code generated by the compiler would take advantage of this).
Regards,
>float, float GetXY() // tuple return type
pair<float,float> getXY()
>inner functions
Is possible, however with a little trickery (put
the function inside a union)
>6. Standard Graphics API based on OpenGL
For this, you have api's - that's definately sth which does
NOT belong in the language, just like audio, moviedisplay and
(de)compression of mp3's aren't part of the language.
Some additional "base" libraries - not as a part of the language! -
(like eg the stl) for matrices, compression/decompression and other
areas would be interesting (as long as it's standardized)
>Sure, there are invasive ways to add this to existing classes so that you can
>switch on a member variable defined in the base class, but why waste space
>when you probably have a vtable pointer anyway?
I agree with Emmanuel Deloget :)
Support for sth like "enum_as_string" would be nice though :)
[Edited by - Kitt3n on November 11, 2005 7:59:59 AM]
pair<float,float> getXY()
>inner functions
Is possible, however with a little trickery (put
the function inside a union)
>6. Standard Graphics API based on OpenGL
For this, you have api's - that's definately sth which does
NOT belong in the language, just like audio, moviedisplay and
(de)compression of mp3's aren't part of the language.
Some additional "base" libraries - not as a part of the language! -
(like eg the stl) for matrices, compression/decompression and other
areas would be interesting (as long as it's standardized)
>Sure, there are invasive ways to add this to existing classes so that you can
>switch on a member variable defined in the base class, but why waste space
>when you probably have a vtable pointer anyway?
I agree with Emmanuel Deloget :)
Support for sth like "enum_as_string" would be nice though :)
[Edited by - Kitt3n on November 11, 2005 7:59:59 AM]
I think that I should better explain what I meant earlier by a standard graphics API based on OpenGL. What I mean is to include a small subset of OpenGL into standard C so that on any device those libraries can be expected.
In some embedded systems it would be a waste to have this extra functionality, but for most systems it would be very nice. Graphical User Interfaces could be defined based on the small set of drawing functions as well as 3D applications. This would be very nice from a portability standpoint.
The reason that I would actually like it to be part of the language standard so that people would feel obligated to use it or that it would be the obvious choice.
I hope that this makes it more clear.
In some embedded systems it would be a waste to have this extra functionality, but for most systems it would be very nice. Graphical User Interfaces could be defined based on the small set of drawing functions as well as 3D applications. This would be very nice from a portability standpoint.
The reason that I would actually like it to be part of the language standard so that people would feel obligated to use it or that it would be the obvious choice.
I hope that this makes it more clear.
Quote:Original post by AllTheLuck
I think that I should better explain what I meant earlier by a standard graphics API based on OpenGL. What I mean is to include a small subset of OpenGL into standard C so that on any device those libraries can be expected.
In some embedded systems it would be a waste to have this extra functionality, but for most systems it would be very nice. Graphical User Interfaces could be defined based on the small set of drawing functions as well as 3D applications. This would be very nice from a portability standpoint.
The reason that I would actually like it to be part of the language standard so that people would feel obligated to use it or that it would be the obvious choice.
I hope that this makes it more clear.
It was perfectly clear before. Just completely retarded. Why should the language dictate what features the environment has? Why should people feel compelled to use OpenGL? What use does a low level language like C have for a high level construct like a graphical library? Why should a rapidly evolving field like graphic libraries be stripped down and locked into a single static version for the rest of time? And so forth.
CM
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
