Perl6 Being Rewritten in C++ 152
jamiemccarthy writes "A rewrite of Perl in C++ is underway. The audacious plan, now called Topaz, will become Perl6 if and when it's successful. Its author, Chip Salzenberg, will
tell you all about it. " Wow. That's quite a project - you can also listen to Chip's talk given at the OpenSource Convention. For those you unaware, Chip is one of the Perl core developers.
Re:C++? Take a *good* language! (Score:2)
after all, python people wrote a mailing list manager just so they wouldn't have to use majordomo written in perl.
Well, we could use python to write perl, perl to write python and have tons of fun.
There's that story about when steve jobs bought a cray machine. the sales manager called up the guy who designed cray (I forgot the name) and told him that apple bought a cray to be used for designing apple computers. The cray designer thought abit and said that it was logical - he is using an apple to design the cray.
Re:One Question... (Score:1)
They could have used JPython, which is a Python implementation that compiles to Java bytecode. Can't get much more portable than that, and GCC will compile Java class files into native executables if you want more speed.
What?
What?
WHAT?
I can't help but wonder.. (Score:1)
..and no this isn't intended as a flame (I'm sure it will be interpreted as one by many anyway, but whatever.. ;).. if this comes from someone who thinks that Perl stands for Practical Extraction and Report Language..
Doomed (Score:1)
First, anyone who has any aspirations of writing platform independent C++ code should read what netscape [mozilla.org] has to say about the subject. This should scare off any right-minded hacker.
A re-write of perl has interesting correctness issues. Larry Wall believes that languages are so complex that they can't be completely specified. Therefore, he has intentionally avoided a formal specification for perl, relying on the one implementation as the spec. How will we know if this new implementation is correct? I bet that any new implementation of perl will break thousands of existing scripts.
C++ is deceptively complex - in ways that perl isn't. You really need to know every corner of C++ before you can write solid, reliable, extendable code. Chip's description of his project doesn't make him seem like one of the top ten C++ programmers in the world, and I think you'd need to be, in order to pull off this project. Just as a one particular, I'm curious how he intends static initializers and destructors are going to get called for dynamically loaded code in any portable way.
Binary compatibility. C++ classes aren't guaranteed to have binary compatibility on the same platform from compiler to compiler, or even from any given release of one compiler to the next. This makes distributing and maintaining pre-compiled perl modules for a given platform much more difficult.
Re:Stability (Score:1)
In
Half of my programs are linked to 2.8 and the other half to 2.9 and they are completely incompatable. What nonsense!
Re:Stability (Score:1)
What nonesense!
Re:It's slow enough already... (Score:1)
#wc Database-HOWTO.txt
13313 63905 472980 Database-HOWTO.txt
So.. it's a pretty big file. Both programs were compiled under pgcc-2.91.66, with -O6 -mpentium and the binaries were stripped.
Here's the code: (hope this looks ok.. please excuse the complete lack of formatting.. html is a tricky medium with a limited subset of tags!)
#include <iostream>
#include <fstream>
#include <string>
using namespace std;
int main( int argc, char *argv[] )
{
string szinput;
ofstream write;
write.open( "output_cpp.txt", ios::out );
while( cin >> szinput )
write
write.close();
return 0;
}
#include <stdio.h>
#include <string.h>
int main( int argc, char *argv[] )
{
FILE *write;
char buffer[4096];
char *ptr;
write = fopen( "output_c.txt", "w" );
while( fgets( buffer, 4096, stdin ))
{
ptr = strtok( buffer, "\n " );
while( ptr )
{
fputs( ptr, write );
fputs( "\n", write );
ptr = strtok( NULL, "\n " );
}
}
fclose( write );
return 0;
}
...the results...
Juggernaut:~/test/source> time words_c
0.080u 0.020s 0:00.11 90.9% 0+0k 0+0io 200pf+0w
Juggernaut:~/test/source> time words_cpp
0.370u 0.140s 0:00.50 102.0% 0+0k 0+0io 145pf+0w
Don't ask me how I got 102.0% cpu. I just cut and paste. It is an overclocked celeron, so that might have something to do with it.
Anyway.. C is obviously much faster at this. However.. the C++ code is much easier to understand.
Of course, the perl code for this is very simple, short and easy to understand:
open( OUTFILE, "> output_perl.txt" );
while( <> )
{
foreach $word( split )
{
print OUTFILE "$word\n";
}
}
Juggernaut:~/test/source> time
1.080u 0.020s 0:01.35 81.4% 0+0k 0+0io 402pf+0w
At a cost!
Java (Score:1)
Jou don't get that from himplementing Perl in Java. You get that by implementing Perl to compile not to their own intermediate code, but to Java Byte code and then run the result through a Java VM.
So I guess that the implementation of Perl should never been thought of been done in Java.
Re:perl in perl? (Score:1)
It would be a fascinating Idea of having a Perl Frontend for egcs. Then the last point would also speak for Perl.
One could also write and test perl code using the Interpreter, and when it comes to beeing productive and fast compile it.
Re:There are other languages... (Score:1)
OTOH, I wonder why he didn't choose GNAT.
From the article: The problem is that if Perl 6 were written in Ada--it would require people to bootstrap GNAT before they could even get to Perl. That's too much of a burden to put on anybody.
Basically Ada '95 didn't get used because a lot of people don't have it. Chicken, egg, egg, chicken.
But that may also be suffering from lack of current maintainers.
Errm? 3.11p was released in January, and 3.12p is suppoused to be out RSN.
AdaCore Technologies is the normal maintainer, but they were sounding very commercial when I talked to them a year ago.
Hmmm. I'm a member of the Ada-Linux team [gnuada.org] and we've got a very good relationship with ACT and ACT-Europe. They are a company, but they do do a lot to help both the Ada and GNU communities (there was an ALT/ACT meeting in Paris in June), both officially and unofficially (the Ada-mode [eu.org] for emacs is maintained by them, and several members of ACT-Europe helped create GtkAda [eu.org])
Of course the problem of where to get his programmers couldn't have anything to do with his choice. :-)
Course, comp.lang.ada [lang.ada] wouldn't be a good place to start would it?
- Aidan (dislikes disinformation, but is horrendously behind on /.)
The problem with C++ (Score:1)
The problem, as I see it, with C++ is that give them a few more iterations and the Standards Folks will have used every English word as a keyword and we will be left using hard coded constants. I suspect that is why unicode is getting more and more popular. They've even had to start re-using keywords (if re-use works for code, why not language syntax). At last count, the number of different uses for 'const' was approaching Avagadro's number.
Mind you, I think keyword bloat is probably good for compiler writers. Since no one can possibly implement ALL of the C++ keywords a lot of the pressure is gone. They only have to implement the subset of them that they like most. For the rest of the keywords, they can just give suitably entertaining compiler errors, such as the following that I got out of g++ (or was it CC?) a couple of years ago...
WARNING! Namespaces is mostly broken!
(Ah, I feel better after that rant
Dana
Re: (Score:1)
Re:perl in perl? (Score:2)
There is another school of thought that says the language being implemented is clearly the best in the world for almost all purposes, therefore its compiler/interpreter should be bootstrapped.
In general, I don't think that either of these attitudes is entirely appropriate. It strikes me that when implementing a translator for a programming language, that one would want to use a language that had:
1) Automatic lexer and parser generator tools. I suspect that the lack of these tools is not a real barrier though, since most compiler jocks know enough to rattle both off in a weekend.
2) Reasonable linguistic facilities for manipulating strings.
3) Reasonable linguistic facilities for specifying and manipulating user defined data structures -- particularly trees.
4) Some way to do information hiding and separate compilation. And perhaps other facilities for programming in the large.
5) A reasonably speedy implementation, so the translator that you're writing isn't hideously slow.
Now, does Perl have all of these attributes? Mostly. The thing that I would think you wouldn't want to do, is write a bytecode interpreter in Perl. This, you definitely want to do in C (if you're concerned with portability) or C/assembler (if performance matters more than anything else).
How behind the times are you? (Score:1)
Besides which the Perl5 syntax is simpler, and it supports lots of neat things. (Taken a look at CPAN recently?)
Cheers,
Ben
So what's it in ATM? (Score:1)
Please excuse me for never having looked at the Perl sources, or even downloading them. I got fed up with compiling it myself and nouse rpms.
Re:Why C++? (Score:2)
So, I'd expect a similar design decision was made for Topaz. In interpreters you have to deal with data structures that represent scalars, arrays, dictionaries, etc., so an OO approach might let you avoid hard-wiring an expected type, in favor of an expected interface. Whether this will pay off significantly is the purpose of the experiment.
Macro's (Score:1)
Re:first post (Score:1)
No, Perl is interpreted, so it's not possible for it to interpret itself. How would the interpreter run, if it were in Perl? (Actually, Perl compiles to bytecode - but that needs interpreting by a C program.)
As perlfaq1(1) [perl.com] says:
Re:Wanna see you do it in C (Score:1)
But, but, everything else's suposed to be in C++!
(this is me desperatly trying save my side of the argument and loosing...badly)
No, I can't spell!
-"Run to that wall until I tell you to stop"
(tagadum,tagadum,tagadum
-"stop...."
Sure this is an ... interesting decision. (Score:1)
Basically, apart from the time it would take to write, the only downside I can see to this is the huge number of Perl modules that would be utterly broken.
Part of the attraction of using Perl for me is that I know whatever I'm doing there are going to be modules available to help me solve my problem.
Changing the implementation, and breaking these modules is going to be a huge loss from the whole Perl community - I've written Perl modules, and I've dabbled in embedding a Perl intepretter inside some of my programs, so I know how deeply you sometimes have to get inside Perl to work.
The obvious question is how much gain there would be if the code was re-written in C++, I know that a lot of the Perl code is an utter mess to follow, not the mention the "witty" comments
like:
If the code was restructured in C++ it could be better, but I'm sure that it could be equally structured if the C code was smarted up.
Some OO(P) advocates tend to forget that its possible to program OO'dly with necessarily using an OO language. (Though granted it is a little harder, and some things are not as "nice").
As for the whole "C++ is too slow / inificcent"
argument I think thats a no-brainer, Perl is never going to be the fastest language in the world if it remains intepretted, (I wonder how the Compiler Malcomn Beatty was working on is coming along), the implementation langauge should have little impact on the end-user.
Besides I don't imagine that many "advanced"
features of C++ would be used if it was to be re-written. But the readability of the source code would go way up if there was a nice object structure, with a clear inheritence model.
As soon as the more people can understand the Perl code the maintainence suddenly becomes much easier.
(I wonder how many of the people who say that Perl is a write only language have seen the source
Steve
One Question... (Score:1)
Re:Java (Score:2)
Sure you do, the interpreter is a Java program. The java program gets optimized so the perl implementation benefits from the optimizations. Of course you would never get the same speed as with compiled perl (since we are talking about an interpreter), you are right about that. But also a Perl JIT compiler could be written in Java, especially if it is supposed to compile to Java bytecode but other code should be no problem either.
But as I said in my original post, I don't belief Java is fast enough at this moment to meet the performance requirements for PERL (i.e. be as fast as modc, or whatever its called, for apache).
Re:It's slow enough already... (Score:2)
Well, no I wasn't, I was just using a contrived example. The point is that the reason it looks like C++ is doing something weird is because it just provides language definition capabilities needed to make first class types. I get your point though.
>Instead of using recursion, they wrote an
>iterative function with handcoded
> stack. They made the stack dynamic, extending
> their sizes using malloc() and free()!
Ha! To bad you can't tweak them about it without getting a bad grade.
Actually, call/return overhead is the least of your worries when you're calling malloc and free. On many systems, these are the slowest OS calls there are that don't do IO.
Re:first post (Score:1)
C++ is slower than C? (Score:1)
Speed issues are largely just compiler issues. Whatever you say about each language, they both end up as machine code. How fast the executable is depends on the compiler far more than the language.
Time to fork, then? (Score:1)
stable language; most systems don't implement
the spec properly yet.
Anyway, this says to me "we are buying into
buzzwords". I don't like it. Perhaps someone
else should look at a clean rewrite in a real
language?
Maybe it's time to start pushing C9X.
:)
Re:One Question... (Score:2)
"So, we're left with C++. It's rather like the comment that I believe Winston Churchill is reported to have said about democracy: It's absolutely the worst system except for all the others. So, C++ is the worst language we could have chosen, except for all the others. "
Re:A perspective from a perl porter (Score:1)
Let me put it another way:
If perl's OO module is not fundementally broken, why would you rewrite perl in a language that isn't doing things that way?
If "there is no security. don't use the undocumented API" is a good philosophy (and I think it's a great one), then you can do that just as well in C, without pushing us all to much less reliable compilers.
C will be more stable on more platforms forever.
Let the language wars begin! (Score:5)
(
Who remembers... (Score:1)
The reason Perl is so hard to maintain isn't that it's written in C. It's that it's written in hard-to-maintain C. If someone were to rewrite it in C with the same clarity as, say, emacs or qmail or tcl, the problems that Chip alludes to would go away.
{'dot'}->{'notation'}->{'please'} (Score:1)
Does it feel awkward to you to write every fscking structure reference in the perl ->{} format? Wouldn't it be nice to do structured variable embedding as s/\$([\w\.]+)/${$1}/gs ? A syntax hook for such would be nice
Re:Damn (Score:1)
Perl6 (if I'm reading and listening correctly) will still be the same unwieldy, arcane beast you have known and loved. ;) It might have a smaller footprint, squeeze into tighter spots (MicroPerl! yay!), and be a bit easier to maintain.
And it won't have all those nasty macros you C programmers seem to like so much. (ducking and covering) ;)
Re:How about /this/ part of the article..? (Score:1)
Not really. Simula [dmoz.org] is generally considered to be the first object-oriented language (i.e. being built around the notion of classes: entities which encompass both data and behaviour). It builds on Algol60 [dmoz.org] and was defined in 1967; it predates both C and Pascal which are early seventies.
Object-orientation gained popularity through SmallTalk [dmoz.org] (late seventies).
C++ isn't a pure OO language; it's a procedural/OO hybrid language due to being based on C. It's unwieldyness isn't explained by this. Other OO and OO/hybrid languages (say Objective C [dmoz.org] which was a stronger influence on Java's OO nature than C++) are a lot less unwieldy.
Nowadays, Object Orientation [dmoz.org] and OO programming [dmoz.org] are popular because they allow for a more natural modelling of problem domains and implementations of solutions than the procedural approach which makes it possible to deal with larger problem sizes.
Re:perl in perl? (Score:1)
Bootstrapping Through Another Language (Score:3)
Object Orientation is a relatively new paradigm, and work is still being done in making OO code run faster - in general. It is the OO heirarchy that slows down C++ compared to C, it is what helps make Java slower even though the JVM is a relatively efficient interpreter/VM, and it is what "crippled" languages like Smalltalk and Eiffel in the eyes of "real" developers. However, the ease of design and maintainability of OO code has inspired a lot of research into trying to speed up OO languages so they can compete with their functional counterparts.
The advantage of Sather isn't speed (not yet, maybe someday), but, according to the authors, ease of maintainability. This, however, might be a reason to make the choice to use this language. As C++ is fairly broken in some places due to the ad-hoc OO/C integration, it can be very quirky to work with, and it's easy to write bad C++. I'd need to study Sather in detail to say it is actually more elegant and maintainable than C++, but I rarely doubt claims that something is more elegant than C++
Unfortunately, though, to port the Perl source to Sather one would first need to port the Sather compiler to Windows, as Berkely hasn't bothered doing so... and the Perl6 team will obviously need to support Perl on Windows as that's been in the core Perl for a bit of time now...
Creating a formal language base to bootstrap a framework into C through LISP is a great idea... but according to Larry Wall, PERL can not be formally specified in such a manner, and therefore I believe that this tactic would not work in this case, though I have not really studied the possibility in any great detail.
The suggestion of rewriting Perl in Python is a bit silly... why not rewrite Perl in Scheme, TCL or Java... or Perl? Talk about speed not being an advantage... While Python is pretty fast, Java with a good compiler (such as Jikes) and a good JVM (such as Java2 with HotSpot) is faster, at least on our tests on WindowsNT and Linux.
If raw speed at the expense of maintainability (and therefore the possibility of speed lost to bad programming rather than a "bad language") is one's goal, C is still the language to use (or assembler if you're both wed to one chipset and a total maniac). Otherwise, there are a lot of choices, including C++.
I think C++ was chosen because porting from C to C++ isn't that difficult to do (at least to do very badly), and can be done incrementally. I think the efficiency of Perl in C vs C++ will depend entirely on the programmers and how they use the language. As one person already pointed out, if they use C++ for some added maintainability but with an eye towards speed (that is, use the parts that don't slow the program to a crawl), they'll do just fine on the speed front...
Re:True Hackers... (Score:1)
Not!
Chip Speaks! (Again!) (Score:1)
You see, I'm in the middle of a cross-country move, having just been hired by VA Linux Systems, and my net access this week is probably the worst it's been for five years. Right now I'm in a borrowed office at an Alabama rest stop.
I will review everyone's comments and do my best to respond to them--and to work on the code! But please be patient while I settle into Geek Country. Just the culture shock will probably set me back for a day or two. :-)
Re:Why C++? (Score:4)
Macros are evil. Each time you use a macro you are working around a language limitation. C++ has more language constructs than C so you can avoid macros more often. The nice thing about C++ is that the use of those language constructs is optional. I.e. if the use of a certain language construct in a certain spot of your program has a serious performance impact on your program the solution is simple: don't use it.
"Overall this will end up one of two ways: 1) it will fail because C++ is too slow or 2) it will succede because he uses C++ only for what advantages the syntax can provide him without being trapped into the glitzy (and mostly useless) constructs that make C++ about as speedy as my grandmother on a cold winter day."
I would go for number 2 and would like to add the prediction that if this thing is designed in a proper way, performance might actually be better than the old C version.
One of the arguments for reimplementing was that the current version is so complex that there are only a handfull of programmers who have enough knowledge to make non trivial changes to the code. A nicely designed C++ version of Perl could change this. An example of an increasingly successfull C++ implementation is Mozilla. It is fast, well designed and progressing really fast.
This discussion seems to be drifting in the "you can do anything in C" direction. While this is certainly true, it does not mean that C is the best solution for everything. Most perl users at least wouldn't dream of using C for the stuff they normally use perl for. Why?? perl is a better solution for their problem.
Likewise, C++ is a good language for large, complicated software. It's OO features allow for better structuring of the programs, and its C inheritance allows for performance optimizations should they be needed.
"Along those lines: I heard a good joke recently. A JIT compiler for Java that claimed to run code "just as fast as C++"! I laughed for minutes. Then I cried when I realized that this will likely work as an add campaign. Sigh."
You'll be crying a lot in the coming few years. Probably Java is not a good solution for implementing perl right now. But I wouldn't be surprised if it becomes an option in a few years. Perl is used mainly for server side processing of scripts. Good performance is essential there. Java has been coming quite nicely in this area and can be expected to improve even further the coming few years.
from the article: "I finally realized that Perl may be competing with Java in the problem space, but when you're writing Perl, implementing the Perl runtime, really what you're doing is something equivalent to writing a JVM. You're writing the equivalent of a Java Virtual Machine. Now, would you write a JVM in Eiffel? I don't think so. No, so neither would you write the Perl runtime in Java or in Eiffel"
While this may be true, implementing Perl in Java would mean that pearl benefits from all the optimizations in the Java vm (that would otherwise have to be implemented in the C++ version of perl). It would also mean that Perl would benefit from the portability of Java. One major advantage of a Java implementation would be that it would be far easier to maintain than a C or C++ implementation.
Re:perl in perl? (Score:1)
Yes, I believe this is a clever plan.. does anyone have any qualms about committing genocide using Recursive Perl?
Re:So what's it in ATM? (Score:1)
sheesh.
Re:Who remembers... (Score:1)
Oh dear! (Score:2)
One application I had a lot of dealings with was re-written in such a way, and was so buggy that users reverted to the previous version, or went elsewhere. It even caused a number of NT migrations. Unfortunatly the C++ version was the only one that was Year 2000 compatable. I even spoke to the head of support at the UK end of the company - he did not admit there were any problems, probably to save his job. The product sucked more than a VAX (thats the UK vacuum cleaner, not a DEC machine!).
Another thing - have you seen how much memory gcc uses when compiling C++? With the sudden rise in memory prices I may not be able to compile perl6, as I won't be able to afford the extra gigabyte of RAM required!
Please, please, please don't do it.
So what is Perl written in now? (Score:1)
Re:Who says C++ is slow ? (Score:1)
Re:So what is Perl written in now? (Score:1)
Re:There are other languages... (Score:1)
Of course the problem of where to get his programmers couldn't have anything to do with his choice.
Re:Hmm.. (Score:2)
C++ slower than C != C++ cannot be faster than C (Score:2)
Having written in both, I can tell you that I am able to actually write faster code in C++ than in C, not to mention that I make MUCH fewer stupid mistakes because of better type
checking etc.
Remember that C++ is a semantic extension to C. So whatever C can do, C++ can do it too. There are two possible places where C++ can beat C: 1) inline functions and 2) using const reference parameter. The first can be solved using macros or compiler-specific inlines.
Based on my experience, the reason why some people find C is bigger than C++ is because the C code is written in a 'neat and tidy' fashion. C will punish you for this. If you want to write elegant code and want the compiler to figure out how to generate this efficiently, sometimes it is better to use C++. This phenomenon is similar to the case when assembly coders start to heavily use macros to make their code look neat and tidy, and later found out that it is much bigger than a C equivalent. C will look through the macros, and do proper register allocation and topologically sort the expressions for you.
You can use C++ as efficiently as C if you don't use the extensions. When you do, it MAY start to kill you. At best, it will simplify code writing and maintainence for something you can manually code in C anyway. Case in point, GTK. At worst, you end up with code bloat because compilers are either immature or there are semantic constraints that prevents it from doing further optimization, which can easily done by human inspection.
Kernighan/Ritchie designed C based on what they can generate in assembly. Stroustroup designed C++ based on what he can generate in C. There is going to be some efficiency in C++. So you have to ask yourself what is more important, ease of coding and maintenence (C++), or efficient and deterministic code (C)?
Hasdi
Re:There are other languages... (Score:1)
Re:It's slow enough already... (Score:5)
Early OO systems did a lot of runtime message passing, so they _were_ slow. C++, on the other hand implements a lot of the OO paradigm at compile time for more speed.
Virtual function DO add a table lookup each time they're called, but this would only have any effect during a tight loop. And you don't have to use them if you don't want them, but they do provide the benefit f reducing the need for type unsafe downcasting.
The other argument I've seen about C++ has to do with it somehow not being as "close to bare metal" as C. This impression comes from the fact that C++ does a lot of weird things like construct temporary objects to fit an object into an expression where it otherwise can't be used. Of course C does this too; if f takes a float and i is an int, then in the expression "f(i)", C constructs a float out of i for you. The difference is that C++ allows you to create bonafide first class types.
If you don't want temporary objects constructed, code around this problem. After all, in C++ you can always define both f(int) and f(float), but in the end it won't make any difference because most of the time you'll be doing the equivalent conversion in the function anyhow.
A lot of the hot opinion about C++ "inefficiency" reminds me of all my CS professors who used to say as an article of faith that "recursion is inefficient", and then go on to code elaborate ugly iterative algorithms to get around this. Well, one day I went home and ran a few algorithms through the profiler, and guess what? Most of the time there was no difference, and some of the time the recursive algorithm was a tad faster.
You can't trust your intuition about what is fast and what is slow. So, profile your code. If a virtual function or constructor for a temporary is taking a lot of time in a tight loop somewhere, optimize just that one piece by coding around the problem. Usually performance problems tend to be in a very tiny fraction of code.
I think that a lot of bad C++ comes from the fact that some programmers can't effectively use the extra flexibility that the language provides. They say if all you have is a hammer, every problem looks like a nail. If you have a hammer and a screwdriver, you're not in any better position unless you can tell the difference between a nail and a screw.
In the end, I personally prefer C, because I find it small and elegant. Look at how thin K&R is! C++, because it exposes so much language definition machinery to the programmer, will never be as elegant, but it is nonetheless in most respects very well thought out.
Re:It's slow enough already... (Score:2)
Early OO systems did a lot of runtime message passing, so they _were_ slow. C++, on the other hand implements a lot of the OO paradigm at compile time for more speed.
I have to agree with you on this one. C++ is probably the fastest OOPL around. You can code OO is C but it gets ugly. Stroustroup wants the code to be as elegant as other OOPL but can be as fast as C. That's why you have virtual, inline, const, and static keyword cluttering the class declaration.
The other argument I've seen about C++ has to do with it somehow not being as "close to bare metal" as C. This impression comes from the fact that C++ does a lot of weird things like construct temporary objects to fit an object into an expression where it otherwise can't be used. Of course C does this too; if f takes a float and i is an int, then in the expression "f(i)", C constructs a float out of i for you. The difference is that C++ allows you to create bonafide first class types.
You are forgetting that class==private struct! At this point, a lot of compilers optimize ints and floats using automatic register allocation. Struct and array is usually implemented as a pointer to a memory on the current stack frame (Although since struct is well-bounded, there are optimization opportunity not in arrays). A C/C++ does not *care* how many temporary ints and floats you have, it will weed them out! struct/class temporaries always are spilled! You don't believe me, encapsulate your ints into a 'class Integer' and floats into 'class Float' and overload operators accordingly. Compile -O3 an arithmetic intensive functions one using pure ints and floats and the other substitute with 'class Integer' and 'class Float'. get code size using a dump utility. QED.
A lot of the hot opinion about C++ "inefficiency" reminds me of all my CS professors who used to say as an article of faith that "recursion is inefficient", and then go on to code elaborate ugly iterative algorithms to get around this. Well, one day I went home and ran a few algorithms through the profiler, and guess what? Most of the time there was no difference, and some of the time the recursive algorithm was a tad faster.
I know what you mean. That's what they say at Ann Arbor too. Some professors are either misinformed or either doing a poor lip-service to real gurus. Instead of using recursion, they wrote an iterative function with handcoded stack. They made the stack dynamic, extending their sizes using malloc() and free()!
So what is wrong with the picture? The iterative function is poorly written. 99% of the time, the reason why recursive function is slower is because of the call/ret overhead and function header/tail overhead. If you replace this with a cmp/jmp, you will get much better performance, hence the endorsement for iterative functions. If you start using malloc() and free(), you are making the problem worse!
If you want to optimize something, don't look at the C code. Look at how the code is being generated. A smart compiler can automagically convert a recursive function into an iterative one, if it is tail recursive.
Enough ranting for one day. Back to work.
Hasdi
Old versions of Perl a serious prob @ Fortune 500 (Score:3)
We run Perl5 in development but have been working very diligently to get it approved for prod, which currently uses v4. In my travels writing Perl code for Fortune 500 companies, this is a much more serious impediment to acceptance than the majority of Perl users realize. My largest clients are commercial banks and brokerage houses, and you constantly find machines at these places running versions like 5.002 or earlier.
The normal reaction from a Perl user at an ISP or an academic institution is that the people running that system must be really dumb or must not use Perl. This is not the case.
Many consultants like me and the software development staffs we work with are not the people that decide which development tools are used. These decisions are made by people at the Chief Technology Officer level at many companies. They tend to spend most of their time evaluating Closed Source Software because this is the software that is promoted through the corporate IT news, sales, and marketing channels.
OTOH, software that is actually used, like Perl, is considered an ancillary part of the UNIX OS build that is installed on each Sun, HP, or IBM server. The geeks in the back room often have to resort to civil disobedience in order to get a new version of Perl approved and installed.
Sorry if this seems slightly off-topic. To tie it back to the discussion about Perl 6 I would have to say, with all the new features we would like to add, we in the community need to re-double our efforts at advocacy. We need to do a better job of identifying places where obsolete Perl versions are still installed, and figure out ways to remedy the situation.
Violent Agreement (Score:2)
My point was not to detail the "splintering" but to indicate that it took place, and represents cause for the lack of stability of C++ on Linux.
I certainly agree that the now-much-better implementation results from the EGCS efforts.
Mmm.. (Score:2)
Kill paranthesized section and subsequent comma, and you get a little closer to my point. I wasn't attempting to take a historical look at OOP in general, just it's recent widespread popularity (with regards to C++ vs. C).
One might even say less useful. Java hurts my mind, yet C++ doesn't, so the term "unwieldly" is merely an opinion (well, it could be considered a documented fact in the case of certain languages.. but certainly not among the languages of choice), which is why I said "some" people might find it to be so.
Besides, C++ isn't so much a procedural/OOP hybrid as that it allows you to use C within C++ (though if you do, you are clearly missing the point of using C++ in the first place.. unless you have a real good reason for doing such a thing). Yes, Java lets you "play it safe" (and I won't even go into Objectionable C), but it sacrifices a bit of power and versatility. I'll take the power and versatility, thanks.
An excellent point, though I don't see how this debunks the notion that encapsulation, and subsequent ease of code maintenance, is not a primary factor is the widespread acceptance of OOP and/or C++.
Polymorphic objects in persistent storage (Score:2)
Secondly, you can still hack outside of the C++ language to mess with objects' vtable pointers. It should be possible to wrap up this ugliness in a module that can be adapted for various compilers.
Re:Old versions of Perl a serious prob @ Fortune 5 (Score:1)
David
Re:C++? Take a *good* language! (Score:1)
This might make the language design easier to understand, but at the same time it would make the generation of the interpreter (should I say virtual machine, to be current?) more complex. That shouldn't be a real problem, since it wouldn't need to be done often.
But given this line of thought, perhaps the Perl in Perl thread earlier should be the way choosen.
Why C++... (Score:3)
But for a big, non-nuts and bolts project like perl, C++ has a few important advantages.
1. OO. I think this is obvious. Of course you can do OO in C, and C++ doesn't garentee a good object model, etc. But it is less work, "cleaner", and requires fewer dodgey practices like macros to make things work. Additionally, there is far more tool support for doing OO in C++ as opposed to C.
2. Templates/generic programming. Now that there is a cross-platform compiler that does these relatively painlessly (ecgs/gcc3), Open Source C++ programmers should have no qualms about exploiting this feature, as they have in the past. What do templates give you that macros and typecasts don't? Well, first of all, type safe containers. That means you can't add a string to a list of ints. It won't even compile. Compare this to the best C containers, which can only catch it at run-time (with a performance hit). If type safe containers aren't enough, the C++ standard template library gives you iterators. To make a long story short, iterators allow you to write container independant algorithms. Your sort routine will run on a tree, a hash, a list, a vector, etc. Try doing that in C without enough casts and macros to sterilize a rat. And of course, the STL comes with nice implementations of most of the well-known algorithms you are likely to need.
3. Exceptions. Exceptions are simply a more elegant way to program, as any Java programmer will tell you. It nicely solves the ever-recurring problem, "How do I return both an error code and a result?". No more if (foo() == -1) return -1; everywhere and wondering if returning TRUE means success or failure.
In summary, C++ isn't for everyone or every project. But it has some nice features that make it nice for large projects.
Re:Can't argue with that.. (Score:2)
> Just be careful which circles you swim in when you say things like that. I'm sure a lot of zealots would refer to such a thing as blasphemy.
Er... Direct quote:
"To those who merely like it, Perl is the Practical Extraction and Report Language. To those who love it, Perl is the Pathologically Eclectic Rubbish Lister".
Camel book, p. xi
Kaa
dot = concatenation operator (Score:2)
$onetwo = $one.$two;
and:
$blah = $one.scalar($two);
This becomes less of a benign "feature request" and more of a fundamental change in one of Perl's more frequently used operators.
Granted, you could make the distinction by looking for whitespace near the . (e.g. $blah = $one . scalar($two);), but you would still end up breaking a significant number of scripts. Plus it's less obvious when you see $one->{$two} versus $one.$two versus $one . $two. Also, how do you distinguish between $one->{'item'} and $one->item (a method)? Use paranthesis? Things get complicated.
. . . but (Score:1)
"The number of suckers born each minute doubles every 18 months."
Re:So, what do we mean by C++, exactly. (Score:1)
<>==<nbsp;>
--
A host is a host from coast to coast...
Can't argue with that.. (Score:1)
Just be careful which circles you swim in when you say things like that. I'm sure a lot of zealots would refer to such a thing as blasphemy. Personally, I don't care, but I would rather it remained named Perl (and I'm sure it will, unless someone assassinates Larry ;). Hee hee..
Re:So, what do we mean by C++, exactly. (Score:1)
--
A host is a host from coast to coast...
Re:Overcomplex & underpowerful ??? (Score:1)
Granted, C++ and Perl are overcomplex and have exception-ridden syntax, but underpowerful?
IMO, a big part of C++'s problem in terms of complexity is that offers many weak constructs rather than a few powerful ones. Thus you need to learn a new syntax for each partial solution and then when they run out of steam you need to combine them in patchwork fashion to solve your real problem. This makes it much harder than it should be to do clean design and reason about your system.
Let's take C++'s approach towards polymorphism. It gives us templates, virtual functions/inheritance, and function overloading on the argument types. Each of these is an ad-hoc solution to a piece of the larger problem of supporting polymorphism, and in a well-designed language there would be a unified mechanism for all of these things. (Objective CaML, Cecil, and Dylan are two examples of languages that are of comparable performance to C++ but exhibit much better design.)
The standard objection to this line of argument is that this is all just syntactic sugar, and that a good programmer can write elegant code in C++. This is IMHO true but vacuous; since all computer languages are Turing equivalent, all the differences between them are essentially a matter of syntactic sugar. And since I don't see many systems written in Intercal, I think that the differences are of practical importance.
Re:Bootstrapping Through Another Language (Score:2)
That's not the only problem; the other critical issue is that of Foreign Function Interface. Perl presently offers the opportunity to connect in libraries with C interface plumbing, which requires that the implementation language be fairly deeply compatible with C.
That being said, if there was a good compiled Scheme or Lisp with a bunch of back ends (arguably, the way to do this would be a Scheme front end for GCC), this would in fact represent a fast option. It is a longstanding fallacy that "Lisps are Interpreted." That may have been true 20 years ago, and was particularly true with David Betz's XLisp, but isn't a truthful statement.
Perl succumbs to marketing forces (Score:2)
Great. So now development of Perl is driven by least-common-denominator capabilities just so they can say "It works on Windows!" I thought the whole thing behind open source projects like this was that decisions could be made on technical merit rather than what some marketroid decided the software needed to be able to do. Or is that turning out to be just a myth?
Chip could have at least phrased that statement a little different to say something like, "We just want to make sure it works with Visual C++ so we can support Windows" rather than the "We're basing it on Visual C++ because we think supporting Windows is much more important than using a compiler where bugs really get fixed on a stable platform the developers really use" implications of the way he stated it.
-=-=-=-=-
Compilers and ANSI.. (Score:1)
Re:Mmm.. (Score:1)
I didn't intend to debunk this notion, but rather I intended to offer a slightly different perspective on it. In my view OO(P)'s success results from it being the right tool for more jobs than procedural modelling/programming ("if all you have is a hammer, every problem looks like a nail"). Encapsulation just a part of it (as is e.g. the notion of inheritance) and the easier code maintenance is also because the program is more similar to one's mental map of the problem domain than a procedural program for the same problem.
Compilers and ANSI.. (Score:1)
A number of C compilers still don't conform to ANSI. I've noted that they aren't in very widespread use. Personally, while I'm in love with the idea of Perl being rewritten in C++, I'd rather it was fully ANSI/ISO compliant. I could just about smack Chip across the face for even thinking thoughts about Visual C++. (am I the only person who thinks MS Visual anything is simply a Bad Idea?)
Big deal (Score:1)
-- Peter Piper
Re:Let the language wars begin! (Score:1)
Now...I'm gonna go watch an old movie on my Betamax...cause VHS sucks.
Re:"Topaz" is a nice name (Score:1)
a software product by that name.
They( Software Science) have been making TOPAZ
for DELPHI (on PC's)for quite some years now.
Check out their Web site:
http://www.softsci.com/
Scott
Re:PERL ? (Score:1)
A Few Questions (Score:1)
I could not access the link in this article so I may be asking questions that may have been covered.
1. Why undertake such a huge task of re-writing a proven language ('s interpreter) in another language instead of cleaning up existing C source?
2. What are the benefits of using C++ to do this as opposed to C?
3. What is bootstraping?
4. I think [?] that PHP4 was a complete re-write of the interpreter of the PHP language, while remaining backwards compatible with most PHP3 code. This seems to have been a dramatic advantage, and did not seem to [?] take all that long to accomplish. Can the re-write of Perl be compared to this?
5. What is Larry Wall's opinion on this?
Please be a little descriptive, for my sake at least. :-)
Re:Stability (Score:1)
STL seems to work fine. It now supports default template arguments.
I even use it in thread code without trouble. Of course, you need to use a synchronization object
when one thread inserts items into a list and another removes them. The synchronization objects I use (CCriticalSection) are not portable. But there are ways to create classes that
hide the OS implementation.
We just have no need to port the code to Unix/Linux at work.
I learned STL on G++ and started using it with MS VC++ 4.2 (using explicit allocator template args).
At work, we are getting ready to migrate the changes needed from VC++ 4.2 to VC++ 6.0. This mostly involves adding "using namespace std" in
a lot of places.
Folks who argue that C is more portable seem to forget about things like configure, autoconf, automake, and the ever popular #ifdef, #else, #endif.
C and C++: Pros and Cons (Score:5)
I've been a software engineer for 13 years. My first exposure to C came during a junior year course, Survey of Programming Languages, at ULowell, now UMass/Lowell. Once exposed, there was no going back. I was hooked. IMHO, it was so much better than Pascal. Once exposed, my Turbo Pascal went back to the bookshelf, never to be used again.
My initial exposure to C++ came during my senior year. I was enrolled in a compiler design course and the professor was a Modula-2 fanatic. Since half of the class were budding C gurus, he relented and allowed us to use "this new language", C++. We shelled out the $$$; he went to the Harvard Coop to buy copies Stroustrup's book.
I was impressed by the differences between C and C++. I particularly liked the organizational improvements that class definitions had over struct definitions. I found it a joy to code.
The project for the course was to build a Pascal-subset compiler. We couldn't use global variables and all functions, except for the tokenizer, had to fit on one page of hard copy printout. At the end of the course, he ran informal benchmarks for our compilers in terms of output size and compilation speed. My C++ compiler was the fastest and 3rd in efficiency!
Fast forward to the real world. After working for Omtool and Phoenix Technologies coding C and x86 assembler respectively, I worked as chief software engineer at Image Concepts. As chief software engineer, I was to design and develop their image cataloguing database product. To do so, I had the freedom to pick and choose the development tools and platforms for development. Since our product was slated to run on Unix/X11, Mac System 7 and Win3.x systems, I chose C. Again, portability, and the fact that Unix shipped with free compilers and Image Concepts was a very small company...
Once I started working at Pegasystems, after 6 years at Image Concepts, C++ became the language of choice, both for day job and night coding. Why? Code organization. Even though I wrote my C code in a C++ style, first argument to functions written for a particular struct was a pointer to a variable of that struct, C++'s constructors, destructors and exceptions made error management much, much better.
Typical C function (pseudo-code):
open file
if error: return
alloc memory
if null: close file and return
read from database
if error: free memory, close file and return
do something else
if error: yada, yada, yada...
C++:
open file object
if error: return
init buffer object
if error: return (file object destructor closes file)
read using database object:
if error: return (buffer object frees memory, file closed)
-or-
throw exception on error, which will also call destructors
You get the idea. When using C, I spent more time writing error management code than writing the algorithm. Worse, the algorithm was hidden amongst the error checking and management code. In C++, I build my libraries of well-designed classes and exceptions and, wow, you can actually see the logic. What a concept!
C++ isn't perfect, particularly some implementations. However, now that the language has been standardized, it should become more portable.
Languages are tools. We use them to design apps. We use the compilers to build the apps. Some are better than others in some areas. Each has a place. I use C++ for systems programming. I use Perl for CGI programming. For pattern parsing and portable scripting, Perl gets the nod. For outright speed, C++ gets the nod.
Is C better than C++? Vice versa? Is Java better? Is C++ purely OO? Does it really matter? Just pick a language, write the app, and distribute your work and add some value to the computing community at large. 'Nuff said.
One caveat to note regarding C++: templates and shared libraries are a bitch to implement well, that is, if you don't want multiple copies of stack scattered throughout your libraries. Both Visual C++ and Metrowerks CodeWarrior had ways of working around this, to have stack in one library and have other libraries link back to the first one, but the syntax each used were extensions off of standard C++. I don't how G++ will handle this.
Hmm.. (Score:3)
Might I inquire what would give one such an impression? C is covered by ANSI standards, and so is C++ (not to mention, yay! ISO!), which means just about any compiler worth anything can compile perfectly ANSI compliant C or C++ code. Both are just about the epitome of portability (unless you count Java.. but you know, I don't feel like it), which aside from their being quite powerful languages, is what makes them languages of choice. C being a subset of C++, etc.. I'm not sure what would cause one to think of C++ as "less stable". Perhaps I'm not understanding the question? After all, it is rather early..
And since C++ is object oriented, it's a lot more.. useful.. in most situations than C. C still has its uses where C++ would be considered blatant overkill, but for anything that's going to be complex enough and is going to need to evolve a lot, C++ is the better alternative.
It's slow enough already... (Score:5)
adhoc programming without order or system. Now
we look at it and we are scared. So we will just
drop everything we'v done and rewrite this whole
thing in some other language. We hope that objective nature of C++ will solve the problems
we as programmers cannot resolve (such as writing
a good structural code)."
Well, it won't... It will be slow as hell, Perl
not being a jetrocket now will be worse then your
java in Netscape on a 486:) And if they can't
keep their code neat - no OO language is going
to save them...
Sad..very sad.. they are smart people but that
doesn't necessarily gives discipline.
Why C++? (Score:5)
Why not use C? Certainly C does have a lot to recommend it. The necessity of using all those weird macros for namespace manipulation, which I'd rather just use the namespace operator for, and the proliferation of macros are all disadvantages. Stroustrup makes the persuasive argument that every time you can eliminate a macro and replace it with an inline function or a const declaration or something or that sort, you are benefiting yourself because the preprocessor is so uncontrolled and all of the information from it is lost when you get to the debugger. So I'd prefer to use C++ for that reason.
Macros are the reason to dump C for C++? Woah, I got off of perl5-porters way too soon. Not to start a language war or anything, but this article read like a C++ lovers manifesto, not a reasonable set of excuses to use the language to re-impliment one of the most powerful and stable interpreted languages ever.
If you want a clean object model, just look at GTk+. If you want to eliminate macros just use inlines. Most people have a hard time with the idea of building inlines in header-files, and I don't blame them, but that's how you're going to end up doing it in C++.... And, don't try that "inline isn't in most C compilers" because most OSes don't ship with a C++ compiler. If you say that you can just buy one or get GCC, then the one you buy will almost certainly also be a C compiler that handles inline, and gcc supports inline (or __inline__ if you have -ansi turned on).
OTOH, macros are a good thing. Yep, I said what you thought I said. When a macro performs only a simple syntactic transformation, that's fine. I've never once been caught by such a thing. When a macro is a few lines of code, you've failed to correctly design your program, and I've lived in debugger-hell for that one. I can certainly see the value of consts over macros for variables, but that's not even something that's hard in C.
Overall this will end up one of two ways: 1) it will fail because C++ is too slow or 2) it will succede because he uses C++ only for what advantages the syntax can provide him without being trapped into the glitzy (and mostly useless) constructs that make C++ about as speedy as my grandmother on a cold winter day.
Along those lines: I heard a good joke recently. A JIT compiler for Java that claimed to run code "just as fast as C++"! I laughed for minutes. Then I cried when I realized that this will likely work as an add campaign. Sigh.
perl in perl? (Score:3)
Yet another new version (Score:1)
But yes, this is great news and I can only hope they can make a great thing(tm) better with more functionality.
-Vel
Perl and C++ (Score:1)
Why does writing Perl in C++ not make sense to me?
It's a natural fit! Consider that C++ is a systems programming language with an arcane and exception-ridden syntax and a semantics that is at once overcomplex and underpowerful, and that Perl is a scripting language with precisely the same design. :)
I suppose the corresponding effort in the Python world is John Max Skaller's attempt to reimplement Python in Objective CAML. You may draw your own parallels between size of OCaml's user base and Python's.
Stability (Score:4)
- There not being a normative standard.
- There not being a good free compiler.
- Interoperability of LIBC++ versions has not been real good.
What this adds up to is that C++ on Linux has had some fairly severe handicaps. Several are no longer in effect; we'll see if this allows C++ to "get up and walk."That became untrue a year or so ago, when the ANSI C++ committee released the "final" standard.
G++ only fairly recently has started to be both "reliable," "correct," and "nearly completely conformant to standard."
The gyrations between GCC and EGCS, which has recently become GCC, did not help.
The claim is that there shouldn't need to be Yet Another Noninteroperable Version of the GCC libc++ library; I'm inclined to wait six months and see...
(My personal suspicion is that there may continue to be some LIBC++ gyrations for a while...)
That doesn't explain... (Score:1)
---
Re:Who remembers... (Score:1)
Re:Stability (Score:2)
I'm the coordinator of the Free Trek project, which is a space battle simulator intended to run at the very least on Linux and Windows computers. The project uses C++, compiled by G++ and Visual C++ 6.0. It has been tremendously difficult at times getting VC++ to work properly with the code, mostly due to the brain damaged Standard Template Library that ships with VC++.
The STL that comes with VC++ is based on the Hewlett Packard implementation which is old, and not thread safe. In my experience, VC++ will not even compile that old STL without a pile of errors which are nearly impossible to fix. I found an STL implementation called STLPort (http://www.stlport.org) that does the job, but it was also somewhat difficult to get working even with the latest Microsoft compiler and all the patches. The good part of that implementation is that it is a modern implementation based on the SGI code (which is in turn based on the HP code), and it is thread safe. The Free Trek distribution includes a configuration file for STLPort which can be dropped right into the STLPort distribution for VC++ compilation. It is not entirely obvious how to compile STLPort with VC++, and it certainly doesn't compile properly out of the box. With our config file, it will.
They are right in pointing out the G++ is pretty much standards compliant right now, and that they will have to limit their usage of the standard to what VC++ supports. If they use the STLPort library, then those problems will be minimized. One of the developers on the Free Trek project uses the Metrowerks compiler, and he seems to have a great deal fewer problems compiling the code.
So, based on my experience, I'd say that C++ on Linux is really excellent right now, and whatever kinks might exists should not exclude C++ from being chosen as a development language when it is appropriate for the project. Only if you are going to be maintaining a Windows port will you run into problems. I'd have to say that Free Trek has hit most of those problems already, so if anyone writing the Perl code gets stuck with something, please send me an e-mail. I might be able to help you out.
Re:C++? Take a *good* language! (Score:2)
1. Perl is already written in C. C++ gives you an easier migration path from C than other languages. You can gradually move the program component by component. The C++ parts can freely call the C parts and everything is linked into a homogeneous whole.
2. Speed. Perl is a interpreter for a programming language. Moreover, it is widely used in practical applications. So it deserves to be written in a systems programming language that is statically typed and translates to reasonably efficient machine code.
Re:Stability (Score:1)
The fact that the two groups have re-merged and adopted the EGCS compiler as the standard GNU one just shows how well the Darwin model of free software development works. Again, the ability to temporarily fragment the code base allowed the code base as a whole to become better and more reliable than it otherwise would have.
99 little bugs in the code, 99 bugs in the code,
fix one bug, compile it again...
Re:Why C++ ? OpenC++ instead... (Score:1)
C++ is a good tool when used properly. It sounds like C may be 'easier' in this case though, as the current sources reside there...unless the architectural change is needed.
Re:It's slow enough already... (Score:2)
There have been a lot of statements along the lines of 'C++ is slower than C'. After being puzzled by where this perception came from, I realize it came from Visual C++ development under Windoze. This end up being slow there becuase of both the pressure people in that environment are under, and the slow and badly designed nature of the function call libraries masquerading as an OS that they have to work with.
In my experience C++ is as fast, or faster than C.
Sure, virtual functions impose a tiny bit of overhead. So does RTTI. Exceptions also introduce some overhead, though implementations are getting better.
The speedup doesn't come from using these features directly. It comes from the flexibility afforded the programmer. Want to switch from using a list to using a tree because you discovered that your list is unexpectedly holding thousands of elements instead of the expected few dozen? No problem. Want to have a more elegant and faster way than a switch statement of picking the right thing to do for a particular type of data? No problem.
And that's just a sampling. Done correctly, C++ both leverages optimization efforts and makes them easier.
I find this dislike of C++ in the open source community to be very upsetting and distressing. It puzzles me how a bunch of people who claim to have open minds can reject a language out of hand that is so obviously useful and worthwhile. One can only suspect that the declaration of open mindedness is a facade and that they're horribly afraid of learning anything new.
PS. To me, GTKs main disadvantage is that it isn't written in an OO language. I though that people, after seeing what a cock-up Xt is, would've known better.
Topaz is supporting VC++ too early (Score:1)
If I were Chip (which I'm not) I would barely give a moment's thought to the Visual C++ port at this stage. Yes, Perl needs to run on Windows. But GCC works fine on x86 Win32, and I'm not sure Windows plans to support any non-Intel-types in the future. Well over 99% of Perl users on Microsoft platforms will never compile perl.exe and don't care what compiler built their binary. And if M$ considers Perl worthwhile (which it seems to), it'll take care of its own. Even if the first stable Topaz works with Visual C++, I bet M$ will rewrite it to ``take advantage of Windows features''.
Re:Perl succumbs to marketing forces (Score:1)
How about /this/ part of the article..? (Score:4)
I believe difficulty in code maintenance with languages such as C was one of the primary reasons for the spawning of object oriented programming languages (complex and sometimes unwieldly though they may be to many), such as C++.
Who says C++ is slow ? (Score:3)
If you use features such as polymorphism or RTTI, of course you get a performance hit, but if you try to implement the same things in C manually, you won't get any better results.
Slowness of the program comes from sloppy programming, it has nothing to do with the language.
Why NOT C++? (Score:2)
My C++ is admittedly rusty, (I moved on to Java three years ago), but I don't recall any performance issues. I do remember being completely screwed by over-enthusiastic use of operator overloading, virtual base classes, fancy conversions, and especially templates, but not performance issues.
You say that it's the C++ glitz that makes the language slow. Exactly what features are you referring to, and what sort of performance penalty is incurred?
If I had to write C or C++ again, I would definitely want to use C++ (performance permitting), but I would be much more selective about the features I used.
So, what do we mean by C++, exactly. (Score:4)
For instance, if I write something using MFC (CMapStringToPtr or the less disgusing CMap template) then, well, it isn't real C++ is it? I won't be able to compile it anywhere else. I'll be stuck with that god awful library.
So you start using STL, beacause it's ANSI'd and open and designed by adults who knew what they are doing. You go looking for (and find) a convenient map template and in the process notice templates for near as dammit everything else! Strings, memory allocation, streams, the whole enchelada.
So, to be *real* C++, should I only be using the stl library, doing #include "string" and only stretching as far as #include "cstdio" when I feel a nasty hack urge coming on? Can I say goodbye to the happy days of getting a char* to the first byte and bouncing along the string until it dereferences to zero? Do I, in short, have to clean my act up?
And to what extent do other major C++ projects do this, especially given the relative newness (in terms of C++ standardisation) of the STL?
Dave
(offtopic note) MFC is horrible. Immense kudos to the ATL team for a fine piece of work.
I know they should be angle brackets, couldn't remember the HTML to make the browser not think they were tags. At least I previewed.
A perspective from a perl porter (Score:3)
Basically, the internal datastructures are hoary. They're awful to dig through, and even worse to try and modify. Even writing external modules for use in perl can be horribly nasty because of the structures involved, the reference counting, etc.
I'd say at this point there are about 10-20 people (at most) who are competent to go and change the guts of perl. That's not a large number, especially when they don't have all that many tuits.
One of the prime motivations of rewriting perl in C++ is so that things will be modularized so that the knowledge barrier is greatly reduced. Right now, you need to know how _everything_ works before you can modify _anything_.
I'll be quite glad to get rid of things like
return sv_2mortal(newSVpv(ret,len));, thank you very much.
There are other languages... (Score:3)
How about, say, Sather [berkeley.edu]? A clean, fast, free (libre and gratis), object-oriented, garbage-collected language, which (and this is the beauty) compiles into portable C, so you can bootstrap Perl without first bootstrapping Sather. You only need Sather if you want to tweak Perl.
If that's too much effort, then you've basically already made the decision that only C or C++ will do since that's the compiler that machines will already have, so there's not much point in talking about other languages you might have used were it not for that condition. But I think it would be a mistake for free software projects to mandate that only these languages will do - it's not a restriction that proprietary, binary-only releases labour under.
--
Re:PERL ? (Score:2)
Then you should check out the HTML::Mason [masonhq.com] module running under mod_perl. Even though I'm a hard-core Perl advocate, I was a big fan of PHP for web development (until I found Mason).
Very cool stuff...
--