Thread: C++0x ???

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

Originally Posted by CornedBee

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.

That seems kind of... ridiculous.
So what is it preventing more meetings? Perhaps because members are from all over the world, I guess?

It's simply not true that the committee only took on the easy tasks.

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.

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?

Well, maybe there are a few things I would like - like getters/setters, but mostly I keep hearing things like "not enough 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.

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.

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.

Originally Posted by Akkernight

You peeps are always so serious...

Don't take everyone for being so serious all the time, even if there are no smilies...

Originally Posted by Akkernight

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

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.

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

Originally Posted by Akkernight

It is possible to copy the contents from a vector to list, right?

Of course, but it will take linear time.

Code:

It is possible to copy the contents from a vector to list, right?

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.

Originally Posted by Akkernight

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

Fill in the blanks to complete your vectorlist class:

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;
}

EDIT: My goal is after filling in several more "blanks" the repetitive nature of this project begins to reveal its own futility...

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...

Code:

vectorlist<T>::push_back( const T& d ){
 
 mlist.push_back( d );
 mvec.push_back( d );
}

Is that some kind of class function?
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?