On 21 Feb, 19:22, Nicola Musatti <[EMAIL PROTECTED]> wrote: > On Feb 21, 6:31 pm, Paul Boddie <[EMAIL PROTECTED]> wrote: > [...] > > > The main reason why C++ has declined in usage is because almost > > everything of practical value is optional. > > The main reason why C++ has declined in usage is because it never got > the kind of corporate marketing enjoyed by Java and C#.
What? C++ was practically the favoured language for serious applications development on the win32 platform for a good decade. It was all about Visual C++/Studio until Microsoft dabbled with J++, got sued and eventually came up with C# (and Managed C++). You can't really ask for a more influential patron than Microsoft. [...] > > Back to those C++ newbies, then. Of course, none of them pushed into a > > C++ project is going to have much say about which memory management > > "best practice" is going to be used - the decisions are already set in > > stone by the project - and so it's all about coping with the tedious > > tracking of "who owns which pointer" and hoping that different > > libraries don't have different policies. Taking the quotes out of > > order... > > Sorry, but although this was probably true in the early 90's that's > not the way it goes in practice nowadays, thanks to automatic > variables, destructors, the standard library containers and smart > pointers. Yes, but support for a lot of this stuff usually lags behind the best practices, so there are usually the tools that actually do attempt to provide this stuff, then there are the tools which people have to use (such as Visual Studio) and which don't work satisfactorily, although I'll admit that the situation was improving (on the Free Software side, at least) when I last had anything to do with C++ in a project. Sadly, it took most of the 1990s for widespread support for several key C++ features to become available. The joke always used to be about templates and exceptions, but I've had pages full of bizarre errors from libraries like Boost more recently than the 1990s. And I've seen plenty of libraries this century which probably don't follow the best practices, possibly because the people involved have no faith in the language implementations. [...] > It's not just a matter of memory consumption patterns, it's also a > question of explicitly resetting your memory references to ensure that > the GC can reclaim them. This can be less than obvious when complex > data structures and/or callback objects are involved. As I said, the caveats are fewer, but there are caveats involved, yes. Paul -- http://mail.python.org/mailman/listinfo/python-list
