Re: Language flame wars are moot

From: Jeremy J (arketype_at_myrealbox.com)
Date: 11/08/04 

Date: 7 Nov 2004 21:53:50 -0800

All good points.

> 1. The standard library came to late.
> Most windows libraries and the like use their own collection
> hierarchies.
> It is not unusual for a application to use two or even three different
> collection libraries.
> They are mutually incompatible and conversion and the like wastes size,
> speed and time.
> Also they handle allocation differently.

I feel your pain. Standardization was a real train wreck for C++. I
wish to emphasize that C++ should be applied to particular problems
only after determining if the language AND libraries provide
sufficient support. I refuse to write GUI code in C++ because I have
found Objective-C to provide superior support for GUI's on my platform
of choice. Likewise I refuse to write math heavy code in Objective-C
because the STL provides superior support for vectors, matrices,
complex number and a host of other types.

> 2. It is difficult to write secure code in C++.
> Many C library functions use unsafe practises and this is
> not always documented. The classic example is gets but there
> are plenty of others.
> Again finding and plugging these holes is time consuming.

This was once very true, but now less so. Buffer overflows and the
such are beasts of the past for C++ as the standard libs remove NEARLY
ALL need to manipulate raw memory.

> 3. There are big difference between the level of support for C++ among
> compilers.
> In particular templates, exceptions and name-spaces can cause troubles.
> Porting is a slow and time consuming process.

Guilty as charged. I guess I am lucky that I don't have to support old
compilers :)

> I can't see that developing in C++ is faster, cleaner and more reliable
> than most other languages.
> Again much of the software quality depends on the programmer more than the
> language.

I did not say that DEVELOPING is cleaner or faster, but the resulting
programs can be.
Let me be explicit. C++ is HARD. It is not for most desktop
applications. Don't use it unless you know what you are doing. But if
you do know what you are doing then you can write very well defined
programs that run FAST.

> The methodology helps, but again, this is not a feature of the language.

Exactly. C++ does not prescribe a particular methedology, which is
it's biggest strength and the source of so much misunderstanding. C++
is multi paradigm. It SUPPORTS object oriented programming, as well as
functional programming. It IS neither an object oriented language, nor
a functional one. Good methedology is better than all the language
features in the world, as a human can apply methedologies with
discrimination and flexibility, while a compiler lacks the judgement
to apply language features with any flexibility.

Please don't think that I am saying that C++ is the greatest language
ever. I doubt it is. For most desktop apps, it is rather silly. But so
many of the posts on the 'C++ sucks for games' thread come from a
position of ignorance, and I am trying to enlighten.

My real beef with the thread is that it does not define what people
mean by game programming. I for one am writing my graphics engine in
C++, Scenario Editor in Objective-C and network support in Java. These
are all very different activities.

Happy programming, in any language.
Jeremy J

Relevant Pages

  • Re: CL-UNIFICATION as a library (Re: Qi Seems Great)
    ... perhaps it is time for a new revision for the language? ... Common Lisp people looking down on everybody else, ... But I'm not new to programming - that's ... should find the CL implementation and set of libraries most suitable ...
    (comp.lang.lisp)
  • Re: C++ or Java ?
    ... programming styles, not just OOP. ... >> libraries and tools outweighs the benefit of having a more powerful ... pick a suitable set of libraries, and then see which language it's ... What is Python, precious? ...
    (comp.os.linux.development.apps)
  • Re: Conformance
    ... better than C for certain types of programming, and C is better than C++ ... You think that C will lose because it has far less features than C++. ... currently a superior language. ... libraries, some of which were last updated decades ago. ...
    (comp.std.c)
  • Re: RFC: C and concurrency (as CC extensions)
    ... I do see some places where concurrency can be ... As far as libraries go, obviously there is already support for ... If you are thinking about extending or breaking the language, ... common constructs in concurrent programming can be built out of others; ...
    (comp.lang.misc)
  • Re: why still use C?
    ... Actually there are several issues with Objective-C: ... there are several variations of language abilities. ... libraries or attempts at making Unix look and act like Next or MacOS ...
    (comp.lang.c)