Re: C vs. C++

Kaz Kylheku wrote:
Complexity has to exist somewhere. If you banish it from the programming
language, you push it into the programs. It's not an exact conservation law,
because a given amount of complexity in one place may translate into vastly
more complexity if it is relocated to another place, due to duplication of
effort.


The problem is not the necessary complexity tied to the application
but the unnecessary complexity tied to the use of an obscure programming
language

That is unnecessary complexity that adds nothing to the program but bugs.

C++ can manage certain complexities that are otherwise difficult in C.

As a rule:

language simplicity => program complexity


No. It may mean that the programmer must develop some routines
that *could* be part of the C standard library but they aren't.

The problem with C is that all development has stopped and it
has become a dead language. I have been discussing this problem
in this group for years, together with the comp.std.c, where
I have been met with the ususal: "If you want C++ go there".

All developments in C (specially the update of the standard
library that is hopelessly OBSOLETE by now) are stopped by the
attitude of many C community members that see any development
as an attack to their baby.

This leads to the situation where nobody develops a higher
level library for C. Then, of course, C will be criticized
as being "low level".

It helps to look at backwards. If you have large body of code written in a
complex programming language, and you want to simplify the programming
language, as a rule that will require adding reams of code to that existing
code to compensate.

No. In most cases the algorithm behind
list<int>
are not really complex at all and can be replaced without any greater
problem.


Every little thing you remove from the language will
potentially have an impact over broad areas of the existing code base,
potentially requiring reams of complexity to be heaped onto it.


Do you have any data to support that assertion? Supposing you replace
list<int>
with a linked list in C. You can use any of the several libraries
available. What complexity did you add?


Whatever /single/ thing you don't have in a language for taking care of some
responsibility translates to countless repetition of that responsibility.

No. It requires a little bit of coding effort that is payed off by
not having to care about the complexities of C++.

This is particularly true of language features that generate code. It's less
true of library features. If you take a function out of a library, you might be
able to just add that function to your program. You might have a big library
used by everyone in your your software organization, so you might be able to
just add it in one place even for many programs. But there are still other
organizations that will be similarly reinventing the function.

You might not like C++ templates, but what would have to be done to a C++
codebase that is based on templates, if templates were taken away, and how does
that task compare to the complexity of templates? What if the codebase is much
larger and more complex than the implementation of templates?

I am working in a solution of that problem. It is not the C++ way, but
the C way. "Trust the programmer" means that you open to the programmer
a window into the compiler itself. You can't imagine the SIMPLIFICATION
that that method provides. Instead of obscure templates you get REAL
compile time functions written not in an obscure functional language
like the language of boost metaprogramming but in C.

I am working in this since more or less a year, and I have a lot of
things working already. I will present it to the C/C++ community this
year.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
.

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: Language flame wars are moot
    ... > Most windows libraries and the like use their own collection ... only after determining if the language AND libraries provide ... Likewise I refuse to write math heavy code in Objective-C ... It SUPPORTS object oriented programming, ...
    (comp.lang.lisp)
  • 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)