[bitlug] Re: [Beowulf] Which is better GNU C or JAVA (for network programing)(fwd)
- From: Peeyush Prasad <peeyush@xxxxxxxxxx>
- To: bitcompsci02@xxxxxxxxxxxxxxx, <bitlug@xxxxxxxxxxxxx>,<kiggaboys@xxxxxxxxxxxxxxx>
- Date: Wed, 11 Feb 2004 13:28:56 +0530 (IST)
--
---------- Forwarded message ----------
Date: Fri, 23 Jan 2004 15:41:28 +0100
From: Jakob Oestergaard <jakob@xxxxxxxxxxxxx>
To: Robert G. Brown <rgb@xxxxxxxxxxxx>
Cc: prakash borade <hpcatcnc@xxxxxxxxx>, mail-plug@xxxxxxxxxxx,
beowulf@xxxxxxxxxxx
Subject: Re: [Beowulf] Which is better GNU C or JAVA (for network
programing)
On Wed, Jan 21, 2004 at 11:46:15AM -0500, Robert G. Brown wrote:
...
> > I find your lack of faith disturbing... ;)
>
> Trying an old jedi mind trick on me, are you?
>
> At least your metaphor is correct. You are indeed attracted to the
> Power of the Dark Side...:-)
Hey! Making jokes when we're having an *argument* - now that's just
plain unfair! ;)
...
> Well, we COULD make a list of all the major programs involving > 1KLOC
> (exclusive of comments, even) that have been written entirely in C (plus
> a small admixture, in some cases, of assembler). Unfortunately, the
> list would be too long (I'd be here literally all day typing), and would
> include things like the kernels of pretty much all the major operating
> systems (certainly all the Unix derivatives and variants) and gcc
> itself, including its g++ extension.
For good reason too
See - C++ was standardized in 1998 - but until around 2001 or so, there
were no decent compilers generally available.
Even today, "certain" platforms still have problems on the C++ compiler
front.
How many compilers and operating system kernels have been written from
scratch since, say, 2001? Yeah, probably some, but none that I know
of either :)
As I see it, C++ is a very new language when you consider languages that
are "mature" and "practically usable".
That's why I understand (and appreciate) that big things like the Linux
kernel or GCC are written in C - anything else at that time would have
been plain silly.
>
> To be fair, that doesn't prove that your observation is wrong -- there
> is a rather huge list of fortran sources available in my primary field
> of endeavor, for example, which doesn't stop fortran from being a cruel
> joke.
Did he just say the F-word? ;)
(oh, the memories of parallelizing serial chemistry code in Fortran
pre-77 from Cray to SP/2 with MPI.... The guy who wrote it had kept the
Amdahl-induced line serial numbers after column 73 in his code as a sort
of revision control - so he could see which lines he wrote before and
after 1970... I have a big scar on my chest from back then... The scars
in my mind will probably never heal though ;)
...
> What you probably mean is that IF everybody knew how to program in C++,
> they would have written all of this in C++, right?
*if* they knew the language and *if* they started over from scratch
today, then 100% affirmative *yes*.
(Starting a new project was the spawn of this thread)
> Let's see, is there
> a major operating system out there that favors C++? Hmmmm, I believe
> there is. Are it and its applications pretty much perpetually broken,
> to the extent that a lot of its programmers have bolted from C++ and use
> things like Visual Basic instead? Could be.
What operating system would that be? :)
I make a living from writing a piece of commercial software that runs on
a bunch of different operating systems, one of them being the one you
mention.
We use the Intel C++ compiler on that platform. We have to. Because the
opearting system vendor do not have a C++ compiler themselves - they do
have a compiler called "C++", but it does not understand the language.
We only have two major problems left with C++ support on that platform;
that Intel rely on the OS vendor's linker and STL - those are the two
weak links that are left.
So, honestly, I cannot say that they favour C++. If they do, they have
one sick way of showing it ;)
They do favour "bad C with extensions" though - I've seen a lot of such
code (on many platforms) being labelled as C++, so that might be where
the confusion comes from ;)
Now, you can look at my statements as I'm arguing for a solution which
would fit in an ideal world (which we do not live in) - this is not my
intention. I am just trying to point out that things have changed the
past 10 years, and what was true about a language under development 10
years ago just may not be the entire truth about what that language has
evolved into today.
> This isn't intended to be a purely a joke observation. I would rather
> advance it as evidence that contrary to expectations it is MORE
> difficult to write and maintain a complex application in C++.
I think this boils down to how well written the application is - and
that will hold true for any language out there.
I have seen unreadable ML - something I was told at university was
impossible (yeah, I didn't believe them either).
> The very
> features of C++ that are intended to make an application "portable" and
> "extensible" are a deadly trap, because portability and extensibility
> are largely an illusion.
Maybe I misunderstand, or maybe you know a dark corner of C++ that I
don't (that's not impossible at all :)
But for platform portability I use makefile rules to compile different
implementations of code prototyped in a common header file. Same as I
do in C.
...
> To go all gooey and metaphorical, programming seems to be a holistic
> enterprise with lots of layering and feathering of the brush strokes to
> achieve a particular effect with C providing access to the entire
> palette (it was somebody on this list, I believe, that referred to C as
> a "thin veneer of upper-level language syntax on top of naked
> assembler"). C++, in the same metaphor, is paint by numbers. It
> ENCOURAGES you to create blocks to be filled in with particular colors,
> and adds a penalty to those that want to go in and feather.
Hmm.... I would say, C++ allows you to write "quite" efficient code
really darn easily. If "quite" is not good enough, it allows you to do
what C would have forced you to; to write the stuff yourself. With no
run-time performance difference between C and C++.
You can say C++ might encourage people to accept the "quite" efficient
solution, whereas a "real" C programmer would have spent that extra
week writing yet another AVL tree implementation instead of using the
existing RB tree provided by the STL.
But there is nothing that stops you from spending that week and
re-inventing the AVL tree in C++ either.
Now some C programmers would say "but there are standard implementations
for all those data structures for C as well!" - the really funny part
being, that all generic data structure implementations in C that I have
seen, use void pointers to point to key/data members, which makes it
impossible for the compiler to do clever inlining, and therefore a
type-agnostic C implementation of an RB tree will actually be run-time
*slower* than the corresponding STL C++ RB tree ;)
This is the sort of thing that made me move from C to C++ (where
feasible - yes, part of my job is also writing software that will
actually function on a number of platforms including NetWare, so I do
write and maintain a good piece of C code as well ;)
...
> a) Do C's basic object features (typedefs, structs and unions, for
> example) suffice to meet the needs for object creation and manipulation
> in those code segments where they are needed? I would say of course
> they do.
I agree.
But I must add, that for example having "destructors" can take a lot of
pain out of memory management, when used cleverly and appropriately. I
have not found any usable substitute for that in C.
(Yes, you can write "destructor functions" and call them instead of
free(), it will work but it is less convenient).
Once you start using exceptions in error handling, destructors can
become quite essential in assuring that memory leaks cannot happen.
> IMO, protection and inheritance are a nuisance more often than
> an advantage because, as I observed, real "objects" are almost never
> portable between programs (exceptions exist for graphical objects --
> graphics is one place where OO methodology is very appropriate -- and
> MAYBE for DB applications where data objects are being manipulated by
> multiple binaries in a set). "protection" in particular I think of as
> being a nuisance and more likely to lead to problems than to solutions.
> In a large project it often translates into "live with the bugs behind
> this layer, you fool, mwaahhahahaha". Result: stagnation, ugly hacks,
> bitterness and pain. In single-developer projects, just who and what
> are you protecting your structs FROM? Yourself?
Never heard that argument before - but it's a good one.
I do not see protection as being a powerful feature in C++ (but I have
not thought about it before now - scary, you make me think! ;)
I see protection more as a way of commenting your code, with a compiler
assisted check that someone read your 'comment'. For example, "private"
means, "when you use this class/struct, you're not supposed to be
referring directly to this member". Someone new to the project can
look at the struct/class in question, and will know (assuming it is
well written code), that probably the original author had a good reason
for not wanting others to address those members directly.
So, I guess one could think of protection as "enforced comments". In a
sense one could argue that this is an unnecessary language feature,
because it make up for three reserved words (private, protected,
public), and only allows us to "enforce comments" in one particular (but
rather common) case.
Anyway, it's there. It does not give run-time overhead. Use it if you
want to. Or just use 'struct' if you feel better with that.
These two type declarations are *identical* (will yield exactly the same
code, memory layout, run-time performance, everything...):
struct A {
B b;
};
class A {
public:
B b;
};
If what you need is the first, it'd be silly to write the longer one ;)
I have quite a lot of C++ code which obviously uses the first and
shorter example. Anything else would just be plain stupid.
>
> b) Do C++'s basic object features increase or decrease the efficiencies
> of the eventual linked binaries one produces? As you say, C++ is more
> than an "extension" of C, it has some real differences. In particular,
> it forces (or at least, "encourages") a certain programming discipline on
> the programmer, one that pushes them away from the "thin veneer" aspect
> of pure C.
I disagree that it "forces" anything. This is a delusion, but a common
one at that.
I do agree though, that it can be difficult to keep people "sharp", when
you use a language that allows you to write really bloated code easily.
In C it is more difficult to write code that magically results in about
a billion nested function calls, even more dynamic memory allocations,
etc. etc. In C++ this can be a trap. In order to write lean code in
C++, you need to have some sort of dicipline (or a screaming violent
psychopath in the corner of the office - that's me ;)
So, in a way I agree that C++ can be more dangerous wrt. writing poorly
performing code. But it is not a language limitation, it is a
disciplinary problem :)
The same features that lead to this trap, are the same features that
allow you to write code that is as fast as "C the way you would have
written it if you had had the time", correct and maintainable.
If the programmer does not understand the language (ie. when to use
what), then I guess he has a good chance of writing something that's
really crap. But to a large extent that would go for any other language
as well.
The real incompatibilities from C to C++ (except for a few reserved
words which do cause real (but easy to remedy) problems), are mostly C
braindamages that noone really depends on anyway - at least this is my
experience... If anyone has counter examples, I'm always happy to be
enlightened. For example:
struct A {
struct B {
int a;
};
};
struct B b;
The above is valid C and invalid C++, because C++ does not forget scope
checking in this special case. C++ would require you to write:
struct A::B b;
Now, I'd be rather surprised if something like this is going to make all
your C code not compile with a C++ compiler ;)
> I think it is clear that each additional layer of contraint
> INCREASES the intrinsic complexity of the compiler itself, thickens the
> veneer, and narrows the range of choices into particular channels.
It absolutely increases the complexity of the compiler front-end.
Compiling C++ just takes longer. That's a real and practical problem
(but a good excuse for a Beowulf ;)
However, the language was carefully designed so that "you pay for what
you use". If you take a piece of C code that happens to also be valid
C++, and compile it with g++ instead of gcc, there is no valid reason
for the resulting code to be slower than the original gcc-compiled code.
> Those channels in C++ were deliberately engineered to favor somebody's
> idea of "good programming practice", which amounts to a particular
> tradeoff between ultimate speed and flexibility and code that can be
> extended, scaled, maintained. So I would expect C++ to be as efficient
> as C only in the limit that one programs it like C and to deviate away
> as one uses the more complex and narrow features.
One very powerful feature of C++ is templates. It has no run-time
overhead, compared to how you would solve the problem in C. They do
allow more complex problems to be solved, where in C you would fall back
to using void pointers and casts (instead of the proper types), which
would give you a *slower* C implementation than what C++ makes feasible.
Let me throw out a challenge:
"Write a program in C that reads from standard input until EOF, and
prints the number of distinct words found in that input"
I give you my solution here, in C++:
----------------------------------------
#include <set>
#include <string>
#include <iostream>
int main(int argc, char **argv)
{
// Declare and Initialize some variables
std::string word;
std::set<std::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;
}
----------------------------------------
I use an RB-tree to store the words I find, and print the number of
elements in the final tree.
A comparable C solution shouldn't be more than a few thousand lines ;)
Oh, right, I cheated and used STL. Well, STL is a big part of why C++
is really handy, but go right ahead and use "glib" or whatever.
I still guarantee you two things:
1) Your code will be longer
2) Your program will be slower
As always, I love to be proven wrong ;)
> Efficient "enough",
> sure, why not? CPU clocks and Moore's Law give us cycles to burn in
> most cases. And when one uses objects in many cases, they ARE cases
> where bleeding edge efficiency IS less important than ability to create
> an API and "reuse" data objects via library calls (for example). Still
> I think C would have to win here.
I'm just dying to see that piece of C which cannot possibly be made to
parse as C++, without fundamentally changing the structure of the code.
...[lots of good arguments nipped for brevity]...
> unchanneled by the compiler.
Yup, I understand what you mean.
And I'm not arguing that C++ is some magic silver bullet either.
All I'm saying is, that I think for 99% of the larger projects you start
today, C++ can provide you with some really convenient benefits over C,
with no practical downsides.
That is, if you know the language, if the people who will maintain your
code knows the language, and if you can rely on having a reasonably good
compiler. These are definitely practical obstacles out there in the
scary real world of coding, and I am aware of that.
Just trying to point out that *if* those practical obstacles can be
ovecome, then there *is* practical benefits. And today, just *maybe*
it is not universally a bad idea to at least consider whether the
practical obstacles can be overcome in order to reap the benefits that
can be provided.
Uh, I'm starting to sound like some middle-ground-searching tree-hugging
weed-smoking hippie. That was not my intention! ;)
> Do I have to deal with sometimes screwing up data typing? Absolutely.
> Do I have to occasionally deal with working my way backwards through my
> programs to redo all my structs? Of course (I'm doing it right now with
> a program I'm writing). This process is INEVITABLE in real-world
> program design because we DON'T know a priori what the best shape is for
> the data objects is until we've programmed them at least once the wrong
> way, in most cases. The really interesting question is whether or not
> this PROCESS is any easier in C++ than in C. I can't see why it would
> be, but perhaps it is.
In my experience, not much, if at all.
You screw up, decide to rewrite, and rewrite.
One thing which could give C++ an edge (depending on your program of
course), is, if your code is 1/10th the size in C++ - you would have
less code to rewrite :)
...
> This is a lovely tradeoff in a lot of cases, which is why I hesitate to
> actually stick a rod up java's ass and barbeque it on a spit. I really
> do believe the BASIC argument associated with OO programming, that the
> data and what you want to do with it should dictate program design
> features, including choice of language and programming technique. For
> many problems perl or python provide a very good data interface where
> one DOESN'T have to mess with lots of data issues that are a major chore
> in C. Wanna make a hash? Use it. Wanna make your hash into an array?
> Change the little % TO A @ and hack your dereferencing a bit. Is your
> hash actually stored as a linked list, as an array of structs? Don't
> ask, don't tell, don't try to look. All this and direct syntactical
> manipulation of regular expressions, what's not to love?
A hash of hashes, is not to love in perl ;)
At least, that's one thing they got right with STL and templates -
templates may not have the prettiest syntax imaginable, but at least
it's consistent. A map from int to int:
std::map<int,int> A;
a[42] = 5;
A map from int to a map from int to int:
std::map<int, std::map<int, int> > A;
A[42][5] = 8;
I can't remember how many explicit '{' and '%' you'd need in perl to do
that last one, but I do remember it wasn't pretty ;)
To be fair, I have never seen anything remotely as powerful as Perl's
regular expression handling. That's just sweet. Unreadable, but sweet.
...
>
> > I prefer to think of "C++" as "A better C", rather than a "C extension",
> > as not all C is valid C++, and therefore C++ is not really an extension.
>
> Funny that. I tend to think of C++ as "A broken C extension" for
> exactly the same reason;-)
Good one!
>
> If they hadn't broken it, then there really would be no reason not to
> use it, as if C were a strict subset of C++ all the way down to the
> compiler level, so that pure C code was compiled as efficiently as pure
> C is anyway then sure, I'd replace all the gcc's in my makefiles with
> g++'s. That would certainly lower the barrier to using C++; C
> programmers could program in C to their heart's content and IF AND WHEN
> their program needs a "C++ object" they could just add it without
> breaking or even tweaking the rest of their code.
Have you actually tried this and found that your code would not compile
with g++ ?
Anyway, I'm not arguing that all that is C should become C++. C has its
uses (sort of like automatic weapons ;)
I think for new projects C++ is worth considering. If I had a 10KLOC C
program that worked really well, I probably wouldn't bother to convert
it (even if no conversion was necessary). Why risk to break the
application on some obscure platform out there, if you are not going to
take advantage of the new language features anyway? I've never tried
such a conversion on a large program, and for the small programs where I
did it I ended up pretty much rewriting them anyway (having 60% void*
"generic" code with casts, and 40% template-based code is just *messy*
to look at).
> Breaking C was (IMO) a silly design decision.
Well, yes, but I believe the largest brekage is due to the new keywords,
which really coulnd't have been avoided (unless "static" should have
gotten yet another five-ten different meanings depending on which
context you use it in ;)
The other breakage (my scope example earlier) is more like a braindamage
in C that virtually noone depends on which was fixed. I like that.
> So was adding crap like a
> completely different stdin/stdout interface, which makes most C++ code,
> even that which doesn't use objects in any way, most
> non-back-portable-or-compatible to C.
The C library is readily available, and writing fprintf() instead of
std::cout in your C++ code does not make you a bad person :)
> It is very clear that these were
> all deliberate design decisions INTENDED to break C
Ok, Bjarne explains quite well in his books why each breakage was
introduced - they did deliberately break compatibility, but they paid a
lot of attention to not breaking "more than absolutely necessary".
You may disagree with the definition of "absolutely necessary" of course
- I do too at times.
> and FORCE
> programmers to make what amounts to a religious choice instead of
> smoothly extend the palette of their programming possibilities. I'd
> honestly have to say that it is this particular aspect of C++ more than
> any other that irritates me the most.
Ok.
I just do not see the breakage as such a deliberate attempt to piss
people off ;)
...
> >
> > Amen! This goes for C++ as well though.
>
> Y'know, you won't believe this, but I actually added the (and C++)
> references in my original reply just thinking of you...;-)
Hehe, thanks ;)
> Last time we had this discussion you were profound and passionate and
> highly articulate in advancing C++ -- so much so that you almost
> convinced me.
:)
> Alas, that silly barrier (which I recall your saying took
> you YEARS to get over yourself)... I just bounce right off of it in a
> state of total irritation every time I try.
I understand. I don't know of any easy way to do that.
Having too much time on ones hands is a good start I think. Yeah, I had
that once, I can almost remember it, if I think about it hard ;)
It was worse when I moved from Pascal to C though (quite a few years
earlier, I guess I was 16 back then - time does fly ;)
> Another problem is that
> every time I work with a student C++ programmer coming out of Duke's CPS
> department (which now teaches C++ as standard fare) I observe that while
> they are just great at creating objects and so forth they are clueless
> about things like pointers and malloc and the actual structure of a
> multidimensional array of structs and how to make one and manipulate its
> contents. As a consequence I have to spend weeks teaching them about
> all of the virtues of "C as a thin veneer" in order to get them to where
> they can cut advanced code at all, in either one.
Some people argue that it is better to start with C++, then "move on" to
C if necessary (or at least the subset of C++ that is also C).
I think they have many valid points. And so do you. I don't know.
For sure, you cannot be an excellent "computer programmer" if you do not
understand in detail how memory works, and all those other "details"
that *can* be abstracted away in C++. Those details will still bite
you, no matter how far they are abstracted away, and if you do not
understand them, you cannot hope to solve the problem.
I guess we agree on that :)
> You may not have encountered this as you did C first. Or maybe you
> never have cause to allocate triangular arrays of structs or to build
> your own linked list of structs, or maybe C++ does this and eats your
> meatloaf for you and I'm just to ignorant to know how.
C++ does not make the need for understanding go away.
Other "more pure" languages make understanding irrelevant though - no
matter how clever you are, you cannot solve the problem because the
language won't let you ;)
> Its funny. Back in the 80's all the CPS departments taught pascal
> because it provided strong type checking and absolutely forced one to
> use a rigorous bottom-up program design methodology. Precisely the same
> features that caused all real programmers to run from it screaming, as
> somehow all the programmers I've ever met work top down initially, then
> top, bottom, middle, whereever until the project is finished, often with
> a few epiphany-driven total project reorganizations in the middle as
> experience teaches one what the REAL data objects are that they are
> manipulating and whether they need easily maintained code that can run
> relatively slowly or whether they need the core loop to run faster than
> humanly possible if they have to hand-code it in assembler to get it
> there.
The difference, as I see it, is that Pascal *forces* you to use a very
rigorous (and limiting) type system, or, work around it in extremely
unsafe ways.
C++ *allows* you to use a fairly rigorous type system, and "fall back"
to casting where required. But even the casts have been made "safer",
for example, the static_cast will not cast away const, you must
explicitly add a const_cast if you really want to do that. Just an
example.
Typing the longer casts can be a little tedous - but hey, \textbf{} is
that long because if you used it frequently your text would look ugly
(don't remember if it was Lamport or Knuth who gave that explanation).
Same goes with cast-ridden code. The longer and more difficult a cast
is to type, the better ;)
But if you disagree with me, C++ allows you to use C-style casts as
well. Just don't come back complaining to me when they bite you ;)
> Now they teach C++, and as you observed, teach it badly. I humbly
> submit that the REASON they teach it badly is that they aren't teaching
> "C++" at all, they are teaching structured programming and programming
> discipline with a language that simply doesn't permit (or if you prefer
> encourage) the student to use methodologies with far more power but far
> less externally enforced structure. Pure pedagogy, in other words.
Thank you, I do prefer "encourage", and I would argue that "permit"
would be false. ;)
Handing a person a copy of Webster's will not make him a poet.
I'm sure we can agree on that last one (we can, right? ;)
It's a pity, really, if teaching of "real programming languages" is
really in such a sad state. I got some learning material from the
univeristy here (have a cousin who started there recently), and that was
*bad*. It was C though, at least I think it was meant to be (yes, it
was hard to tell). Giving 3rd semester students example code where you
do inter-process communication by writing to a file from one process,
and polling it from another (hoping that other write finished
completely), now that's just sick. Best part; the delay function (from
keeping the polling from taking too much CPU time or whatever) was a
busy wait - yes, you know, a for() loop which counts to a gazillion and
a half, with a neat little arithmetic function in it to keep the
compiler from optimizing the loop away.
I almost cried. Then came the rage. Oh, and the voices in my head.
[...good stuff snipped...]
> I suspect that students who learn C++ in this order are, as you appear
> to be, really good programmers who can get the most out of C++ and its
> object oriented features without "forgetting" how to manipulate raw
> blocks of memory without any sort of OO interface per se when the code
> structure and extensibility requirements don't warrant all the extra
> overhead associated with setting one up.
I really don't know how one ought to teach people "properly".
But I absolutely agree with you that one must understand the machine
that one intends to program. At least to a resonable extend (and that,
in my book as well as in yours it seems, includes knowing about layout
of datastructures in memory, knowing that caches exist, etc.)
...[much more good stuff snipped]...
> Give me a few days paring C++ down to the bare minimum extension of C so
> that it is a pure superset (so ALL C CODE just plain compiles perfectly
> and even produces the same runfile, so that the I/O language
> "extensions" are moved off into a library that you can link or not,
You would need to take out the 'template' reserved word (among others)
to gain that full compatiblity.
That alone would make C++ woth only half as much. Templates are
*extremely* powerful (when in combination with either existing C and new
C++ constructs).
Again, I believe that there were good reasons for the breakage
introduced. Sure, you can probably point out things that were stupid,
and I may even agree with you, but a major part of the breakage was
definitely a "lesser evil", at least the way that I see it :)
> mostly not, and so that using things like classes and protection and
> inheritance are suddenly pure and transparent extensions of the basic
> ideas of structs and unions and typedefs, and I wouldn't even argue. In
> fact, I'd say that the argument itself becomes silly and moot.
Exactly!
>From where I stand, in many situations (in particular, the situation
that spawned this very thread - the start of a new project), we may
already be at the point where there is no practical downside to using
C++ as compared to C.
That leaves you with some possible benefits you can use where you see
fit.
Assuming, as before, that the author knows the language etc. etc.
And the whole argument becomes silly and moot :)
> One
> wouldn't even have to change Makefiles, as C++ would just be a feature
> of gcc that is automatically processed when and where it is encountered.
[albatross:joe] $ g++ -o wc wc.cc
[albatross:joe] $ gcc -o wc wc.cc -lstdc++
We're there already - sort of ;)
Just rename your files and you're done (the wc.cc file is the
"challenge" from above) ;)
> So the kernel would suddenly be written in "C++", sort of, and there
> would be a very low barrier to converting C into C++ because basically,
> there would be no conversion at all, only extension.
Well, yes and no.
Thinking about all this, I am actually not so much of a proponent of
converting existing C projects into C++.
I believe it is better to make a "clean break" - when starting a new
project, go C++ from the beginning. Do templates. Use STL. Manage your
memory safely.
Compared to a hybrid project, where some percentage of the code is
"very" safe, some percentage is "rather unsafe", and some of the safe
code may need to call unsafe code and end up being unsafe itself.
I don't know actually - I have a gut feeling that such a conversion
would be a pain. The problem is not the conversion itself, the problem
is that you end up with a so-called C++ program, which has never taken
advantage of the advantages that C++ could have provided.
So, in effect, your old "Good C" program becomes a "Bad C++" program.
I am not so sure that this is a change to the better. In fact, you may
even make me say that it is probably not...
And this may be a good reason to keep the good ol' "gcc" for a few more
decades. For all the code that is "Good C".
> This of course will never happen. Until it does, then an excellent
> reason to choose C instead of C++ is if you happen to know C very well
> but not know (or care for) C++ as well.
That's a good reason for sure! :)
It's even language neutral ;)
[...good stuff snipped yet again...]
> majority of people who stick with C++ end up programming for Windows for
> some big corporation (which might well be Microsoft) -- and produce
> shitty, broken, huge, inefficient code as often as not.
Hey, I will claim that:
*) "Bad C++" has a strange attraction to crappy programmers
*) Windows has a strange attraction to crappy programmers
Thus, I end up observing the very same thing as you; that a lot of
people write crappy C++ on windows.
I'd just rather attack people than languages ;)
(uh, *some* languages that is... Don't get me started on the J-word ;)
[...more good stuff snipped yet again...]
> lives next door writing software and clipping coupons. Other faculty I
> know seem to view C++ the same way -- a good thing to use to teach
> students because it forces them to code a certain way, but THEY don't
> use it for THEIR research projects.
I think it's a matter of time until more people get to learn the
language and get used to it.
Sure, a struct may be all you need. But then one day you have a struct
which just needs a dynamically allocated member. And then, maybe, you
find that it is convenient that you can put the deallocation of that
member in the struct destructor. It's the little things, at first.
Small conveniences that just come in handy.
As far as my arguments have gone, C++ is more like a three year old
language, in the "mature languages" world. No wonder it's not
ubiquitous.
Especially when looking at production systems or even research projects
that may have been 10 or 20 years in development.
>
> Professionals seem more often than not to prefer having the entire
> palette and all the brushes, and don't like even MAKING color by numbers
> codelets.
I continue to claim, that you do have the whole palette. It's just,
that for the little trivial things where colour by number is more
convenient and fully accomplishes the task at hand, you can actually do
it, instead of starting to cut out the support frame for your future
canvas on which you will eventually paint your masterpiece.
You should still know how to produce a canvas, and how to paint
properly. But you should (in my oppinion) not be absolutely required to
start from scratch for every little trivial problem that needs solving.
Any large project will solve countless small trivial problems, and a
number of absolutely nontrivial problems too probably. It's darn
convenient to be able to solve the trivial ones trivially ;)
It will take a long time before C++ is generally accepted as "A Better
C", I'm sure, but the time will come eventually (bets, anyone?) ;)
>
> This is very definitely not exhaustive or definitive. I also know
> students where they exact opposite is true -- they learned C++, learned
> about data structs and malloc and C, and continue to code in C++ (as you
> do) with strictly enriched abilities. Of course they are (like you;-)
> Very Bright Guys...
*blush* ;)
> and could probably even write good Fortran code if
> they ever learned it. No, wait, that is an oxymoron -- couldn't happen.
Point!
...
> I agree, and hope you realize that I'm deliberately overarguing the case
> for C above for precisely that reason. I really do believe that it is
> as much a matter of taste and your particular experience and application
> space as anything else and wouldn't be surprised if some java coder DOES
> speak up for java as that's what THEY are really good at and they've
> discovered some feature that makes it all worthwhile.
I see it as serious fun :)
Besides, it's no fun to hear about a langauge from someone who doesn't
care about it. You need to poke people, call them sissies, tell them
their language sucks and things about their mother, and *then* you can
get a good language discussion going ;)
A good language discussion needs *passion*, *anger*, *love*, true
feelings.
Or maybe that's just me... ;)
> We've already heard from the python crowd, after all, and THAT'S a
> language where they even eschew such obviously useful constructs as {}'s
> and line terminators such as ; in favor of indentation as a matter of
> deliberate design/dogma. It really does come down in the end to
> religious belief/personal taste.
They do that to some extent in Haskell as well - I code a little in
Haskell from time to time, but haven't gotten around to Python yet. The
indentation idea is, well, "interesting", I'd say :)
>
> In the best spirit of tongue-in-cheek, I cannot do better than end with:
>
> http://www.phy.duke.edu/~rgb/Beowulf/c++_interview/c++_interview.html
>
> Read it and weep...:-)
Will do.
Both, I fear ;)
Cheers,
/ jakob
_______________________________________________
Beowulf mailing list, Beowulf@xxxxxxxxxxx
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
Other related posts:
