Heap efficiency?

[_uj]

But (Again to the best of my understanding), have done ZERO quantitaive measurements to support this. IF I believe that variables should never have the letter O in them, with absolutely no quantitative evidence to support this position. I dont see a difference.

As I've told you several times, I don't use "look at me" argumentation. I just don't think personal results are valid evidence. Instead I stick with qualitative arguments and peer reviewed results. And of that I've posted plenty in support of my argumentation. Maybe you should do the same.

Very very simple. As soon as you replace the default allocator, you take on the full responsibility of testing EVERY piece of code that uses that allocator.

Not necessarily so if the provider of the default allocator and the replacement allocator is the same. As you may know Intel offers a popular C++ compiler. Intel also offers a replacement allocator as part of its TBB library. I'm sure Intel takes as much responsibility for the TBB allocator as it does for the standard allocator it ships with the compiler.

Having said that I realize that the most common situation may be that the replacement allocator doesn't come from the compiler provider. In that case there may be the implications you suggest but only if I've developed the allocator myself. Otherwise - no.

You have somehow arrived at the conclussion that original parts must always be better than third-party parts. This is a dire proposition for two reasons. Firstly it just isn't true. Third-party parts are likely to have been developed to the same high standard as the originals, if not even higher for the simple reason that otherwise they wouldn't sell. And secondly, it may give you a false sense of security. When an original part you unconditionally trust does fail you may be standing with your pants down because you didn't plan for what you thought could never happen.

So the secure world you've built yourself with original parts is nothing but an illusion. Cozy to be in but potentially dangerous if it makes you exclude the unexpected from your product testing.

[TheCPUWizard]

As I've told you several times, I don't use "look at me" argumentation. I just don't think personal results are valid evidence. Instead I stick with qualitative arguments and peer reviewed results. And of that I've posted plenty in support of my argumentation. Maybe you should do the same..

I did, but you seem content to ignore Reply #37.

[Speedo]

Instead I stick with qualitative arguments and peer reviewed results. And of that I've posted plenty in support of my argumentation.

Your argument is a classic non sequitur.

Your source says one thing ("it is sometimes beneficial to use a custom allocator"), but you interpret something completely different from it ("for serious OO programming to be feasible in C++ the standard memory allocator must be replaced with something more efficient. The standard allocator sucks and is likely to be a major bottleneck") and then argue as if your interpretation is fact.

[_uj]

I did, but you seem content to ignore Reply #37.

I didn't ignore it, I wrote it.

And look who's talking. How come you dodged the seconds part of my post #46? Yes that's right. That's where I rip apart your pet argument about not replacing the standard allocator.

[ahoodin]

Oh will the real slim shady please stand up?

This thread is garbage!

[_uj]

Your argument is a classic non sequitur.

Your source says one thing ("it is sometimes beneficial to use a custom allocator"), but you interpret something completely different from it ("for serious OO programming to be feasible in C++ the standard memory allocator must be replaced with something more efficient. The standard allocator sucks and is likely to be a major bottleneck") and then argue as if your interpretation is fact.

Mine is a derived conclussion, not an exact quote from some authoritative source. And the formulation is deliberately somewhat provocative which I think is okay in a discussion forum. It's not like I'm writing an article or a thesis or something.

By the way which source are you referring to? If it's Alexandrescu's book there are much stronger quotes in support of my view. See my post #32 for example.

[ahoodin]

No this bickering has turned a good thread into garbage. It is a shame that as the OP that you don't realize that it ruined the thread. Not that it really is "Your" thread because everybody who contributed also owns the thread. Good threads get published in a CG book every once in a while. That book is given away or sold at times. I don't think there is any chance of that ever happening, especially with the tone of the thread and the manners exhibited here. Why should a CG moderator have to fix what would have been a perfect thread for a book such as that? So in your honest opinion would you publish a thread where some of the contributors clown a Microsoft MVP?

[TheCPUWizard]

I did, but you seem content to ignore Reply #37.

I made a typo in shortening the post.

MY comments were in Reply #36, and the original question was why you were ignoring those issues (concerete examples, in detail, by the most recognized vendor, that supports replacing the allocator on SPEICIFC classes) in your reply #37 and thereafter....

Sorry if this was too confusing....

[_uj]

