Printable View
Hi,
Let's take a class A
so..once I have this class with a constructor that accepts a char *, can I do this..?Code:
class A
{
char a[10];
public:
A(char *);
};
if not, it will mean that a array member can never be initialized using the member initialization list. or is it not?Code:
A::A(char * s)
:a(s){}
will be elated to get the right "pointer". ( :-D )
Indrajit
I know literally nothing about initialising arrays in a initialiser list but if you actually compiled the code you'd get an error similiar to this:Quote:
Originally Posted by indrajit_p1
:thumb:Code:error C2536: 'A::A::a' : cannot specify explicit initializer for arrays
hmm...
I started in programming with Fortran and moved on to C. Always felt in those days that C++ is not really as good as it looks like.
But the last 4/5 years on and off with C++ had the idea that all the fancy features of C++ fits into each other amazingly well, growing in me.
Now it looks to me like they should have stopped at dumb C data strucutres where you could simply use a initializer list.
"Seem"s like I have come a full circle...
:-)
I
p.s.: MyBowlCut - thanks for the very conclusive pointer though.. (a word better than coclusive is evading me as I write this)
most likely you should not be using c-style arrays at all.
If you are trying to represent a string, use std::string.
If you are trying to represent a buffer, use std::vector.
Trying to bring the habits you have learned in C to C++ will result in very bad C++ code.
And what would happen, if s points to more than 10 characters? Should a be initialized with the first 10 characters only? Or should a be initialized with the first 9 characters only and a[9] be automatically initialized with a terminating zero. Or should more than 10 characters be copied causing a buffer overflow that some distant day would have crashed the program?Quote:
Originally Posted by indrajit_p1
There are good reasons why the code you posted does not compile.
Frankly, it *should* be possible to do something like
though. That would make sense, and is a fairly strange oversight.Code:class A
{
char a[10];
public:
A(): a({0,1,2,3,4,5,6,7,8,9})
{}
};
I agree with that. :thumb:Quote:
Originally Posted by Lindley
Hi guys,
This really made me appreciate std::string!
However,
I did some studying of my own and I came to a conclusion at this point that it is not possible to initialize an array in the initializer list and I'd like to confirm this finding (or correct) by those who know better.
My understanding is this -
When an element initializer is used, its copy constructor is called,
I'm not sure if this applies to an array but it certainly applies to sequential containers.
if this too applies to the array, and we know that there is no array copy or assignment,
hence, the initialization would fail for the array.
can anyone tell me more in details if this is true or not?
Thanks.
Not always the copy constructor; but a constructor of some type, certainly. Since arrays aren't constructable....
looks like a new language feature, std::initializer_list, will be introduced to solve this problem.
Hmm...
This is turning interesting and educating.
Lindley, your suggestion hardcodes the initializer list into the constructor. (??)
Indrajit
Lindley's example is not valid in C++. It appears that it will be in future implementations of the language.
Depending on what you are using that c-style array for, C++ most likely provides more appropriate tools, such as std::string, std::vector, ....
If you must use a c-style array, then the normal way to initialize it is in the body of the constructor, not in the initializer list.
As long as I can think of, using C-style arrays is cheaper than using std::vector or std::string. I've made a template class for static arrays which is essentially the same with C-style arrays except they are more convenient. I'm posting it as I think it might help you.
But there is a problem. Each member in the array must be default-initialized first and then assigned to a value (see the tagged line above). A more sophisticated version can fix this problem.Code:template <class Type, size_t Length>
struct static_array
{
Type Data[Length];
operator Type* ()
{ return Data; }
operator Type const* () const
{ return Data; }
typedef static_array<Type, Length> my_type;
static_array() {}
static_array( Type const* pData )
{
for( size_t i = 0; i < Length; i ++ )
Data[i] = pData[i]; // <-- introduces inefficiency
}
static_array( my_type const& Ob )
{
for( size_t i = 0; i < Length; i ++ )
Data[i] = Ob.Data[i];
}
my_type& operator = ( my_type const& Ob )
{
for( size_t i = 0; i < Length; i ++ )
Data[i] = Ob.Data[i];
return *this;
}
~static_array() {}
};
// You can specify constructor for it.
class A
{
static_array<char, 10> a;
public:
A(char * p)
: a(p)
{}
};
Sorry if too complex. Some other people may have simpler solution.Code:// This struct is used to call constructor / destructor in demand
template <class Type>
struct manual_construct
{
Type data;
// Construction / Destruction
manual_construct()
{}
manual_construct( Type const& Ob )
: data(Ob)
{}
~manual_construct()
{}
// Operator new / delete
// These operators does nothing.
void* operator new ( size_t, void* pvAddress )
{ return pvAddress; }
void operator delete( void*, void* )
{}
void operator delete( void* )
{}
};
// This class takes space for one element, but construction will be done
// in demand
template <class Type>
class reserved_space
{
private:
char buffer[sizeof (Type)]; // declared as char array to prevent calling constructor automatically
public:
void construct()
{ new (buffer) manual_construct<Type>(); }
void construct( Type const& Ob )
{ new (buffer) manual_construct<Type>( Ob ); }
void destruct()
{ delete reinterpret_cast<manual_construct<Type>*>( buffer ); }
reserved_space() {}
~reserved_space() {}
};
//
template <class Type, size_t Length>
struct static_array
{
reserved_space<Type> data[Length];
operator Type* ()
{ return reinterpret_cast<Type*>(data); }
operator Type const* () const
{ return reinterpret_cast<Type const*>(data); }
typedef static_array<Type, Length> my_type;
static_array()
{
for( size_t i = 0; i < Length; i ++ )
data[i].construct();
}
static_array( Type const* pData )
{
for( size_t i = 0; i < Length; i ++ )
data[i].construct( pData[i] );
}
static_array( my_type const& Ob )
{
for( size_t i = 0; i < Length; i ++ )
data[i].construct( Ob[i] );
}
my_type& operator = ( my_type const& Ob )
{
for( size_t i = 0; i < Length; i ++ )
(*this)[i] = Ob[i];
return *this;
}
~static_array()
{
for( size_t i = 0; i < Length; i ++ )
data[i].destruct();
}
};
I've looked at the boost source code and found that boost::array has the same problem. e.g. all elements are first initialized and then can be assigned. So it might not optimal when elements are heavy objects. (umm...maybe swap() can help but not entirely)
How about re-implementing that? We can invoke copy constructors directly.
Hope your opinions
Not to any significant degree, if you use them properly. I mean, sure, if you're passing a std::vector by value all over the place and duplicating it on a whim, or resizing it a lot, it can get expensive. But if you treat it just like a C-array----pass by reference or const reference, initialize a size on construction and leave it that size, etc----the extra cost is completely negligible, and your code becomes far cleaner. Similar logic applies to std::string.Quote:
Originally Posted by muse1987
Try to resize a C-style array.Quote:
Originally Posted by muse1987
So you're just referring to static arrays? Then a std::vector has negligible difference between itself and an array if the vector isn't resized.Quote:
I've made a template class for static arrays
Probably faster:Code:for( size_t i = 0; i < Length; i ++ )
Data[i] = pData[i]; // <-- introduces inefficiency
Also your assignment operator doesn't check for self-assignment.Code:std::copy(pData, pData + Length, Data);
Regards,
Paul McKenzie
When I say C-style array is cheaper than std::vector, it implies the case where we can choose either one. How can we compare their costs otherwise?Quote:
Originally Posted by Paul McKenzie
Are you sure? In my understanding, std::vector allocates its buffer on the heap. And heap is far expensive than stack. The following code takes 225 nanoseconds on my machine (mine is not too old, with 2GHz core frequency)Quote:
Originally Posted by Paul McKenzie
But obviously C-style array like "int V[10];" have almost no overhead, as all it needs is just modifying the stack pointer.Code:std::vector<int> V(10);
Isn't it essentially the same? I used to write my own code for trivial cases because overwhelmingly complicated STL code often fools my compiler optimization. In the case static_array<int,10>, the implementation that uses std::copy() takes 32.8 nanoseconds while the one with for( ;; ) takes 16 nanoseconds on my machine.Quote:
Originally Posted by Paul McKenzie
And furthermore, what I meant by 'inefficiency' was not that (I wrote this in the previous post but writing again). Suppose elements of the array are heavy objects, e.g. they acquire some system resources when they're constructed. In that case my first version constructs all elements, which involves resource acquisition, and then copy the objects. The second version I've posted fixed that issue by copy-constructing elements directly. (well, this idea was borrowed from STL implementation)
You specified the right point. Thanks. Maybe it has worked fine until now because each elements' assignment operator checks self-assignment. But I do appreciate your advice as it makes it faster in the self-assignment case.Quote:
Originally Posted by Paul McKenzie
Please look at my post above. It would tell you why we should use C-style arrays in trivial cases.Quote:
Originally Posted by Lindley
You're correct that stack allocations are faster than heap allocations. But std::vector is certainly no worse than using new[]. So if you know the size at compile time, go nuts with the stack; if not, use a std::vector.
I recently encountered a class called UnicodeString, part of the ICU project. Not only does it have copy-on-write semantics, but it *also* contains a small internal buffer, which is used until the string it contains grows too large, at which point it moves the data to the heap. It would be nice if the STL had containers with such mechanisms.
Invariably, whenever the discussion of which is faster, it always comes down to the resizing that eventually invalidates arrays being faster than vector.Quote:
Originally Posted by muse1987
Of course using arrays in a trivial way are faster. Arrays are basic 'C' types. But how many times do you see people trying to beat vectors using pointers and new[]/delete[], believing what they're doing is faster than a vector?
Real code is more than just initialization.Quote:
Are you sure? In my understanding, std::vector allocates its buffer on the heap. And heap is far expensive than stack. The following code takes 225 nanoseconds on my machine (mine is not too old, with 2GHz core frequency)
The same thing in terms of final results -- it isn't necessarily the same thing in terms of how those results are achieved. For example, you post-increment the loop counter -- I'm sure that a good implementation would pre-increment the loop counter. Also, a good implementation would specialize std::copy to do a memcpy() if POD types are used.Quote:
Isn't it essentially the same?
Get another compiler. I've not tested std::copy, but I know STL algorithms such as std::transform(), std::for_each(), etc. are invariably faster than hand-written loops.Quote:
I used to write my own code for trivial cases because overwhelmingly complicated STL code often fools my compiler optimization.
Also, what is "overwhelmingly complicated" to you may be trivial to someone else. So "overlywhelmingly complicated" is highly subjective.
Then a C++ programmer would know to use a vector of some pointer or smart pointer type, not a vector of objects. Maybe they would use the vector of objects to get something working, but then switch to the (smart) pointer vector when finally optimizing the code.Quote:
Suppose elements of the array are heavy objects,
In other words, there is no sense in timing things that no smart programmer would really ever do. If you were to time, say an array of smart pointers against a vector of smart pointers, then that is different.
Regards,
Paul McKenzie
The Visual C++ implementation of std::string uses "short-string" optimizations as you described.Quote:
Originally Posted by Lindley
However, I believe that copy-on-write is going to be outlawed for std::string implementations, since std::string must be implemented internally as an array of char type (an upcoming addition to the ANSI standard).
Regards,
Paul McKenzie
Well, copy-on-write could still be used; they'd just have to make sure that the non-const version of .c_str() and the non-const version of operator[] triggered the copy, and any other non-const means of accessing the underlying array. You'd still get major savings that way for const strings.Quote:
Originally Posted by Paul McKenzie
Of course, it may not be worth it; const strings could be passed by reference as easily as by value, and the C++0x concept of an R-value reference handles most of the other potential savings areas.
Here we go again and again and again. Some people just can't get enough of bashing std::vector and trying to rewrite the C++ std template library in their spare time. I guess some people have a lot of time on their hands. While it's true that vector default initializes the members most people would manually initialize a c style array anyhow. So unless you are dealing with an enormous buffer that doesn't need to be default initialized I can't see the advantage of rejecting the std::vector. It'd be nice if in a future release of the C++ std the vector constructor is redesigned to not initialize the memory unless the user specifies a value in the constructor.
Sorry, I do not see any post that tells me this. I don't really care if heap memory is slower than stack memory and I am not sure that I buy your statement that there is a significant difference. You didn't provide any numbers for the use of stack memory. You said that it takes 225 ns for your heap example. How much faster is stack? Even if it is slightly faster why does that mean I have to use a c array instead of a vector? There are cases where a vector might be slower but is still a better design choice in the long run (code readability and maintainability, better OO design for instance). Not all programs are perfectly optimized for speed nor do they need to be.Quote:
Originally Posted by muse1987
Well now, let's not go dismissing the benefits of avoiding heap allocations altogether. That way lies terrible code.Quote:
Originally Posted by kempofighter
Getting memory from the heap involves some fairly complex algorithms to choose the right bit to give you. Getting memory on the stack requires one addition instruction. *If* you're absolutely certain that you only need 10 elements in an array, and out-of-bounds accesses aren't even a remote possibility, go ahead and stack-construct it by all means.
std::vector is great. I use it all the time. But there is no one correct solution to every situation.
From a newbie's point of view,
I prefer vector over array because;
1. My first book devoted far more pages on vectors than it did on arrays, so I'm used to vector
2. I fear that I might have shortcomings, but realized that vector does pretty much anything array does
3. Vector offers simplicities enticing beginners and allowing us to have good time programming.
As I said before, I'm referring the case where we don't need to resize the array. From the first I never told new[]/delete[] is better than std::vector.Quote:
Originally Posted by Paul McKenzie
And you should have realized what I'm telling when you saw my class : it isn't designed for dynamic arrays. It just encapsulates static C-style array to help array-copy. There's absolutely no point to mention new[]/delete[] since I didn't talk about it.
And much more initializations.Quote:
Real code is more than just initialization.
std::copy is already implemented through memcpy(). And MSVC2005 doesn't actually generate function call but inlines it. So, what's happening in the for( ;; ) loop? The compiler unrolls the loop since it knows how much time it executes in the compile time. An ideal C++ compiler would even unroll memcpy() if size is known in compile time. C++ compilers aren't as perfect as one might expect.Quote:
The same thing in terms of final results -- it isn't necessarily the same thing in terms of how those results are achieved. For example, you post-increment the loop counter -- I'm sure that a good implementation would pre-increment the loop counter. Also, a good implementation would specialize std::copy to do a memcpy() if POD types are used.Get another compiler.
Pre-increment isn't better than post-increment for POD types. And I would mention that the code I posted is more than 6 years old.
Depending on the programmer's skills. Nothing can be always good. If hand-written code is slower, that means the programmer isn't very skilled. I'm sure almost every algorithm can be optimized for special cases. When a skilled programmer implements it, it will be significantly faster than STL's general algorithms.Quote:
I've not tested std::copy, but I know STL algorithms such as std::transform(), std::for_each(), etc. are invariably faster than hand-written loops.
However most of time we don't have to worry about optimization. Most performance improvement can be achieved by optimizing only 10% or even less amount of whole code. So they would save a lot of time by using STL.
"overwhelmingly complicated" means it's complicated for compiler, not for me.Quote:
Also, what is "overwhelmingly complicated" to you may be trivial to someone else. So "overlywhelmingly complicated" is highly subjective.
Are you talking that the second implementation is worse than the first one? No.Quote:
Then a C++ programmer would know to use a vector of some pointer or smart pointer type, not a vector of objects. Maybe they would use the vector of objects to get something working, but then switch to the (smart) pointer vector when finally optimizing the code.
In other words, there is no sense in timing things that no smart programmer would really ever do. If you were to time, say an array of smart pointers against a vector of smart pointers, then that is different.
At least the second implementation saves the programmer from having to use smart pointers. You don't have to waste space&time just to say "this isn't much useful", if you don't find anything bad.
And I forgot to mention one thing, the storage overhead. Suppose we need to int array of size 4, which is 16bytes. What will happen if we make it std::vector? Let's look at just Windows. The vector itself consumes at least 8 bytes (in MSVC2005, it's even 16 bytes but let's just forget about it), and since the buffer is allocated on the heap memory, another 16 bytes is consumed for block header. So it uses 40 bytes in total. It's absolutely abuse. So I'd recommend using built-in arrays if they can do the job.
Incidentally, from the Boost libraries work there is now std::tr1::array.Quote:
I've made a template class for static arrays which is essentially the same with C-style arrays except they are more convenient.
Yes, and I agree that it's a nice one. Just it would be a little better if it can copy-construct the elements directly, as std::vector does.Quote:
Originally Posted by laserlight
So what good is an application that just initializes? Also, a trivial array has to be initialized also, whether it is at the point where it is declared or some other part of the program.Quote:
Originally Posted by muse1987
Read item 43 ("Prefer algorithm calls to hand-written loops") from Scott Meyer's book "Effective STL".Quote:
Depending on the programmer's skills. Nothing can be always good. If hand-written code is slower, that means the programmer isn't very skilled.
The reason why algorithms are used are maintainability, efficiency and correctness. Meyers lays out perfectly why algorithms are preferred over hand-written loops. I suggest you read his book before making claims of programmers not being very skilled, and the argument that compilers cannot optimize algorithms. I won't even discuss the maintainability and reusability factor.
I don't know whether you've taken compiler theory, but what usually cannot be optimized is code that overly uses pointers and pointer aliasing, which is almost always the case with a programmer trying to be smarter than the compiler. Using algorithms and functors is what makes a compiler able to optimize code (by inlining, and again discussed by Meyers). So using algroithms gives the code a much better chance of being optimized than hand written loops.Quote:
"overwhelmingly complicated" means it's complicated for compiler, not for me.
Then the maintainability factor comes into play (discussed briefly here, even though I stated previously I won't discuss it).
Other programmers may have to maintain all of that tricky coding that attempts to be smarter than the compiler's optimizer. Using standard algorithms allows other programmers to understand immediately what the code is supposed to be doing, leading to less bugs, less downtime, and more time to develop other parts of the application. If you're coding alone, then these factors may not matter to you, but it sure does matter when working on a project with multiple programmers, where the deliverable must be done in a certain time, have few if any bugs, and is maintainable and scalable.
As a matter of fact, everywhere I've worked, the project leaders would reject any code that is "home-made" if it's attempt is to mimic what an STL container or algorithm is supposed to accomplish.
Then just declare an array of 4 items.Quote:
And I forgot to mention one thing, the storage overhead. Suppose we need to int array of size 4,
And there is a point where an array of n items creates a larger than necessary footprint for an object,Quote:
It's absolutely abuse. So I'd recommend using built-in arrays if they can do the job.
Which foo is smaller in size? There is a point where using regular arrays are efficient. However those cases are small compared to the number of real world cases where the array must either be larger than 100 items, or that the array must be dynamic.Code:class foo
{
int array[400];
// other members
};
//...
class foo
{
std::vector<int> array
public:
foo() : array(400) { }
};
Regards,
Paul McKenzie
I fully agree with that.Quote:
Read item 43 ("Prefer algorithm calls to hand-written loops") from Scott Meyer's book "Effective STL".
The reason why algorithms are used are maintainability, efficiency and correctness. Meyers lays out perfectly why algorithms are preferred over hand-written loops. I suggest you read his book before making claims of programmers not being very skilled, and the argument that compilers cannot optimize algorithms. I won't even discuss the maintainability and reusability factor.
I read the chapter and was convinced. My first thought nowadays when iterating through data is, 'can I use an algorithm and functor to do this?'. Updating old code has often reduced a dozen lines of code to a single algorithm call.
Trivial arrays don't use the expensive heap memory.Quote:
Originally Posted by Paul McKenzie
What I mean is hand-written codes can exploit extra informations for that specific case to optimize. I've experienced a lot of those cases. Most of time I ignore it just because it doesn't have much impact. However, if it's performance-critical portion, I write the loop myself and optimize it using those informations. I'm pretty sure that you would have seen people programming inner loops in assembly language.Quote:
Read item 43 ("Prefer algorithm calls to hand-written loops") from Scott Meyer's book "Effective STL".
The reason why algorithms are used are maintainability, efficiency and correctness. Meyers lays out perfectly why algorithms are preferred over hand-written loops. I suggest you read his book before making claims of programmers not being very skilled, and the argument that compilers cannot optimize algorithms. I won't even discuss the maintainability and reusability factor.
In theroy, yes. But in practice, no. You can find it by disassembling this code.Quote:
Using algorithms and functors is what makes a compiler able to optimize code (by inlining, and again discussed by Meyers). So using algroithms gives the code a much better chance of being optimized than hand written loops.
This is the code generated by MSVC2005 (/O2 with #define _SECURE_SCL 0). I'd happy to see C++ compiler which is significantly better than Visual C++.Code:int a[10] = {0};
std::vector<int> b( a, a+10 );
Code:00401046 mov eax,dword ptr [esp-3Ch]
0040104A sub esp,3Ch
0040104D push esi
0040104E push eax
0040104F lea ecx,[esp+0Ch]
00401053 push ecx
00401054 lea ecx,[esp+48h]
00401058 lea edx,[esp+20h]
0040105C call std::vector<int,std::allocator<int> >::_Construct<int *> (401150h)
00401150 push ebp
00401151 mov ebp,esp
00401153 push 0FFFFFFFFh
00401155 push offset __ehhandler$??$_Construct@PAH@?$vector@HV?$allocator@H@std@@@std@@QAEXPAH0Uinput_iterator_tag@1@@Z (402090h)
0040115A mov eax,dword ptr fs:[00000000h]
00401160 push eax
00401161 push ecx
00401162 push ebx
00401163 push esi
00401164 push edi
00401165 mov eax,dword ptr [___security_cookie (404018h)]
0040116A xor eax,ebp
0040116C push eax
0040116D lea eax,[ebp-0Ch]
00401170 mov dword ptr fs:[00000000h],eax
00401176 mov dword ptr [ebp-10h],esp
00401179 mov esi,dword ptr [ebp+8]
0040117C xor eax,eax
0040117E push eax
0040117F push esi
00401180 mov dword ptr [esi+4],eax
00401183 mov dword ptr [esi+8],eax
00401186 mov dword ptr [esi+0Ch],eax
00401189 mov dword ptr [ebp-4],eax
0040118C mov eax,dword ptr [ebp+8]
0040118F push eax
00401190 push ecx
00401191 push edx
00401192 call std::vector<int,std::allocator<int> >::_Insert<int *> (4012F0h)
00401197 mov ecx,dword ptr [ebp-0Ch]
0040119A mov dword ptr fs:[0],ecx
004011A1 pop ecx
004011A2 pop edi
004011A3 pop esi
004011A4 pop ebx
004011A5 mov esp,ebp
004011A7 pop ebp
004011A8 ret 8
004011AB mov esi,dword ptr [ebp+8]
004011AE call std::vector<int,std::allocator<int> >::_Tidy (4010B0h)
004011B3 xor eax,eax
004011B5 push eax
004011B6 push eax
004011B7 call _CxxThrowException (402026h)
--- and much more. Too much to extract all of them
Absolutely the first one. Unless you change the constructor of second class, and if what you're considering is real memory usage rather than sizeof (foo).Quote:
Which foo() is smaller in size?Code:class foo
{
int array[400];
// other members
};
//...
class foo
{
std::vector<int> array
public:
foo() : array(400) { }
};
That's enough. Because I'm not talking about other cases. I think "... if they can do the job" is telling that point.Quote:
There is a point where using regular arrays are efficient.
And in your example, if that class isn't allocated inside most-inner loop, definitely I'll use std::vector. However, when the performance becomes the first concern, I'd rather write
Code:class foo
{
// other members
void* operator new( size_t, int Length );
void operator delete( void*, int );
void operator delete( void* );
int array[1];
};