QuoteOriginally posted by: demhaQuoteOriginally posted by: CuchulainnI tested it on VS2010 in Windows. For other tests malloc and new were similar and pool was about twice as fast. I have not done extensive tests but some counterexamples are enough to show what I wanted to prove at this moment.The interaction of stack and heap makes it interesting.I use this idea QuoteIn most practical applications I've seen, (on reputable OSes ), tuning the allocator is way down the performance priority list. Embedded?For near real time apps, the allocator is quite prominent and makes a big difference. So, whenever I've had to do custom memory management, it has been for those kind of apps. Have you tried the Hoard allocator (http://www.hoard.org/?gclid=CN6bmYf2-qcCFcJP4Qod1G_VqQ). Used to have a good reputation for multithreaded apps.That looks like a good product. I was in 'sequential mode' allocators but I suppose the big issue is for multi-threaded code and avoiding performance problems.BTW, the buddy algorithm was invented by Harry Markowitz, the Economics Nobel prize winner. It would be nice just to be able to say vector<double, hoardAlloc> myvec;

QuoteOriginally posted by: renormConst-correctness is very important, especially in multi-threaded world. C++ and Java seem to use different approach. I came across this while browsing stackoverflow. This DrDobbs article was referenced in one of the answers.And here is the quiz (or open ended discussion if you like it that way).Compare and contrast C++ const strings, including C-string literals, and immutable strings in Java. Do you think DrDobbs article is trying to solve Java-problem in C++, i.e. Mad COW disease is a problem only if you try to code Java in C++.Everyone is welcome to chip-in their $.02.Personally I don't think const-ness has much to do with thread safety. Const member variable is a good thing because conceptually we do have constant numbers, "lables" etc in reality. But const member function is completely an over-commitment to the user. Practical inconvenience that is caused by const member function (and various associated hacks, including mutable) probably far out-weights its perceived technical elegance. In this regards, I am all for Java/.NET's design decision to discard the concept of const member function.Regarding string, it's a half-way between a simple data type (which typically is a value type, such as double) and a full-scaled data class (which typically is a reference type). For simple value type, we usually do not need to worry about thread safety because they are not shared (i.e. every holder gets its own copy). But for reference type, we have to worry about thread safety because the same instance may be held by multiple parties. Now for string, we conceptually tend to think it's a simple data type, though technically (for efficiency) this is a reference type. Therefore I tend to think "copy-upon-modification" may be practically the simplest design in such scenario.

QuotePersonally I don't think const-ness has much to do with thread safety. Const member variable is a good thing because conceptually we do have constant numbers, "lables" etc in reality. But const member function is completely an over-commitment to the user. Practical inconvenience that is caused by const member function (and various associated hacks, including mutable) probably far out-weights its perceived technical elegance. In this regards, I am all for Java/.NET's design decision to discard the concept of const member function. Declaring a member function const is a promise not to modify object's state. Declaring state variables as mutable so that they can be modified by const member functions is an improper use of mutable. If a member function needs to modify object's state than it shouldn't be declared const. Mutable is meant to be applied only to scratch variables, such as temp buffers, data cache etc. Practical inconvenience that is caused by const member functions is due to declaring non-const state-modifying functions as const. Making every member function which doesn't modify object's state const is good programming style. It is the principle of least privileges in action.C++ const is meant to protect against Murphy, not Machiavelli. PPL and TBB parallel patterns require function objects (or tasks) with const call operator. If a member function is truly const, e.a. we are not dealing with Machiavelli, then each thread can get its own local copy and call const member functions without synchronisation. C++ doesn't use garbage collector and the ability to copy tasks simplifies object lifetime management and improves locality. Anyway, passing tasks by reference (Java/C# style) isn't very useful, since only bitwise constant objects can be used without synchronisation. Copied tasks don't have to be bitwise const, because all internal scratch variables are duplicated for each thread. But all copies must provide const member functions which threads can call to do the actual work.On the contrary, const data members in C++ are not very useful. Objects with const members are not assignable, because the assignment operator must respect data field constness. I wish the assignment operator didn't care about data field constness. Data field constness is implementation detail, whereas the assignment is public interface. Assignment is like erasing the old object and replacing it with new one.

Quote I am all for Java/.NET's design decision to discard the concept of const member function.I think this was not a design intent with Java in the first place! They did not discard it AFAIK but it was never included in the first place (also no operator overloading not generics). Sorry, so taking Java as baseline is not the strongest argument. A close analogy would be Ada, which is bullt-prooof.If done right, then const works fine and it should be used. If code is badly designed then you get big problems with const, but const is not the culprit but the user code.IMO, No const in C++ code <==> shaky code. QuoteConst member variable is a good thing because conceptually we do have constant numbersNot sure where this would be useful. I think it is a sign of unmaintable code. Is this const object shared by other objects?? It's just another magic number and this makes code less useful.

I think const fields make objects less flexible, at least in C++. Objects with const members can't be duplicated with assignment. It is like after X=Y, X are Y. are not equivalent. But const (non-mutating) member functions are very useful. Btw, passing non-const function objects to STL algos is undefined behaviour. PPL and TBB enforce constness at compile time.

QuoteOriginally posted by: renormI think const fields make objects less flexible, at least in C++. Objects with const members can't be duplicated with assignment. It is like after X=Y, X are Y. are not equivalent. But const (non-mutating) member functions are very useful. Btw, passing non-const function objects to STL algos is undefined behaviour. PPL and TBB enforce constness at compile time.Sounds like good practice to me. Less chance of nasty side effects.

QuoteOriginally posted by: renormI think const fields make objects less flexible, at least in C++. Objects with const members can't be duplicated with assignment. It is like after X=Y, X are Y. are not equivalent. But const (non-mutating) member functions are very useful. Btw, passing non-const function objects to STL algos is undefined behaviour. PPL and TBB enforce constness at compile time.STL algos are part of the (impure) functional paradigm, so that's not a surprise. C++, one way or another, allows imperative, OO, functional and God knows how many other potential ways to program. Truly, a programmer's heaven or hell!

Member function is an interface contract. Therefore we have to ask ourselves what guarantee the caller can get from a const function declaration? In a multi-thread world, two consecutive calls to the same const function may return completely different results because another thread may sneak in between and change something. Even during the same call, the callee's states may still get changed because of another thread. So what does "const-ness" mean to the caller?Furthermore, an interface contract just needs to tell the caller what service it provides, not how the service will be provided. An object's internal state is its own business, i.e. encapsulation. I agree that a class' internal members can be classified as regular and scratch (i.e. mutable). But they both should be internal and invisible to the outside world. So why we want to promise others one member function will not change some (regular) members and may change some (mutable) members? Again, why the caller needs to know this and what tangible benefit the caller can get by knowing this?If declaring const-ness member function is about self-discipline, keep it to ourselves and don't make over-commitment to others. This is what const member variable does. Declaring a member variable const is simply a reminder to us that we plan to only use this member variable but not manipulate it.

QuoteOriginally posted by: CuchulainnI think this was not a design intent with Java in the first place! They did not discard it AFAIK but it was never included in the first place (also no operator overloading not generics).To me, it's quite useful and help to compare the features of different languages. And honestly I trust those Java and .NET designer are very experienced and must have spent lots of thinking when deciding which feature to drop and to add. Features like generic has built-in conflict with language execution security (which is very important to Java and .NET in the internet age). But for features like const member function and operator overloading, I don't see any strict show stops that prevent them from being included. So I would guess they are purposely excluded.QuoteOriginally posted by: CuchulainnIMO, No const in C++ code <==> shaky code. Are you saying all Java/.NET applications are shaky because they do not support const member function?

QuoteOriginally posted by: CuchulainnIMO, No const in C++ code <==> shaky code. QuoteAre you saying all Java/.NET applications are shaky because they do not support const member function? I suppose C++ is more dangerous than C# because you can use references, pointers and values and tune them as needed. Do you not miss them in C#? QuoteFeatures like generic has built-in conflict with language execution security (which is very important to Java and .NET in the internet ageIs this an apoology?

QuoteMember function is an interface contract. Therefore we have to ask ourselves what guarantee the caller can get from a const function declaration? In a multi-thread world, two consecutive calls to the same const function may return completely different results because another thread may sneak in between and change something. Even during the same call, the callee's states may still get changed because of another thread. So what does "const-ness" mean to the caller?That is why function objects are copied by PPL/TBB parallel patterns. Each thread get's it is own local copy. Two or more threads won't use the same copy. Constness guarantees that all copies behave identically just like the original, regardless of how many copies are created or in what order the copes are created. It is like a meter stick - we don't care when and where it was manufactured as long as it is equivalent to the master copy.QuoteFurthermore, an interface contract just needs to tell the caller what service it provides, not how the service will be provided. An object's internal state is its own business, i.e. encapsulation. I agree that a class' internal members can be classified as regular and scratch (i.e. mutable). But they both should be internal and invisible to the outside world. So why we want to promise others one member function will not change some (regular) members and may change some (mutable) members? Again, why the caller needs to know this and what tangible benefit the caller can get by knowing this?Constness is part of the interface. It tells the caller that the outcome depends only on the value of supplied arguments, not on the argument values used in previous calls or how many times the object was copied or used. Generating random bits from RNGs shouldn't be const, but Inverse CDF can be and should be provided by a const member function. It is not OK to pass RNGs to PPL/TBB parallel patters (at least not without explicit synchronization and/or copy control), but Inverse CDF can be duplicated so that each thread can use its own copy without synchronization. Mutable variables are rather obscure C++ feature. They are meant to store scratch data only (e.g. for performance purposes). The outcome of function calls shouldn't depend on scratch data. Mutable variables should be completely invisible to to the caller.QuoteIf declaring const-ness member function is about self-discipline, keep it to ourselves and don't make over-commitment to others. This is what const member variable does. Declaring a member variable const is simply a reminder to us that we plan to only use this member variable but not manipulate it.It is not about self-discipline only. Constness is type property and checked at compile time. It will prevent us from passing RNGs to PPL/TBB. Again, it is the protection against Murphy, not Machiavelli.QuoteTo me, it's quite useful and help to compare the features of different languages. And honestly I trust those Java and .NET designer are very experienced and must have spent lots of thinking when deciding which feature to drop and to add. Features like generic has built-in conflict with language execution security (which is very important to Java and .NET in the internet age). But for features like const member function and operator overloading, I don't see any strict show stops that prevent them from being included. So I would guess they are purposely excluded.Java (and .Net as well) design was an incremental process (just like anything else that big and complex). The way Java used today isn't necessarily the same as it was initially intended. Java was meant to be something intermediate between C++ and scripting languages: less fine grained control than C/C++ but still compiled and static/strongly typed. But over time Java moved closer to C++ and further from the languages used for rapid development (flash, python, etc). Const member functions isn't something rapid development should bother with, so Java didn't support them. But constness isn't backward compatible. Can't go back and make something const if it already being used in many places.

QuoteI suppose C++ is more dangerous than C# because you can use references, pointers and values and tune them as needed.In C# (and Java as well) all objects are handles by reference. It is like using only pointers in C++, but with automatic cleanup. With pointers constness becomes somewhat tricky. You can have const pointers, pointers to const and const pointers to const. Maybe Java designers thought that it is too confusing and too low level? Then C# followed the suite, since C# has its roots in Java.

QuoteOriginally posted by: renormQuoteI suppose C++ is more dangerous than C# because you can use references, pointers and values and tune them as needed.In C# (and Java as well) all objects are handles by reference. It is like using only pointers in C++, but with automatic cleanup. With pointers constness becomes somewhat tricky. You can have const pointers, pointers to const and const pointers to const. Maybe Java designers thought that it is too confusing and too low level? Then C# followed the suite, since C# has its roots in Java.If my memory serves me, Java was originally developed for applets, so do you want to annoy web developers with low-level syntax?Generics are an afterthought, and it seems they are just a wrapper for Object?? C++ is a multi-paradigm language; it is powerful (and dangerous),

QuoteOriginally posted by: CuchulainnIf my memory serves me, Java was originally developed for applets, so do you want to annoy web developers with low-level syntax?Generics are an afterthought, and it seems they are just a wrapper for Object?? That's not entirely true. Gosling and his group invented Java for devices (phones and such). It laid in obscurity like many great ideas until some clever dick discovered applets. It's only now that Java is really being used for its original purpose, i.e. in devices and to a lesser extent for realtime applications (yes, Realtime Java). Generics are an afterthought, but most of its idiosyncracy comes from having to remain backward compatible with the original Collections framework (see how painful C++ becomes when it has to bend backwards to remain compatible with C). Generics provide strong typing to Java Collections which were an anomaly in a strongly typed language.

QuoteThat's not entirely true. Gosling and his group invented Java for devices (phones and such). It laid in obscurity like many great ideas until some clever dick discovered applets. It's only now that Java is really being used for its original purpose, i.e. in devices and to a lesser extent for realtime applications (yes, Realtime Java). Those Java sales guys have a lot to answer for