![](https://seccdn.libravatar.org/avatar/cb2fb2ffdbbbc003e8ea1d048ae8c2ff.jpg?s=120&d=mm&r=g)
El día 11 de diciembre de 2008 16:54, lluis
El jue, 11-12-2008 a las 17:32 +0100, Carlos E. R. escribió:
A lo mejor por eso el Gnome era capaz de funcionar en una máquina de 32 megas de hace 10 años, y el kde se arrastraba - todo el mundo sabe que programar en C++ es una desperdicio de recursos :-P
Y dale, lo del C++ NO es verdad.
Seguramente se referia a TODO EL MUNDO QUE NO SABE PROGRAMAR.:
http://unthought.net/c++/c_vs_c++.html
http://www.cs.utk.edu/~huangj/CS302S04/notes/c_versus_c++.html
http://www.eventhelix.com/RealTimeMantra/basics/ComparingCPPAndCPerformance2...
Del primer link:
So, what's the deal with C++?
I'm assuming that you know C already. If you do not, then this article
really isn't for you.
For the vast majority of problems out there, I state that C++ provides
no significant downsides and a number of significant improvements.
Bold? Some people seem to think so, but it's really the case. Let's
start out by clearing up a few very common C++ misunderstandings:
* C++ is slower than C Wrong! Many C programs are valid C++
programs as well - and such a C program should run at identical speed
when translated with either the C and with the C++ compiler.
* C++ specific features give overhead Wrong! The so-called
overhead introduced by certain C++ specific features (such as virtual
function calls or exceptions), is comparable to the overhead you
yourself would introduce should you choose to go thru the pain it
would be to implement a similar feature in C.
* C++ is object oriented Wrong! The C++ language contains some
language extentions over C, that make object oriented programming and
generic programming more convenient. C++ does not force object
oriented design anywhere - it merely allows for it if the programmer
deems OO feasible. C allows for object oriented programming as well,
C++ only makes it simpler and less error prone.
So, if you believe me, we have established that "C++ is not
significantly worse than C". Let's have a look at what it is that
makes C++ a better C:
* Stronger typing The type system in C++ is stronger than in C.
This prevents many common programming errors - coupled with the next
very important feature, the stronger type system even manages not to
be an inconvenience.
* Parameterized types The template keyword allows the programmer
to write generic (type-agnostic) implementations of algorithms. Where
in C, one could write a generic list implementation with an element
like:
struct element_t {
struct element_t *next, *prev;
void *element;
};
C++ allows one to write something like:
template <typename T>
struct element_t {
element_t<T> *next, *prev;
T element;
};
Not only does the C++ implementation prevent common programming
errors (like putting an element of the wrong type on the list), it
also allows better optimization by the compiler! For example, a
generic sort implementation is available in both C and C++ - the C
routine is defined as:
void qsort(void *base, size_t nmemb, size_t size,
int(*compar)(const void *, const void *));
whereas the C++ routine is defined as
template
void sort(RandomAccessIterator first, RandomAccessIterator last);
The difference being, that for example sorting an array of
integers, would, in the C case, require a function call for every
single compare, whereas the C++ implementation would allow the
compiler to inline the integer comparison calls, as the actual sort
routine is instantiated at compile time, automatically by the
compiler, with the correct types inserted in the template arguments.
* A bigger standard library C++ allows the full use of the C
standard library. This is very important of course, as the C standard
library is an invaluable resource when writing real world programs.
However, C++ includes the Standard Template Library. The STL contains
a number of useful templates, like the sort routine above. It includes
useful common data structures such as lists, maps, sets, etc. Like the
sort routine, the other STL routines and data structures are
"tailored" to the specific needs the programmer has - all the
programmer has to do is fill in the types. Of course, the STL is no
silver bullet - but it does provide a great help very often, when
solving general problems. How often have you implemented a list in C?
How often would an RB-tree have been a better solution, if only you
had had the time to do it? With the STL you do not need to make such
compromises - use the tree if it's a better fit, it's as easy as using
the list.
Ok, so I've been telling about all the good parts. Are there no
downsides? Of course there is. Howver, they are shrinking day by day.
Let me explain:
* There are no good C++ compilers It's been like this for a long
time. But you must remember, that the language was standardized in
1998 - it is a complex language, more complex than C. It has taken a
long time for compilers to catch up to the standard. But as of this
writing, there are good compilers available for the most widely used
platforms out there; GCC in versions 3.X are generally very good, and
it runs on GNU/Linux and most UNIX platforms. Intel has a good
compiler for Win32 - it is also pretty good, but unfortunately it
still relies on the MS STL which is sub-par.
* People don't know good C++ This is not an often heard complaint,
but it's something that I see a lot. C++ is a big and complex language
- but it also used to be a language that was hyped a lot, especially
back in the "OOP solves hunger, cures AIDS and cancer" days. The
result seems to be that a lot of really poor C++ code, basically bad C
with a few class statements here and there, is out there and is being
used as learning material. This means, a lot of people who believe
they know C++ actually write really crap code. That's too bad, and
it's a problem, but I think it's unfair to blame C++ for this.
So, the only two major problems with C++ are results of C++ being a
young language. In time they will vanish. And for most problems out
there, if you can get good programmers (or learn good C++ yourself),
the problems are not really an issue today.
Note, that I am not arguing that everything is rewritten in C++. There
are many large projects out there which are written in C - I do not
believe that it is a good idea to just "convert" them to C++. C++
allows for cleaner solutions than C does, for a great many problems.
Doing a minimal conversion of a solution which is "as clean as it
gets" in C, to C++, would convert "good C" code into "poor C++". That
is not a change to the better!
I have converted code from C to C++. But such a conversion has always
ended up being a complete rewrite. From scratch. A redesign as such
may not be necessary - after all, C++ does not force any new design
principles down your throat, and if the original C code was well
designed, there may not be a need to redo that.
However, for new projects starting out today, I fail to see why anyone
(who knows C++ or is willing to learn it) would use C rather than C++.
Unless, of course, that one of the two problems stated earlier are
important.
The Challenge
So, after a little back and forth on the Beowulf mailing list, where
various people (myself included) argued for the pros and cons of their
pet languages and other peoples (inferior of course) pet languages, I
decided to put out a challenge; I presented a problem, and a small and
clean solution for it, and challenged the list to come up with a
better solution.
The problem: Write a program that reads text from standard-input, and
returns (prints) the total number of distinct words found in the text.
In short, I presented a C++ solution to the problem, and challenged
someone to do it in C. I even wrote:
I still guarantee you two things:
1) Your code will be longer
2) Your program will be slower
Hey, you gotta be bold to keep these things interesting!
Initial solutions
The small C++ solution
The following is the solution I presented with my challenge. It is a
total of 15 lines of C++. It uses the STL std::set template with an
std::string as the template argument, to hold the words read from
stdin. In non-C++ speak this means I use an RB-tree of strings.
#include <set>
#include <string>
#include <iostream>
int main(int argc, char **argv)
{
// Declare and Initialize some variables
std::string word;
std::setstd::string wordcount;
// Read words and insert in rb-tree
while (std::cin >> word) wordcount.insert(word);
// Print the result
std::cout << "Words: " << wordcount.size() << std::endl;
return 0;
}
Personally, I think this is elegant. Anyone who knows C++ will be able
to glance at the code and understand completely what it does, within a
few tens of seconds. The code is short, and only extremely simple
well-understood operations are performed on the data - it is quickly
established that the code is correct. If the beholder understands the
language, of course, but this is a problem with all languages.
The faster C solution
Of course, shortly after that post, someone replied with a faster
implementation in C. I should have known that. I was happy to see,
that the C implementation was indeed longer - this faster solution is
85 lines long.
Note, the actual code presented here is not the exact suggestion sent
to the list - I changed the printing of the result at the bottom of
the code, so that the program prints out the number of distinct words
- the original code was made to print out an unsorted list of word
frequencies. This change only touches a few of the very last lines in
the code, it touches nothing in the central parts of the program at
all.
Unlike my initial solution, this program uses a hash to store the
distinct words. A hash can be faster than an RB-tree - a well
dimensioned hash can exhibit O(1) complexity for insertions where an
RB-tree exhibits O(log(n)) complexity.
The change of algorithm is unfortunate for a language-performance
comparison point of view - as the C implementation will exhibit
different run-time performance than the C++ implementation, for
reasons that are not related to the choice of language at all.
However, I'm not going to bitch about it, I'm going to evaluate the
suggestion and still prove my point; that C++ is a better language for
solving general purpose programming problems.
Let's have a look at the C code shall we;
/* Copyright (C) 1999 Lucent Technologies */
/* From 'Programming Pearls' by Jon Bentley */
/* wordfreq.c -- list of words in file, with counts */
#include
As in maybe it's just me, but when I look at Jakob's code I have no idea how it works. What are these routines? What do they do? Where's the logic? Oh, I can read the comments and see the keywords and sort of guess that all sorts of dark magic is being done; I just have no idea how it does it, any more than I would if one took Jakob's code or my code or anybody's code for the same task and wrapped it up in a single routine:
And here I argue that this is where C++'s strength becomes evident. STL is _standard_ (hence its name). Thus, for a C++ programmer, Jakob's code is comprehensible in one 15second long glimpse and this programmer can immediately use (trust?) the code. With the equivalent C code from the posted link, I personally have the problem that I need at least 15 minutes to read and understand it, and even then, I can't be sure I identified all gotchas and thus I can use it without major crashes and problems. I argue that the biggest problem with C up until glib and gsl (thus very recently) was exactly the lack of high level routines collected in a ubiquous library. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org