• Advertisement

Archived

This topic is now archived and is closed to further replies.

Poll: What would you add to C++?

This topic is 5392 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

Advertisement
- "proper" Interfaces (probably COM-style, but without the #define hacks)
- support for template variable/function names based on types (things like T $TArray_[4] which would expand to int intArray_[4])
- partial function specialisation

Share this post


Link to post
Share on other sites
Actually, this is an addition to the editor:

Auto-listing of available enumerated types when typing function parameters. (I don't have VS 7.0, is that in there yet?)

[edited by - Waverider on January 22, 2003 10:38:35 AM]

Share this post


Link to post
Share on other sites
quote:
i''d learn it properly before making any suggestions


I do not think that it would be possible to introduce automatic learning into a programming language. *scratches head* Do you have any other features that you would like to see in C++?

quote:
- "proper" Interfaces (probably COM-style, but without the #define hacks)
- support for template variable/function names based on types (things like T $TArray_[4] which would expand to int intArray_[4])
- partial function specialisation


They all sound interesting, but I am not sure I understand some of them. What do you mean by proper interfaces and partial function specialization? What situations have you come across in which these features would be useful? Could you provide a few bits of psuedo-code to illustrate how you would like to see them defined?

quote:
Auto-listing of available enumerated types when typing function parameters. (I don''t have VS 7.0, is that in there yet?)


I like that idea. I have often wondered, though, whether there might not be a better way of handling what enumerations do... Oh, well, more to speculate upon...

Share this post


Link to post
Share on other sites
Are we talking about Standard C++? or Microsoft''s Integrated Development Environment? or both? or neither?

Share this post


Link to post
Share on other sites
Fix everything at http://anubis.dkuug.dk/jtc1/sc22/wg21/

My personal irritants
- non standardized compiler name mangling
- remove C compatibility (this would solve a huge set of problems)

Share this post


Link to post
Share on other sites
quote:
Original post by Prototype
The ''with'' keyword.
It''s a shame it isn''t there.

No it isn''t. It monkeys around with scope in a manner which can cause problems. Imagine this hypothetical code:


  
struct student
{
int age;
string first_name;
string second_name;
};

int main()
{
student s;
with s
{
age = 18;
first_name = "Sabre";
second_name = "Man";
}
}


This is all fine and dandy, and quite appealing to those who are concerned with programming in the small who don''t think about large-scale implications. However, when you make changes to the student struct, you introduce the possibility of shadowing something from an outer scope in a way which causes subtle bugs. What was a reference to a variable in an outer scope suddenly becomes a reference to something in the scope of s. Oops!

Share this post


Link to post
Share on other sites
quote:
Original post by null_pointer
What features would you add to the C++ programming language?

Sanity. But, knowing that''s a bit far-fetched, perhaps these would make C++ a bit more comfortable...

- multimethods;
- type inference (it won''t happen);
- classes and functions as first-class types;
- ability to yield a symbol given a string;
- default initialisation of PODs is zero-initialisation;
- defined order of evaluation between sequence-points.

Share this post


Link to post
Share on other sites
Ok, you got a point.
But I''ve used Delphi for a lot of years and never encountered problems like that. I just hate to type out full object paths when setting properties.

Anyway, it probably has been considered when the language was designed.

Share this post


Link to post
Share on other sites
A more intelligent compilation model - eliminate the need for such stupid things as header files and forward declarations.



"The fact that a believer is happier than a skeptic is no more to the point than the fact that a drunken man is happier than a sober one." -- George Bernhard Shaw

Share this post


Link to post
Share on other sites
quote:
Are we talking about Standard C++? or Microsoft's Integrated Development Environment? or both? or neither?


Standard C++. Comments regarding code editors are also welcome.

quote:
Fix everything at http://anubis.dkuug.dk/jtc1/sc22/wg21/


Thanks for the link. I was looking for more of a hypothetical response, viz. what would you like to see in a modern C++-like language?

quote:
My personal irritants
- non standardized compiler name mangling
- remove C compatibility (this would solve a huge set of problems)


By name-mangling are you referring to the larger subject of the C++ ABI (or the lack thereof)?

Also, could you list some examples of things that would be better if C compatibility were not an issue?

quote:
This is all fine and dandy, and quite appealing to those who are concerned with programming in the small who don't think about large-scale implications. However, when you make changes to the student struct, you introduce the possibility of shadowing something from an outer scope in a way which causes subtle bugs. What was a reference to a variable in an outer scope suddenly becomes a reference to something in the scope of s. Oops!


So similar problems would result from "using namespace"?

quote:
A more intelligent compilation model - eliminate the need for such stupid things as header files and forward declarations.


Amen! Oops, forgot you are an atheist.

I was wondering, though, would it be going too far to allow things to be used without having been defined or declared first as long as they appear in the same source file? In other words this would work under the hypothetical new rules:


    
class x
{
public:
x (y);
};
 
typedef int y;


EDIT: Missed SabreMan's second post.

[edited by - null_pointer on January 22, 2003 12:55:30 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by SabreMan
What was a reference to a variable in an outer scope suddenly becomes a reference to something in the scope of s. Oops!


that''s a good point.. but couldnt they (hypothetically since
we''re ''inventing'' new features here..) just use the scope
resolution operator (or an entirely new operator for that matter)
ie)


struct pseudostruct
{
int i, j, k;
};
void PseudoCode()
{
pseudostruct s;
int i = 20;

with(s)
{
::i = i; // s.i = i
::j = i; // s.j = i
::k = ::i; // s.k = s.i
}

}


makes code a bit more readable, no? i''m not sure of the
underlying mechanics behind the scope resolution operator,
and i''m not as skilled as sabreman, but visually it makes
sense to me
if its not a plausible idea let me know.


-eldee
;another space monkey;
[ Forced Evolution Studios ]


::evolve::

Do NOT let Dr. Mario touch your genitals. He is not a real doctor!

Share this post


Link to post
Share on other sites
quote:
Sanity. But, knowing that''s a bit far-fetched, perhaps these would make C++ a bit more comfortable...


Could you please refrain from making comments like that even if there is a lot of room for improvment?

quote:
- multimethods;
- type inference (it won''t happen);
- classes and functions as first-class types;
- ability to yield a symbol given a string;
...
- defined order of evaluation between sequence-points.


Eh? Mind explaining any of this to a small-town hick?

quote:
- default initialisation of PODs is zero-initialisation;


Now that I understand.

The implementation ought to be able to forgo zero-initialization as an optimization instead of forcing the programmer to make the decision all throughout the program.

Share this post


Link to post
Share on other sites
Just off the top of my head: maybe reduction in code redundency

We have to declare things various time in the header and the cpp file for example:

in the .h
class Foo
{
static int * myStaticVariable;
}


//in the .cpp
int * Foo::myStaticVariable =0;

So when we make a change to .h file we must change the cpp file as well. Additionally this applies to method declarations as well. I often find it a hassle to change the method declaration in the .h and then having to match it in the .cpp. Ofcouse we would need an alternitive way to uniquely match the method declartion in the header with their actual methods in the cpp (maybe a simpified declaration of the method in the cpp that would still match one-to-one with the declaration in the header, but with out the redunancy)


Ofcouse it might be best to solve this with a development tools that would alter the corresponding method declaration. In Game Programming Gems 3 there is an article that uses macros to declare functions so when you make a change to the method it will update both header and cpp delcarations (but i dont agree witht this solution because dealing with so many macros can be combersome).

Share this post


Link to post
Share on other sites
Multilevel breaks

i.e break 2

for stuff like

    

for(int x = 0; x < foo; x++)
{
for(int y = 0; y < bar; y++)
{
if(something == pleh)
break 2; //Break out of both loops

}
}



Not a C++ problem, but a MSVC problem is that I would like to see this fixed


  
The way it is now:
for(int x = 0; x < foo; x++)
{
//Stuff

}

for(x = 0; x < bar; x++)
{
//Other stuff

}

The way it should be:

for(int x = 0; x < foo; x++)
{
//Stuff

}

for(int x = 0; x < bar; x++)
{
//Other stuff

}



Anyone know if this was fixed in VC.net?

[edited by - terminate on January 22, 2003 1:58:33 PM]

Share this post


Link to post
Share on other sites
This would probably be suited for a whole new programming language (as well as 10-20 years from now) but I''ll say it anyway. I want to see some Real Mutilthreading. (RMT I shall call it.) Basically, if you know how Windows works, it has it''s little nice multithreading system which allocates time splices to all the processes that run on your computer. However, this isn''t real, it''s virtual. (right?) Each process is getting a millisecond to preform it''s action, and then the processor is handed over to the next process for a millisecond and the loop is created amongst all the processes.

Well, it would require some new hardware (dual or triple processors, or new types of processors which deal with RMT) but I think it would make for some very interesting possibilities to have RMT a reality. Just think, it''ll take us one step closer to human compariable AI. You don''t think our brains work on a time slice do you? We preform millions of decisions (as minute as you can imagine) all at the exact same time. (no delay, not even a millisecond)

Anyway, I was just thinking that this extention to C++ (or new language) would just have multiple simutanious-source files. For example... rmt will be our file extension...

main.rmt0 + main.rmt1 + main.rmt2 = 3 Level Real Multithreading Program

What do you guys think? Good idea or bad? And why of course!

Share this post


Link to post
Share on other sites
quote:
Original post by terminate
Multilevel breaks

You have it - it''s called goto.



"The fact that a believer is happier than a skeptic is no more to the point than the fact that a drunken man is happier than a sober one." -- George Bernhard Shaw

Share this post


Link to post
Share on other sites
quote:
Original post by SabreMan
Sanity. But, knowing that's a bit far-fetched, perhaps these would make C++ a bit more comfortable...

- multimethods;
- type inference (it won't happen);
- classes and functions as first-class types;
- ability to yield a symbol given a string;
- default initialisation of PODs is zero-initialisation;
- defined order of evaluation between sequence-points.



I'm curious as to what you mean by multimethods. Could you expand on that?

Class and functions as first-class types is definitely one of the features I really wished C++ had. Unfortunately it's very unlikely to happen, as it seems to me it's somewhat depended on some sort of type inference (with regards to number/types of parameters, as that would most likely need to be determined at run-time).

As for zero-initialization of PODs I'll have to disagree (but only very slightly). I'm generally supportive of C++'s "don't pay for what you don't use" policy, and although the extra cost for zero-initialization is very slight (hence my only very slight disagreement), I still feel that decision should rest in the hands of the programmer.

By "ability to yield a symbol given a string" I assume you mean something along the lines of Java's classloader, but expanded to include not only classes but all symbols? In my experience, while that kind of feature is extremely useful in *some* cases, it is very rarely so, and the amount of effort needed to implement it properly makes it extremely unlikely ever to be included.

Defined order of evaluation... What can I say? It's pretty much a travesty that this hasn't been standardized years ago.

Personally I'd like the possibility of defining private class-methods and members outside the tradional class-definition. This would make the header-files much cleaner as the entire class-implementation (including private methods and such) can be defined in the implementation-file rather than in the definition (being private they only need to be called from within that compilation-unit, or from 'friends' (friends would need to be handled in some fashion though)), making the header-file basically the declaration of that class's interface.

I feel C++'s handling of enumerations is somewhat undesirable, being not quite an int, and not quite a type in it's own right. IMHO enum's should be proper types, allowing two different enum's to use the same value-names.

Oh, and proper rotation operators would be nice.

-Neophyte


Edit: Gah. Screwed up the quoting.

[edited by - Neophyte on January 22, 2003 1:59:34 PM]

Share this post


Link to post
Share on other sites
- A new typedef keyword that actually defines a new type instead of an alias. Explicit typecasting should be necessary to convert between the types.
- Multithreading support within language.
- The possibility to create typedef templates.
- Add that std::string data must be shared between std::string objects.
- New typeof keyword that would return the type of an expression.
- Automatic virtual destructor for classes that contain virtual member functions.
- More standard libraries. For graphics, RPC, internet and other.
- Remove std::vector<bool> specialization.

EDIT1 added the following:
- The ability to use locally defined classes as template arguments.



Update GameDev.net system time campaign: 'date ddmmHHMMYYYY'

[edited by - dalleboy on January 22, 2003 2:31:08 PM]

Share this post


Link to post
Share on other sites
quote:
of course you''d never have public member variables, would you?


Not unless they were properties.

quote:
Anyone know if this was fixed in VC.net?


Off-topic, but yes it was fixed in VC++.NET. Partially. You must use the conform pragma to force the proper for loop scope rules.

quote:
Multilevel breaks


Hmm...I am not sure if I like that, but it would seem to be useful in certain situations.

quote:
What do you guys think? Good idea or bad? And why of course!


What would it be useful for? Any examples?

quote:
Class and functions as first-class types is definitely one of the features I really wished C++ had. Unfortunately it''s very unlikely to happen, as it seems to me it''s somewhat depended on some sort of type inference (with regards to number/types of parameters, as that would most likely need to be determined at run-time).


What do you mean by type inference?

(Someone ought to write a book on obscure programming language terminology.)

quote:
Oh, and proper rotation operators would be nice.


What do you mean by proper rotation operators?

quote:
Personally I''d like the possibility of defining private class-methods and members outside the tradional class-definition. This would make the header-files much cleaner as the entire class-implementation (including private methods and such) can be defined in the implementation-file rather than in the definition (being private they only need to be called from within that compilation-unit, or from ''friends'' (friends would need to be handled in some fashion though)), making the header-file basically the declaration of that class''s interface.


I was thinking that this would be better handled by eliminating header files altogether and forcing the compiler to do its own dirty work, but what would become of libraries that only distribute header files? I suppose this could be resolved by creating a good, standard ABI that handled these things for us.

quote:
- A new typedef keyword that actually defines a new type instead of an alias. Explicit typecasting should be necessary to convert between the types.


Definitely!

quote:
- Multithreading support within language.


I created a thread about this not too long ago, but it did not generate much attention. I received one reply suggesting that I buy a book on the subject.

quote:
- The possibility to create typedef templates.


I believe Stroustrop said that would be in the next version of the standard.

quote:
- Add that std::string data must be shared between std::string objects.


How and why?

quote:
- New typeof keyword that would return the type of an expression.


I though that we already had a typeid keyword that returns a typeinfo object describing the type of an expression. Perhaps you would like to see the typeinfo class extended?

quote:
- Automatic virtual destructor for classes that contain virtual member functions.


Hmm...I do not agree with this one. Programmers might become too dependent on this auto-virtualization of destructors and forget that sometimes concrete classes are inherited from. My idea would be to make all destructors implicitly virtual and have the implementation decide to throw out virtual destructors as a performance optimization.

quote:
- More standard libraries. For graphics, RPC, internet and other.


I would certainly like to see this, but I am not sure that it is feasible. It already takes a lot of time to work on the language standard, and creating standard libraries for all of these things would require a lot more volunteer effort.

quote:
- Remove std::vector specialization.


Hurray!

quote:
- The ability to use locally defined classes as template arguments.


I do not understand why it was disallowed anyway. Perhaps to make things easier for the implementers?

Share this post


Link to post
Share on other sites

  • Advertisement