Share a draft: (rewritten) Zero Initialisation for Classes

[Thomas Young]

Hi guys,

Finally got around to rewriting this one.

It's good I got some criticism about the previous draft, in fact, as that *was* pretty bad as originally posted, and so I'm happy to have rewritten this.
It's still not my best post, but useful as part of the vectors and vector based containers series.

Shared for the next six days, at: http://www.altdevblogaday.com/?p=30846&shareadraft=baba30846_533162eeec3f1
Additional feedback welcome!

Thomas

[Christian Schladetsch]

Hi Thomas,

I don't see the point of this post. You take a long-winded path, just to end up stating that you don't understand C++ or it's error messages, and offer no solution to an apparent non-problem?

To be clear: your 'problem' can be solved with a call to malloc(). Or just use an array on the stack. Or just manage the memory yourself.

Christian.

--
You received this message because you are subscribed to the Google Groups "AltDevAuthors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to altdevauthor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Thomas Young]

Hello Christian,

> To be clear: your 'problem' can be solved with a call to malloc(). Or just use an array on the stack. Or just manage the memory yourself.

This is not clear at all, actually.

The post is a follow up to a previous post about rolling your own vector container, and talks about zero initialisation overhead in placement new calls.

Yes, it is true that you can avoid zero initialisation overhead in placement new by allocating memory directly, but if you think that direct memory allocation has the same convenience and is no more prone to error than allocating buffers through a container mechanism like std::vector, then I guess this post is just not for you.

Regards

Thomas

[Joseph Simons]

I think it is a fun little experiment into seeing how the various ways that C++ does things behind the scenes myself. Certainly you can avoid a lot of this complexity (and there are very good cases to be made for this point), but I don't feel that makes the post worthless.

Only real points that I can make are that you have a broken link in "(Not yet, I will in my next post!)", and there are a few places in the code where it scrolls off the side of my screen, especially in the Type Specialization section, and I am unable to easily view it. Though not sure if that is more a problem with the site than anything. Couldn't hurt to make the code a little more vertical, however. Also you have a double-negative at the beginning of your conclusion ("is finally not an unavoidable issue for us") which I always find a little hard to read.

-Joseph-

[Christian Schladetsch]

Heya Thomas,

Controlling memory directly is better suited to a C/C++ style of programming. This doesn't necessarily mean using STL or being a language lawyer.

I do not see the point in jumping through hoops just to use STL vectors. As a past boost contributor, I understand that STL and boost practices are important.

In this case, a simple malloc would serve the purpose well - possibly followed by a memset. 

Especially since it is nominally per-frame. In this case, in a real time system, I think I covered this well enough with my monotonic allocator.

Regards,

Christian,

[Thomas Young]

Thanks Joseph, I made some changes to address these points.
(Currently updated on the original blog post but not on the shared draft.)

[Thomas Young]

Published.