Any information about C++0x...... Dose anyone know what the big difference are going to be? Am I going to have to learn everything over again?
Printable View
Any information about C++0x...... Dose anyone know what the big difference are going to be? Am I going to have to learn everything over again?
For a new standard to be acceptable to the majority of users, it is generally considered better to make sure that the old style code works too - so "learning anew" is not the case. There will be some extensions to the existing language and library, but it's evolution, not revolution.
If you search the forum, you'll find a few references to and discussions about the new standard.
--
Mats
I suggest that you read: The State of the Language: An Interview with Bjarne Stroustrup.
You could also read the Wikipedia article on C++0x, but it probably contains inaccuracies.
I hope they finish it soon, otherwise they might need to call it C++1x :p Strange how the name isn't even Y2K compliant.
Yeah, I heard that too. It will probably become C++0A or so last I heard. And that was from PDC from a Microsoft employee working with Visual Studio.
But fret not, for a lot of C++0x features are beginning to make its way into compilers already.
The C++0A is more of an insider joke than a real idea, I think. But anyway.
The Wikipedia article is OK. There was one gross inaccuracy that I recently fixed, but I believe everything else is in pretty good shape.
The only major habit changing changes are concepts, which adds better type safety to templates, and nullptr.
Everything else is just features.
EDIT: forgot about nullptr.
There are more type-safe enums, as well.
But I think it is unfair only to mention these features, since C++0x will contain a lot more verrrrrrrrrry nice features.
If it was C++0A, it wouldn't make any sense.
It would probably be
C++0x0A
Although my point would be, why not just do
C+=2 or C+++ lol. Seems silly.
Anyway I thought C++ was finished, and D was going to be used in the future?
"0x" is just a notation used in C++ to tell the compiler it is a hex number; nothing more, so C++0A is fine.
And C++ is very much alive and kicking and not going anywhere soon.
Forget D! Stay with the tried and true C++!
I haven't tried it, but isn't it supposed to be a) compiled to machine code, b) do away with the backwards compatibility problems C++ inherited from C, c) let you do your own memory management (though garbage collection is also available). So exactly, what are your arguments against it?Quote:
Forget D! Stay with the tried and true C++!
Mostly unfamiliarity. It was sarcasm, not anti-arguments.
Also, D is too young to be practical yet. No good IDE to my knowledge. Lack of const correctness.
The whole function_name = n syntax is horrible and disgusting.
Perhaps D may become something yet, but as of right now, it is not.
D is not that young, but the fact that it still really hasn't caught on suggests that it won't.
D suffers from sitting in an uncomfortable middle ground (C++ programmers tend to see it as a peculiar little brother of C++, while Java/C# programmers have never heard of it and wouldn't care about such a language anyway) and from a rather poor standard library, which lacks vision and extent. (The Java standard library and the .Net framework have extent, the C++ standard library has vision.)
That's what I mean by young. It has one version, a second experimental and lacking features that C++ take for granted - such as const correctness and has a poor standard library.
Granted, that should all change over time, when it becomes older and is my point. D is too young right now.
forget about C++, forget about D, F# is newer and thus better (given the idea that seems to permeate this industry that newer IS better by definition).
It's also further up the alphabet so it must be superior.
Well, if we consider lexicographic ordering, Whitespace is greater than all.
Soma
someone doesn't have his sarcasm detector engaged it seems :D
Well, of course I knew it was sarcasm, but you couldn't have picked a better language, could you?
Plankalkül?Quote:
Originally Posted by Elysia
Never heard of...
EDIT: Heh, old german language...
Uh uh, Lolcode or something ^^ Or some other which was 'leet' and then another which was kinda psycho... I think, or maybe that was only talked about :P
BrainF? :)
Yeah that ^^ My friend who does 3D, kept saying Lolcode was the best xD prolly thought coding was made the same way as 3D, by having a fancy application and do.. The 3D'ing :P
...So when were we going to go back to discussing C++0x? :/
Ok, so C++ gave Object Oriented programming, right? Does C++0x give any such major thing? Or am I getting it all wrong? :P
C++ is a language. It evolved from C and added OO among some, yes.
C++0x is not a new language, it is an evolution of C++ - a new version.
And it does add some significant things.
Variadic templates, concepts, static asserts, explicit conversion operators, lambdas, rvalue references, among others.
Yes, C++ extended C with constructs to support object oriented programming natively, but no, it was not the first programming language to support object oriented programming natively.Quote:
Originally Posted by Akkernight
You can read that interview with Stroustrup that I linked to. Nonetheless, note that C++0x is not a new programming language, but a new edition of the C++ standard.Quote:
Originally Posted by Akkernight
Lambdas o.o? Will that make physics calculation and stuff easier and more like the real stuff ^^? Love doing physics, if I do it right, if I get it wrong and just can't figure it out, I almost tear my hair out :P
In this case lamdba refers to anonymous functions. The name is from lambda calculus, not physics.Quote:
Originally Posted by Akkernight
Lambdas in C++0x allows you declare unnamed functions.
Like
I don't know what you get wrong with physics, so I cannot really say...Code:int array[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 0 };
std::for_each(array, array + sizeof(array), [](int n) { std::cout << n << std::endl; });
C++0x is like oiling an older machine. Much of the new standard is maintenance related from what I can tell - it does something about C++'s warts, introduces some new features; some good, some bad.
C++ already has OOP. With the introduction of things like concepts, they're trying to introduce new types of abstraction. Abstraction is a programming tool in itself which helps make your programs express the algorithms they use to solve problems more clearly. As an obverse example, take a look at programs written in earlier versions of BASIC: very little abstraction meant that code was a pain to write and maintain.
Sorry if I'm going on a tangent but that seems to be C++0x's purpose. In regards to the new standards name, I don't think the compiler would care if they called it C++Pudding. Maybe that's what it should be!
A lot is maintenance, I would say, a lot is new. And a lot is welcome.
But even the new stuff is maintenance of a sort. Just like you add new features to a program as part of maintenance: you discovered issues with the software, now you're adding a new feature to make something that you really want to do possible or easier. C++0x is like that.
Perhaps. I suppose it is because the committee is lacking resources for a major overhaul? They're more looking for easy things to implement that does not require as much time or resources.
Hmm... This might sound stupid, 'cause I don't really know much :P but I got this results from accelerated C++
File size list vector
735 0.1 0.1
7,350 0.8 6.7
73,500 8.8 597.1
And those look really drastic to me, so will C++0x also speed things like vector up? make it faster and stuff :P
Those results are for inserting and erasing, correct me if I'm wrong :P
"If it ain't broke don't fix it"? I don't want C++ to suffer from feature creep. In fact, a lot of things were proposed, and many of those were dismissed. But the published opinions from the committee seems like something one should read for themselves than asking a particular person here.Quote:
Perhaps. I suppose it is because the committee is lacking resources for a major overhaul? They're more looking for easy things to implement that does not require as much time or resources.
You are probably interpreting the results incorrectly. Different data structures have different trade offs.Quote:
Originally Posted by Akkernight
In languages, it's not a new version if you break backwards compatibility, it's a new language (Python 3 notwithstanding). C++0x is a new version. They can't do anything drastic, because old code would stop working.
(Minor incompatibilities are fine and pretty much unavoidable.)
I'm afraid you do not understand how the standard works.
They standard says how the implementation must work, but it is up to the compiler vendors themselves to create the implementation.
So either you are using the wrong solution to the problem or you are using a compiler with a slow standard library.
A new standard won't fix this.
Indeed. Usually a good motto if you don't want to break anything.
Of course, a major overhaul does not necessarily mean change all the interface and break everything, but adding a lot of time-consuming features, perhaps. Or along the lines of something like that.
Or maybe overhaul is the wrong word, but regardless. My point was that the committee is trying to take on easy tasks instead of big, complex ones due to somewhat limited resources.
Is it funding or simply not enough people to help out that's really the issue? Does anyone know?
Just so you people know, 'cause you seem to get it wrong :P but the book showed a test of why list is faster for some problems than vector ;)
Depends on where and how it is used.
There is no ultimate solution to all problems. Therefore, there is usually a solution to a specific amount of problems.
Lists are good for insertion or deletion in the middle, but slow at traversing or iterating.
Vectors are good for linear storing of data and a dynamic array, but are very poor at insertion or deletion in the middle.
Why not make a vectorlist? :O
Right, how would that work?
I know, you make a thing that lets you put a . after it, like... vectorlist<type> name, then name.something, and then this thing would see if it's erase or insert, it would use list, if it's push_back then use vector... I have no idea if that's possible, but it seemes logical enough to me :P
It is not.
It would have to keep a duplicate of all the memory. And what happens then if you delete or insert something? It would have to synchronize those two, and that would be worse than if it was only a single one!
You should know how vectors and linked lists works, should you not? Then you should also see how it is not possible to create a vectorlist.
It's time. A feature needs to be proposed. For this, someone has to write up a proposal. At the next standards meeting (and also before that, over mail), the proposal will be discussed in the responsible subgroup. If there are any issues, it will be sent back for revision. Otherwise, it is sent back with a request for wording. The wording will be drawn up and revised, and presented at the next meeting. The wording will be discussed and, if thought ready, passed on to the core group. This may happen at or between meetings, but more likely at. The core group will then review the wording and vote on it. If a proposal makes it to this stage, it will usually get voted in.
So, even a simple, picture-perfect proposal takes two or three meetings to find its way into the language. The committee meets four times a year. Do the math.
Complex proposals like concepts (and make no mistake, concepts were a huge thing) go through many iterations. I think the core concept proposal had about 8 revisions originally and then 9 revisions of the wording. And that's not counting all the sub-proposals, especially the library proposals, but also those for concepts not covered in the original work (TriviallyDestructibleAfterMove, range for loop, ...).
It's simply not true that the committee only took on the easy tasks. They did concepts and threading support. Those two were really, really big. Concepts present an entirely new look at templates, and the consequences for a language lawyer are staggering.
Threading support is much more than adding a thread class and a mutex class. The standard must describe exactly how a given C++ program will work, even in the face of multithreading. It must do so in a way that is not dependent on a specific machine architecture. To this end, the memory model and the execution model of C++ were completely revised. C++0x defines exactly what it means to have a race condition or a deadlock, and it defines the behavior of all multi-threaded programs that do not have such problems. This stuff is not visible to the typical programmer - he gets a very filtered look at the world of C++ - but it is extremely important to the compiler writers. We have to observe restrictions in what code we generate. Our optimizers must know exactly which optimizations are safe and which aren't.
Garbage collection support pretty much fell by the wayside. The committee rescued a definition of non-disguised pointers, and a few functions for pinning objects. This allows reliable behavior for library-based GCs.
But what other big issues do you think should have been approached? What was your wishlist that you feel that were left out due to limited resources?
We didn't get all the library functionality we were hoping for. We have regular expressions, basic timing functionality, lots of fun little utilities from TR1, hash containers, system error support, advanced math functionality, floating point management utilities, and of course threading support.
We didn't get directory support (is in TR2), date/time support, asynchronous I/O support, networking support, shared memory and memory-mapped file support, trees, thread-pools, or arbitrary precision numbers. But library updates are easy to issue compared to core language updates. TR2 will bring a lot of great functionality. And thanks to the work on C++0x, it will be great functionality with a great interface, employing move semantics and concepts.
You peeps are always so serious...
And Elysia, no I don't understand Linked List, since I've long forgot them :P I'm focusing only on what the book I'm reading teaches me, right now :P So, I'm only at strings... Or more exact, "Using sequential containers and analyzing strings", and an offtopic question now that I stumble on it, what does sequential mean? xD
That seems kind of... ridiculous.
So what is it preventing more meetings? Perhaps because members are from all over the world, I guess?
Oh no, never mentioned that. Only mentioned that they usually like to take easy tasks before big, complex ones, with the time constraints and all.Quote:
It's simply not true that the committee only took on the easy tasks.
Well, maybe there are a few things I would like - like getters/setters, but mostly I keep hearing things like "not enough resources".Quote:
But what other big issues do you think should have been approached? What was your wishlist that you feel that were left out due to limited resources?
I would, of course, very much want to see a GUI library. But that is very far-fetched and unlikely to make it into the STL for a very, very long time, if ever. Lacking resources is the quote for the why on that.
I would also like to see boost::lexical_cast make it into the language, and from what I hear, it's coming in the next TR or in the near future.Quote:
We didn't get all the library functionality we were hoping for. We have regular expressions, basic timing functionality, lots of fun little utilities from TR1, hash containers, system error support, advanced math functionality, floating point management utilities, and of course threading support.
We didn't get directory support (is in TR2), date/time support, asynchronous I/O support, networking support, shared memory and memory-mapped file support, trees, thread-pools, or arbitrary precision numbers. But library updates are easy to issue compared to core language updates. TR2 will bring a lot of great functionality. And thanks to the work on C++0x, it will be great functionality with a great interface, employing move semantics and concepts.
Don't take everyone for being so serious all the time, even if there are no smilies...
A linked list basically means a bunch of structs.
Each struct points to the next and potentially to the previous, and potentially to the end or the beginning of the list.
Since they are connected by pointers, it's very easy to add or delete something in the middle because you just have to reconnect the pointers.
But traversing a big list, like finding the Nth element is very expensive since it has to walk through each node in the list.
Sequential means spread out after each other. Like a long row of something.
A vector is sequential. Which means that if you add something - the entire row behind it has to be pushed back.
Likewise, if you delete something, everything has to be pushed forward.
Otherwise it isn't sequential.
You don't seem to understand how lists and arrays are different. Arrays offer fast access through locality of reference, but it's time consuming to properly delete from the middle of an array. It can be difficult too, if you've never had a similar problem before.Quote:
I know, you make a thing that lets you put a . after it, like... vectorlist<type> name, then name.something, and then this thing would see if it's erase or insert, it would use list, if it's push_back then use vector... I have no idea if that's possible, but it seemes logical enough to me :P
Lists are easy to delete from because they only refer to their neighbors. It can be difficult (but not impossible) to ensure locality of reference.
Now combining the two is interesting. You can always have a list of arrays, for example, but that doesn't always make out to be a silver bullet. To demonstrate effective use: a list of arrays is often used to resolve collisions in hash tables. The reason it ain't a silver bullet though is because algorithm design depends on how you should properly store data. If the data is atomic, then using a list of arrays does not make sense, does it? You use both data structures and yet get none of the benefits, being rather cute and wasteful in terms of resources.
Hmm... It is possible to copy the contents from a vector to list, right? Or is there some cool feature like conversion?
Anyways, as a personal task, Imma make a function that... Does kinda what I talked about :P Even tho it'll definetly be a waste of everything, I find such tasks fun ^^
EDIT: Meh, was a fail, but fun anyways :P I dunno how to make one function that accepts both vectors and lists, and I dunno how to allow it to accept all kinds of types, standard or custom :P like int, double or string, but I still made one that accept vector<string> ! :P
Of course, but it will take linear time.Quote:
Originally Posted by Akkernight
Each container has a constructor that takes a pair of iterators. They also have an assign function for copying to existing container. In addition there is the std::copy algorithm.Code:It is possible to copy the contents from a vector to list, right?
Fill in the blanks to complete your vectorlist class:
EDIT: My goal is after filling in several more "blanks" the repetitive nature of this project begins to reveal its own futility...Code:#include <vector>
#include <list>
template <typename T>
class vectorlist{
public:
vectorlist(){};
void push_back( const T& d );
// Fill in the blanks w/ other member funcs
private:
std::list<T> mlist;
std::vector<T> mvec;
};
template <typename T> void
vectorlist<T>::push_back( const T& d ){
mlist.push_back( d );
mvec.push_back( d );
}
// Fill in the blanks with other member funcs
int main(){
vectorlist<int> vl;
return 0;
}
Are you saying I'm supposed to use that? 'Cause I don't understand how that works or how to use it :P
It's an example that, when you complete it, will show you exactly why your idea of a hybrid vector/list just isn't feasible.
It's super simple! What is it that you fail to understand?
template<typename T>, what does it do o.O? and it has no definitions...
Is that some kind of class function?Code:vectorlist<T>::push_back( const T& d ){
mlist.push_back( d );
mvec.push_back( d );
}
And what would happen if I tried:
vectorlist<string> vlString;
vlString.push_back("Where am I?");
Does it work just as using the normal vector?
It is the basics of an implementation of a vector.
I take it you are unfamiliar with templates. Well, should you wish to implement a vector or list or anything else, then you should learn template basics. Nothing advanced, just basics.
And yes, it would work just like a normal vector in that sense. It's missing some stuff like operator [], but otherwise, sure.
It would work precisely that way. Because all I've done is create a class which has a list and a vector within itself. The template <typename T>, means that the vecotrlist (and therefore the list and vector) can take any type, like: vectorlist<int>, vectorlist<string>, etc, etc.
Not "not enough interest"? ;)Quote:
Well, maybe there are a few things I would like - like getters/setters, but mostly I keep hearing things like "not enough resources".
Seriously though, I don't expect any of the people who are likely to write proposals (anyone can do that, by the way - but not anymore) to care enough about language-integrated property syntax to write a getter/setter proposal. They might even oppose it, because it's a core language change that does not really enable new functionality.
No, actually it's lack of agreement. Take any two people from the C++ community and ask them what their GUI library should look like. You will get two answers that areQuote:
I would, of course, very much want to see a GUI library. But that is very far-fetched and unlikely to make it into the STL for a very, very long time, if ever. Lacking resources is the quote for the why on that.
1) either incomplete (too little functionality to be useful), infeasible (feature creep, too big), or unportable (most common problem) and
2) very different.
Stroustrup has pretty much said that nobody needs to bother sending in a GUI proposal because it's just not happening.
Think about the devices C++ targets: everything. Do you really think that you can design a GUI library that is equally applicable to desktop PCs and handheld devices? Have you ever looked at design paradigms of the iPod Touch and compared them to the way desktop software is designed? Do you think the two can be unified?
Regarding the other thread of conversation:
1) You're way off-topic.
2) When you hold data in two parallel structures, you get the best of both worlds on reading, but the worst on writing.
Meh, I have no idea what I'm working with and using mlist.erase(mlist.begin() + d) gave me errors I'm not even gonna bother about >.<
Oh, and the last thing, it was mainly a joke, and I have very poor programmin skills :P
And it's not that off-topic, who doesn't want the ultimate working vector? :P
Perhaps C++0x should specify a time-machine, so that operations on containers are completed even before they started?
Also, isn't deque kind of listvector (fast insertion/erasure at both ends)?
But not in the middle. Deque has yet again different trade-offs.
Sure. Why not also show how we can calculate an electron's position and velocity at the same time? If you can solve that problem, then I'm sure you can also create a vectorlist.
Type-safe enums don't change how enums are used. Type safe templates do, because there is a lot more code needed to make a template typesafe.
It gives type safe generic programming in the form of concepts and multithreading support.
Actually they were originally looking to make even fewer changes to the language, focusing instead on library changes. But it seems there was more demand for language changes than more libraries.
There is no funding. The committee members are volunteers. You may even have to pay to be a part. People are a limiting resource in terms of what changes are made, but when designing something this big too many cooks spoil the stew.
For getters and setters, I know.
But for other things... not enough resources.
Stroustrup quotes it as not enough resources, and I can really picture that especially because of what you say. When people disagrees, it will take a tremendous amount of time to reach an agreement that works with everyone. It just takes too much time.Quote:
No, actually it's lack of agreement. Take any two people from the C++ community and ask them what their GUI library should look like. You will get two answers that are
1) either incomplete (too little functionality to be useful), infeasible (feature creep, too big), or unportable (most common problem) and
2) very different.
Stroustrup has pretty much said that nobody needs to bother sending in a GUI proposal because it's just not happening.
Think about the devices C++ targets: everything. Do you really think that you can design a GUI library that is equally applicable to desktop PCs and handheld devices? Have you ever looked at design paradigms of the iPod Touch and compared them to the way desktop software is designed? Do you think the two can be unified?
I still like type-safe enums :)
One of my favorites!
My favorite is auto
The "export" keyword. Or some real way of separating template def and implementation would be nice.
It can be done already.
Just create your definition, and then your implementation.
Both are going to have to be placed inside headers, however.
Although you cannot simply include the definition and make it work, but still, it is a way to separate the two.
And "export" is not new to C++0x, and I doubt compilers are going to start to implement them because they are a pain to implement.
Well I understand how C++ treats templates differently than other things, hence the problem of not separating the two exactly as you would other class defs and implementation files. However my proposal would be like a new macro, something like:
and then allow you to separate the impl into a .cpp file. There's probably reasons well above my head as to why that won't work, but it's a nice thought.Code:#ifndef
#thedr MYTEMPLATE_H_
#define
#thedr MYTEMPLATE_H_
template <typename T>
class foo{
};
#endif
The export keyword already exists. The problem is that noone wants to implement the feature, because it's complicated - but there's just no way around this. There is no simple way of separating templates from their use.
What would #thedr do?Quote:
However my proposal would be like a new macro, something like:
>>What would #thedr do?
In my feable mind, it would tell the compiler that it's a template so do the behind the scenes compiler magic and allow it to be treated like any non-template header file! LOl!
There's nothing special about a header file that contains a template. Header files are just text files included verbatim by the preprocessor. The template engine never knows whether the stuff it sees comes from a header, from a main source, from a precompiled header, is generated by macros, generated using a compiler-specific special extension, or inserted randomly just to mix things up a bit.
Seems to me like you're trying to re-implement the export keyword.
But since it already exists...
This is why I said it was above my head...
But I thought the way the .o file was generated was somehow different for templates than other object files? Is this where the complication is involved?
EDIT: Complication being implementing the "export" keyword?
No. The fact that you think a .o file is an integral part of compiling C++ shows the actual problem. The traditional C compilation model is simply inappropriate for exported templates. Implementations that use tricks to still integrate in this system are inefficient.
If there was a C++ implementation that completely changed the compilation model, it could perhaps implement exported templates efficiently and easily. Currently, there is no such implementation. One of the big obstacles in creating it would be that it just doesn't play nice with current project management tools.
See, the problem is that a .o file does not contain templates. When the object file is generated, all templates must have already been instantiated. Thus, the compiler must have the template definition before generating the object file.