Jump to content
  • Advertisement
Sign in to follow this  
Nemesis2k2

What additions would you like to see to the C++ language

This topic is 4834 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

What features have you come across/thought of that you'd like to see added to the C++ standard at some point? I have two main ones personally: 1. Templated typedefs This one is such an obvious thing that I'm still surprised it doesn't already exist. This is simply the ability to declare an alias for a templated type, as follows: template<class T> typedef std::vector<T> Array<T>; Fortunately this one is on the way apparently. 2. Access specifiers for namespace members In my opinion, it should be possible to apply access specifiers to members of a namespace, in the same way access specifiers can be applied to members of a class. I have come across times where a class is not logically a subclass of another, but it is internal to a system. It would be nice to be able to mark it as such by making it a private member of the namespace. Conceptually, I consider that namespaces should be used to establish boundaries between subsystems, and it makes sence to be able to hide elements from the public interface to that subsystem in the same way we hide elements from the public interface of a class. Anyway, what features would you like to see added to the language, and what comments do you have about any other proposed additions?

Share this post


Link to post
Share on other sites
Advertisement
How about:
get rid of the #include code-pasting model for header files
Double pass compilation
A standard hash table
standard smart pointers

Share this post


Link to post
Share on other sites

  • Native type of string literals is const std::string, not const char*
  • virtual qualifier on class destructors is inferred by the compiler.


I have other ideas, but they would require changing the language (garbage collecting, limitation on the number of methods per class, properties, contexts, etc)

Share this post


Link to post
Share on other sites
Quote:
Original post by ToohrVyk
limitation on the number of methods per class, properties, contexts, etc


But why would you want that?

Share this post


Link to post
Share on other sites
virtual static members...

but I suppose that is a bad Idea, as I can't specifically decide how they would work, I just know sometimes I wish I had them.

Share this post


Link to post
Share on other sites
i'd want things added to the standard library mostly. fairly happy with the language.

a lot of the things i'd want are proposed for c++0x such as networking library and things.

Share this post


Link to post
Share on other sites
Quote:
Original post by sand_man
Quote:
Original post by ToohrVyk
limitation on the number of methods per class, properties, contexts, etc


But why would you want that?


Hmm, that should be parsed as:

limitation on the number of methods per class; properties, contexts, etc

The goal of this would be to reduce complexity of the interface and reduce the risk of having a god-class anti-pattern. Note that I'm talking about publically-available methods on the class, a class can still have any amount of private methods, module-level methods, and read-only properties.

Share this post


Link to post
Share on other sites
Quote:
get rid of the #include code-pasting model for header files

Yeah, I'd very much like to see the concept of a "module" in C++. It could be added while preserving the current header/source file system for backwards compatibility.

Quote:
Double pass compilation

This is probably the key to the above. I don't think you could compile a module-based source tree in a single pass compiler.

Quote:
A standard hash table
standard smart pointers

I agree. I think these two will be coming shortly enough thankfully.

Quote:
Native type of string literals is const std::string, not const char*

I've thought a bit about this too. I think in reality it would be best if the type was inferred from the context. In cases where there isn't type information available, a const char* is assumed. A postfix could be provided to override perhaps.

Quote:
virtual qualifier on class destructors is inferred by the compiler.

That kind of behaviour (ensuring polymorphism never causes derived class destructors to be "missed") could only be done reliably with some form of RTTI as I see it, and I don't think I'd like C++ to require that to be enabled just yet personally.

Share this post


Link to post
Share on other sites
Quote:
Original post by Nemesis2k2
Quote:
get rid of the #include code-pasting model for header files

Yeah, I'd very much like to see the concept of a "module" in C++. It could be added while preserving the current header/source file system for backwards compatibility.

Quote:
Double pass compilation

This is probably the key to the above. I don't think you could compile a module-based source tree in a single pass compiler.


yeah those would be nice too.

Share this post


Link to post
Share on other sites
Quote:
Original post by Nemesis2k2
That kind of behaviour (ensuring polymorphism never causes derived class destructors to be "missed") could only be done reliably with some form of RTTI as I see it, and I don't think I'd like C++ to require that to be enabled just yet personally.


Why not simply do it like we are doing it now (virtual destructors, no RTTI), but without having the user specify a virtual destructor?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!