In case you haven’t been paying attention, the final Committee Draft of the C++0x standard is out for review, and there is not much time left to make sure we fix any stupid mistakes, wrongheaded blunders, etc. To be specific, the official comment period ends 27 May, and if you submit a comment to your national body, the committee is required to “deal with it.” We can decide not to take any action, but we’re not allowed to ignore it. Trivial mistakes like typos can always be fixed after the standard ships, but since we’re on an aggressive schedule to ship this one, the next few days may be your last chance to help us get the big issues right.
Posted May 24, 2010 by Dave Abrahams, under Uncategorized
Did we get variable sized arrays (with const size initializer) as class members?
PLEASE tell me we did.
If the standards committee insists on fragmenting my memory I’m going to stop using their crappy language.
I don’t remember seeing your proposal for it.
If the size initializer is const, what’s “variable” about it? The only relevant const-ness for a size parameter is compile-time constness here, so why not just use T[N]?
Something like this:
struct Matrix { float data[]; Matrix(int M, int N) : dataM,N {} };
Variable sized arrays (sized at instantiation) as class members could hugely reduce the number of calls to new/delete for crafty programs, and the resulting memory contiguity would largely decrease the number of cache line fills required for common access patterns.
IMHO This is the most glaring flaw in C++. I go a lot of trouble to setup my own block allocators and have always wished C++ would handle this for me.
As a sidenote, there is a similar problem with STL, (thought not Microsofts’) in that there is no way to provide a different allocator per instantiation. IMHO the default STL allocator should be doubling realloc() buffer based, with a buffer per data-structure. The lack of this capacity insures memory fragmentation and poor performance.
If the size was given as parameters to the constructor, then there would be nothing preventing the caller from using values calculated at runtime. The size of the object would then no longer be able to be determined at compile time. Wouldn’t you just want to use a template?
template struct Matrix { float data[M][N]; }
The date we have for BSI is also 26th July, but I’ve asked people to check. If the last date for the US is 27th May, but the final date for ISO is later then people can still file comments via BSI. See my blog post: http://www.justsoftwaresolutions.co.uk/cplusplus/c++0x-now-at-fcd.html
May 27 is indeed the deadline for the US national body (PL22.16) only. The deadline for all national bodies to submit their ballot responses is July 26.
If you are interested in providing comments, Anthony Williams is accepting comments from the general population on behalf of BSI.
http://www.justsoftwaresolutions.co.uk/cplusplus/c++0x-now-at-fcd.html
He has a deadline of Friday June 18th for accepting such comments.
How does one submit comments to the US NB?
Rob,
US NB comments go to Barry Hedquist: (beh AT peren DOT com). I’ll attach the comment template to this article.
…but now that I look, I’m not at all confident that he can accept comments from non-voting members. You can always send comments to Anthony Williams, though (see his comment here)
I don’t know; that’s the deadline for US national body comments. Maybe different NBs have different deadlines. We should probably both check with our respective representatives to make sure there’s no mistake.
Hi Dave, the other day at a Spanish NB meeting the date reported for submitting comments to the FCD was July 26th. Am I missing something?