Re: why still use C?
From: cody (dont.spam.me.deutronium_at_gmx.de)
Date: 10/06/03
- Next message: j: "Re: int (*daytab)[13] vs int *daytab[13]"
- Previous message: Jimmy: "Re: [OT] Setting Time in C"
- In reply to: Sidney Cadot: "Re: why still use C?"
- Next in thread: Sidney Cadot: "Re: why still use C?"
- Reply: Sidney Cadot: "Re: why still use C?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 6 Oct 2003 14:23:23 +0200
> Inheritance and polymorphism have an important part to play as well,
> especially in some areas of application (such as GUIs).
>
> However, this is the first place where you get a tradeoff of execution
> speed, executable size, and runtime memory usage (for virtual method
> tables) versus design-time advantages. In reality of course, especially
> with nowadays' big machines, these disadvantages are not too important
> for most applications. However, (to me at least) it is a bit unnerving
> to be at the mercy of the compiler and its designer, and hope that he
> implemented all this machinery properly and without causing too much
> overhead. This is more a psychological barrier than a real one of
that is really true!
> course, since modern compilers are able to optimize away many
> unneccessary machinery, and some rather clever tricks have been found to
> make virtual method calls very cheap. However, as a programmer I am no
> longer completely in the driver's seat as I am with C. Looking at a C
> porgram, I can have a straightforward and relatively accurate mental
> picture of what the actual machine code produced by the compiler will
> look like. With OOP and C++, that's no longer true, especially with code
> that uses all the available C++ features including exceptions and
templates.
>
> One generic complaint I have with OOP (not limited to C++) is that I can
> no longer look at a code fragment and reconstruct the execution flow in
> my head, because of polymorphism and operator overloading;
yes, operator overloading is one of the most the most sucking thing in c++!
> As for exceptions, you may know Dijkstra's paper "Goto's considered
> harmful". In this paper he has a number of points that I would subscribe
> to, concerning the ability of the human programmer to read the meaning
> of a piece of code from the source. In essence, he argues that GOTO
> statements destroy this possibility.
>
> I would argue that exceptions are "goto's on steroids". Since exceptions
> are allowed to cross function-call boundaries, execution flow becomes
> very non-transparant - at least to me!
where the exception goes is well defined, it cannot go somewhere, it goes
simply
down the callstack which is more readable than gotos, imo.
but doesn't c support structured exception handling too? i heard something
like that.
> It's a minefield.
absolutely.
> Templates.... Suffice it to say that one cannot write a portable C++
> program using templates and expect it to work identically on different
> compilers. Portability is nil, and this makes this feature not useful in
> many practical sutuations. One can complain about (or to) compiler
> builders in this regard, but this is just a symptom of overly
> complicated semantics.
that is not true. name me one example where semantics are different on
different compilers!
templates are a very very useful and mighty feature in c++. however it is a
bit difficult to use.
> To summarize I would say C++ with its feature set is just too
> complicated, as a language design I feel it has failed. One has to keep
> in mind that a programming language is a tool to make programs. If a
> tool has a significant chance of being unintentially misused (with
> possibly disastrous results), it's not a good tool. I will stick with
> something I actually (more or less) understand, which is C.
yes and no. c++ should not be used for everything. gui's should not be made
with c++.
for libraries, c++ is good because it is very fast and flexible thanks to
templates.
you say the language design has failed, but do you have a better idea how it
can be solved?
imo for high performance applications there is no better way than c++. since
c lacks of templates,
c++ would be the choice for me.
> By the way, did you ever read the Stroustrup book ('Programming in
> C++')? As the book progresses, his examples evolve from things that look
> sort-of-like-C to STL-based programs that are (to my untrained eye at
> least) simply ugly. My feeling is that he tries to bring the expressive
> power of dynamic interpreted languages to the realm of compiled
> languages. A valliant attempt, and I would applaud him for it. However,
> his writing conveys a breathtaking arrogance or perhaps lack of
> understanding for the fact that most programmers are mere mortals... I'm
> sure as the language's designer he is able to mentally internalize the
> runtime model of C++, but to think that your average programmer could
> readily do the same is just preposterous.
right i cannot imagegine that somebody really and completely understands the
STL.
-- cody [Freeware, Games and Humor] www.deutronium.de.vu || www.deutronium.tk
- Next message: j: "Re: int (*daytab)[13] vs int *daytab[13]"
- Previous message: Jimmy: "Re: [OT] Setting Time in C"
- In reply to: Sidney Cadot: "Re: why still use C?"
- Next in thread: Sidney Cadot: "Re: why still use C?"
- Reply: Sidney Cadot: "Re: why still use C?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
