Thread: C++0x ???

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.

Originally Posted by Akkernight

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?

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.

Well, maybe there are a few things I would like - like getters/setters, but mostly I keep hearing things like "not enough resources".

Not "not enough interest"?
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.

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.

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?



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.

Originally Posted by Akkernight

Why not make a vectorlist? :O

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.

Originally Posted by cpjust

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.

I did that yesterday.. While making me breakfast... :P
And Anon, nice thought That would so rule! ^^
Meh, I'm been extremely tired all day, so there hasn't been much thinking from my side :P

Originally Posted by Elysia

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.

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.

Originally Posted by Akkernight

Ok, so C++ gave Object Oriented programming, right? Does C++0x give any such major thing? Or am I getting it all wrong? :P

It gives type safe generic programming in the form of concepts and multithreading support.

Originally Posted by Elysia

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.

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.

Originally Posted by Elysia

Is it funding or simply not enough people to help out that's really the issue? Does anyone know?

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.

Originally Posted by CornedBee

Not "not enough interest"?
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.

For getters and setters, I know.
But for other things... not enough resources.

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?

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.

Originally Posted by King Mir

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.

I still like type-safe enums
One of my favorites!

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:

Code:

#ifndef 
  #thedr MYTEMPLATE_H_
#define
  #thedr MYTEMPLATE_H_

template <typename T>
class foo{
};

#endif

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.

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.

However my proposal would be like a new macro, something like:

What would #thedr do?