QuoteOriginally posted by: CuchulainnQuoteThat'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 Indeed. Gosling's being hired by Google. Wonder what damage he'll do now

QuoteOriginally posted by: demhaQuoteOriginally posted by: CuchulainnQuoteThat'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 Indeed. Gosling's being hired by Google. Wonder what damage he'll do now Seriously, I got really fed up in the 90's by all these Java/C++ war stories. Good to see they don't happen on Wilmott.

QuoteConstness 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. I am not sure whether we are talking about the same thing. I refer to simple C++ const member function which says "this member function won't change any instance member variable (...well excluding mutable)"Interestingly, utility functions such as RNG (as well as CDF) will almost for sure be declared as const in C++ (if it belongs to a utility class, not as a standalone function). Conceptually wise, they are just static functions (because they usually do not require instance member variable). But static function and constant member function are two different concepts though.Just my 2 cents ... (per OP )

QuoteI am not sure whether we are talking about the same thing. I refer to simple C++ const member function which says "this member function won't change any instance member variable (...well excluding mutable)"That's correct. But 'const' is much broader than just this!

QuoteOriginally posted by: CuchulainnQuoteI am not sure whether we are talking about the same thing. I refer to simple C++ const member function which says "this member function won't change any instance member variable (...well excluding mutable)"That's correct. But 'const' is much broader than just this!Well, talking about computer programming, two fundamental pieces are data and actions on data (i.e. method/function). In the concept of OOP, they map to (member) variables (including msg etc) and member functions. In other computational domains (e.g. parallel, functional etc), they may be mapped to something else.My view is, in the context of OOP, const declaration on member function is meaningless. (@ Sun Apr 03, 11 07:33 PM)

QuoteOriginally posted by: zhouxingQuoteOriginally posted by: CuchulainnQuoteI am not sure whether we are talking about the same thing. I refer to simple C++ const member function which says "this member function won't change any instance member variable (...well excluding mutable)"That's correct. But 'const' is much broader than just this!Well, talking about computer programming, two fundamental pieces are data and actions on data (i.e. method/function). In the concept of OOP, they map to (member) variables (including msg etc) and member functions. In other computational domains (e.g. parallel, functional etc), they may be mapped to something else.My view is, in the context of OOP, const declaration on member function is meaningless. (@ Sun Apr 03, 11 07:33 PM)Sorry, I thought we were in C++, not OOP or general programming, based on the implicit assumption that neither Java nor C# know about the concept of 'const' in all its manifestations.Const in C++. objects. member functions. return types. const input argsand 2 extra levels: ptr and references.QuoteMy view is, in the context of OOP, const declaration on member function is meaningless.Since the late 80's these were called 'selectors' in OOP and are well-known. Unless I have completely misunderstood.

QuoteOriginally posted by: zhouxingTo 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.Well, a technical term for the result of "deciding which feature to drop and to add" is this one:"A language (such as Pascal, Ada, APL, or Prolog) that, though ostensibly general-purpose, is designed so as to enforce an author's theory of "right programming" even though said theory is demonstrably inadequate for systems hacking or even vanilla general-purpose programming. Often abbreviated "B&D"; thus, one may speak of things "having the B&D nature"."// http://foldoc.org/bondage-and-discipline+languageAlso, from C2 Wiki:"A language is B&D to the extent that its defenders exhibit AuthoritarianPersonality symptoms.Authors of BondageAndDisciplineLanguages believe their concepts of the Higher Principles of Computer Science should apply to how you say "Hello World".Clarification: BondageAndDiscipline is externally imposed, even if you're the one that begged for it to happen. Some of the discussion below still assumes "discipline" means "self-discipline", which confuses things. Bondage == "I'm not allowed to..." (restraint of behavior) Discipline = "I am forced to..." (forced behavior) Self-Discipline == "I better be careful to..." (abandon all hope, ye who enter here)"As in certain languages enforcing object-oriented programming paradigm on ALL (including but not limited to "Hello World"-type) programs... just sayin'

QuoteAs in certain languages enforcing object-oriented programming paradigm on ALL And these are called 'pure' OO language, connotation being that you are damned as developers if you do not program in this way. OOP is just one of the many programming paradigms out there.

QuoteAs in certain languages enforcing object-oriented programming paradigm on ALL And these are called 'pure' OO language, connotation being that you are damned as developers if you do not program in this way. OOP is just one of the many programming paradigms out there. It's not even the most useful one for numerical work.

QuoteOriginally 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.Another potentially interesting allocator implementation is jemalloc A couple of links:http://www.canonware.com/jemalloc/http: ... ry-usage/A couple of claims:"The main benefit is scalability in multi-processor and multi-threaded systems achieved, in part, by using multiple arenas. And it seems to have similar performance to current best algorithms for single threaded use.""[...] jemalloc gave us the smallest amount of fragmentation after running for a long period of time. [...] Our automated tests on Windows Vista showed a 22% drop in memory usage when we turned jemalloc on."Cuch, if you're still interested in this topic, would you be willing to re-run your test(s) including the above?I'm curious whether it turns out to be any good...

QuoteOriginally posted by: PolterQuoteOriginally 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.Another potentially interesting allocator implementation is jemalloc A couple of links:http://www.canonware.com/jemalloc/http: ... ry-usage/A couple of claims:"The main benefit is scalability in multi-processor and multi-threaded systems achieved, in part, by using multiple arenas. And it seems to have similar performance to current best algorithms for single threaded use.""[...] jemalloc gave us the smallest amount of fragmentation after running for a long period of time. [...] Our automated tests on Windows Vista showed a 22% drop in memory usage when we turned jemalloc on."Cuch, if you're still interested in this topic, would you be willing to re-run your test(s) including the above?I'm curious whether it turns out to be any good...Polter,I am very interested, still. What do suggest? One idea is to use these as the memory allocator in Memory Pool (btw any devs there in the pipeline?)An issue is: how usable and learnable are these environments? The less hassle with installing the better

Stack derived from vector QuoteThe Stack class represents a last-in-first-out (LIFO) stack of objects. It extends class Vector with five operations that allow a vector to be treated as a stack.