Another problem with those variable-sized arrays seems to be that they are limited in size (you can have only so much stuff on the stack). Crashes for me if i input one million.
Another problem with those variable-sized arrays seems to be that they are limited in size (you can have only so much stuff on the stack). Crashes for me if i input one million.
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
A PDF copy of the 2003 edition of the C++ Standard (ISO/IEC 14882:2003) can be purchased from the online ANSI store for 30 USD.Originally Posted by Luciferek
Language extensions are allowed, hence users can choose when compiling. Then, compilers are typically do not fully conform to the C++ Standard, so there are edge cases where things are different when compiled on different compilers, even if the Standard says that they should be the same (or perhaps a language feature is not even available).
Since "maximum" is an exaggeration, I think that Microsoft has beaten you to it with Managed C++ and its successor C++/CLI.
Dev-C++ is not a compiler, but an IDE whose default compiler is the MinGW port of g++.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
>> So, In other words... There is no real advantage to using a new and delete keywords except
that it is accepted as a standard? <<
I can think of no advantage to use new and delete for arrays, ever. (Well, almost never.) Use vector.
I don't have a problem with people using a compiler extension in some cases. Many extensions are things that will end up being standardized in the future, and the reason they get standardized is because users use them when they are merely extensions and the community forms a common practice. In this case, variable length arrays are standard in C (which is why gcc allows them), so it's not like you're using some far-fetched feature that will never work anywhere but your current environment.
That said, I don't see the point of using variable length arrays in C++ when the much better option of vector is standard and available.
Yeah, but vector might not have the same performance as an array. Don't know, haven't tested it. Though they should be the same at least for big arrays.
>>I can think of no advantage to use new and delete for arrays, ever. <<
Isn't a vector also allocated on the stack? What if you want a very big piece of memory? You will have to use new/delete even if you just allocate a vector. Right?
Yes, it is.
No. Variable arrays are allocated on the stack.
Indeed, it must be done at run-time, which, I believe, is why it isn't allowed by the standard. And I don't see it being allowed for anything except perhaps backwards compability in the future.
And yes, since they are on the stack, they behave like anything else on the stack.
The stack is also limited, and it has limited life-time, so there are two other reasons to use new/delete.
The standard defines what C++ is. The compilers' job is to follow that standard.Besides why are compilers picky in what they allow and what they do and don't allow? Isn't C++ a C++?
So, if I create a compiler that will bastardize the C++ syntax to the maximum it will be ok?
Otherwise we would have a thousand compilers each with their own syntax and features.
Why is this a good thing? I think you get the point.
I doubt that. You see, there are many solutions to the problem.More I learn C++, more i get angered by it!
Bjarne must have been smoking crack or something!
By the way, the compiler I used to compile it is Dev C++.
First is std::vector. It can take a variable at runtime and define its size.
Second is smart pointers. You can use new to allocate enough storage and hold it in a smart pointer. The smart pointer will free the memory for you.
Some examples of smart pointers are std::auto_ptr, std::tr1::shared_ptr, std::tr1::weak_ptr.
Wouldn't surprise me, since the stack is only about 1 MB.
the vector's internal allocation (the array itself) is on the heap. I don't really agree that you should never use old school arrays. But generally you are safer if you use the stl for most containers.
"You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter
No, it will be on par with native arrays, unless extra checks are done to see if you aren't going out-of-bounds.
I know VC++ produces the exact same code for a vector with operator [] and native arrays (when disabling the extra checks and in release mode, of course).
Nope, std::vector allocates its storage on the heap.>>I can think of no advantage to use new and delete for arrays, ever. <<
Isn't a vector also allocated on the stack? What if you want a very big piece of memory? You will have to use new/delete even if you just allocate a vector. Right?
For the comparison to be valid, it has to be between a dynamically allocated array and a vector. If you compare a statically sized array to a vector, then of course working with the statically sized array would be faster, but it also has its limitations.
No, the contents of a vector is a dynamically allocated array (it would be tough to do it otherwise since the contents must be contiguous). The vector container itself could be on the stack, of course.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
>> Yeah, but vector might not have the same performance as an array. Don't know, haven't tested it. <<
A (dynamic) array might not have the same performance as a vector. In fact, chances are that a vector will be faster than a dynamic array if you need it to resize because it will be difficult for you to do a better job of writing that code than the experts who implement vector.
>> Isn't a vector also allocated on the stack? <<
The vector itself is allocated on the stack, but the memory it uses for its data is dynamically allocated "on the heap".
>> What if you want a very big piece of memory? You will have to use new/delete even if you just allocate a vector. Right? <<
Nope. That's the point of vector. To manage arrays allocated with new. It handles all that stuff internally.
If you need a fixed array, there's also boost::array (or std::tr1::array). It replaces the "native" C-style array.
>> I don't really agree that you should never use old school arrays. But generally you are safer if you use the stl for most containers. <<
The comment was specific to dynamic arrays using new[]/delete[]. Can you come up with a situation when it makes more sense to use those? I've honestly never heard one.
Sure, reading off a socket when the data structure provides a size for the following data. Same can be said for reading from a file. Plus, there are times when its appropriate to write a non standard container class.
"You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter
>> Sure, reading off a socket when the data structure provides a size for the following data.
Why is new[]/delete[] better for that? I don't think it would be any more efficient, since vector does the same thing under the hood. The vector would be easier to use, though, since you don't have to worry about when to delete the memory.
because reading off a socket requires a buffer. Unless of course you go one byte at a time.
"You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter
You can get a buffer from vector, too.Code:std::vector<char> buffer(numBytes); sock.read(&buffer[0], numBytes);