No this bickering has turned a good thread into garbage. It is a shame that as the OP that you don't realize that it ruined the thread. Not that it really is "Your" thread because everybody who contributed also owns the thread. Good threads get published in a CG book every once in a while. That book is given away or sold at times. I don't think there is any chance of that ever happening, especially with the tone of the thread and the manners exhibited here. Why should a CG moderator have to fix what would have been a perfect thread for a book such as that? So in your honest opinion would you publish a thread where some of the contributors clown a Microsoft MVP?

I drive a hard bargain and if the proverbial emperor has no clothes on he can rest assure I'm going to point it out. I make no special provisions for rank or seniority or previous accomplishments. Nobody is better than their last argument. I try to produce good and sharp arguments in a style that's interesting and to the point, even provokative. If I feel someone is being pompous or overly stupid then this will be reflected in my reply. I know I sometimes overdo it but then I'm willing to rephrase, which I've done in this thread.

You may consider my posting style bickery but I know it's very effective in engaging people. If this thread has become interesting its very much thanks to my "bickering". Your whining on the other hand does exactly the opposite. It's when the mediocre with nothing of importance to say come in and start reviewing form and style instead of contributing to the topic the thread dies of starvation. If you want this thread in that CG book - keep out!

[cj-wijtmans]

Maybe this is not entirely on-topic.
But however i just thought of one logical issue with the default allocator, you may correct me if im wrong.
The default allocator allocates an extra capacity to avoid reallocations, since this process takes alot of time.
But when its allocating capacity, and new[] is used, its constructing objects beyond the size() boundry. Meaning it constructed more objects than the actual size of the container.

Major logical error. now if placement new is called i see a major speed increase, and a logical error fix. Now if you can prove me wrong and there will be a speed decrease in ANY case, give me the numbers and i will believe it.

Now im to stupid to understand about the shared/referenced objects? I havent meet any situation where i needed them yet. But i geuss object on the heap or alot slower than on the stack. I wonder if it will ever be possible in C++ to have dynamic allocation on the stack, its good for strings and lookup tables, it could improve performance byalot..

Sorry for going a bit off-topic, i just dont understand the entire thread.

[laserlight]

But however i just thought of one logical issue with the default allocator, you may correct me if im wrong.
The default allocator allocates an extra capacity to avoid reallocations, since this process takes alot of time.
But when its allocating capacity, and new[] is used, its constructing objects beyond the size() boundry. Meaning it constructed more objects than the actual size of the container.

Major logical error. now if placement new is called i see a major speed increase, and a logical error fix. Now if you can prove me wrong and there will be a speed decrease in ANY case, give me the numbers and i will believe it.

I believe the allocator hides the magic of placement new, so there is no "logical error" in the first place.

EDIT:
I do not think that there is a need to show you any numbers though: just ask yourself why convenience functions like std::uninitialized_copy and std::uninitialized_fill exist, why there are member functions named construct and destroy for std::allocator, or why the C++ Standard explicitly states that the default allocator's allocate member function uses the global operator new.

[cj-wijtmans]

I believe the allocator hides the magic of placement new, so there is no "logical error" in the first place.

your saying it does not construct objects beyond size()?

EDIT:
I do not think that there is a need to show you any numbers though: just ask yourself why convenience functions like std::uninitialized_copy and std::uninitialized_fill exist, why there are member functions named construct and destroy for std::allocator, or why the C++ Standard explicitly states that the default allocator's allocate member function uses the global operator new.

i have no idea? can you be more specific

[laserlight]

your saying it does not construct objects beyond size()?

No, I am saying that allocators just provides an interface for allocating space and constructing objects (and thus hides the use of placement new). This allows say, an implementation of std::vector to avoid constructing objects beyond the size despite over-allocating for the capacity.

[TheCPUWizard]

No, I am saying that allocators just provides an interface for allocating space and constructing objects (and thus hides the use of placement new).

Placement new does not do ANY allocation, and has no bearing on the allocator what so ever. It is use to "place" objects at memory spaces that are allready "allocated" or do not need allocation.

[laserlight]

Placement new does not do ANY allocation, and has no bearing on the allocator what so ever. It is use to "place" objects at memory spaces that are allready "allocated" or do not need allocation.

Yes, but how does that conflict with what I stated? My understanding is that placement new is used in the standard allocator's construct member function.