Re: Using the STL for scientific programming
Am 03.10.2011 20:56, schrieb Dave Harris:
musiphil@bawi.org (Seungbeom Kim) wrote (abridged):
Then is new[]/delete[] your preferred choice?
What benefits does it bring, and why would you prefer it to
std::vector?
As a petty example, you can't write:
#include<vector>
class MyData;
std::vector<MyData> vec;
because it's undefined behaviour to instantiate a std::vector on a
partial type. Where-as with my home-grown vector, I can.
With a grain of salt, yes. It would still be undefined behaviour, if MyData has a non-trivial destructor or a deallocation function.
The standard
reserves for itself lots of freedoms and those translate into
restrictions for users.
This is correct, even though I believe that this constraint *could* be relaxed for std::vector (and some other library types). In this case, the problem is mainly the cost to define the specification. It surely won't be without costs. You have to make this valid for all the declaration dependencies of std::vector (std::allocator and std::initializer_list come immediately into my mind) and you have to be sure that you have considered every member function. Plus it increases the complexity for each newly added member (because it has to be fine-checked in regard to type completeness). This is a lot of work. As an example, just search for the terms "shall be well formed" and "shall have well-defined behavior" in sub-clause [unique.ptr.single]. Now try to apply this std::vector.
The consequence is that I can't use std::vector in a header, without also
including the definition of MyData, which pollutes the namespace and
causes more and longer recompiles. I can't forward-declare std::vector<>
itself, either.
Also agreed. Again, this would need a good-quality specification. You probably need to specify basically the same number of <X_fwd> headers for each current <X> header, with all the content description.
I'm sure that the committee would appreciate a proposal like that, but the risk could me that the proposal would have the effect of increasing the library part of the standard by estimated one-fourth. I'm not sure, whether the resources exist to manage this (But I don't want to discourage anyone, I'm only pointing out the risks).
The alternative is to just complain to your compiler vendor, AFAIK there do exist implementations that allow this. Once this has been done, it is much easier to standardize this. De factor, the C++ standardization is mainly driven by "existing implementation experience" in the wild.
Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]