VIncent, I wouldn't look to Stroustrup for guidance about multicore (I'd look to RGB :-) but he defines C++ and the C I use is a subset of the C++ copmpiler (genrally) But yeah, to me C++ is bloaty: compare Stroustrup's gravid classic to K&R's gemlike classic..
I mostly write in C, with the sense that basically it saves me writing in assembly; and most of us, maybe all, use only a subset of C++; which can pare down to K&R (within a whisker) if you like. Something like C with Classes seems like a good middle ground between hierachism for the programmer's comprehension and spare C for the machine's. Peter On 8/25/08, Vincent Diepeveen <[EMAIL PROTECTED]> wrote: > > Well Stoustrup should be the last speaking about multicores, he better > stick to single core. > > Let me explain. > > The experience learns that most C++ code from BIG companies not to mention > organisations is factor 5 to 50 slower > than an imperative implementation. Templates get used to declare variables > and classes are very deep, not seldom > 10 subclasses deep before you actually see a few lines of code doing > something, and you > never know which object gets allocated now and deallocated there. > > Therefore for highend computations C++ is not very interesting. > > Add to that, the C++ standard (iso) where Bjarne has contributed to a lot > (deep respect for that), > costs hundreds of dollars to buy, > so there is no clear hard definition easily available to programmers at > home to figure out the optimization > limitations that C++ allows. To get speed you need to know the exact > borders which compilers must follow. > > int a = 5; > unsigned int x = 2; > > if( a == x ) > > how C treats the above is easy. how does C++ treat it? > Do you know? > > To program code for speed you need to know the EXACT limitations of a > language. > Clear definitions, not 5000 pages with what the language all "might be able > to do for you". > > No one who learns at home is gonna pay to get that ISO of course and the > language is getting that complex and even more > complex, that programmers who try to learn it are busy half their life > learning it. After many years, just knowing how to code C++, > they already are too old to program a lot and feel ready to become > teamleader or manager. This is because C++ is the most > complex programming language on the planet. It has changed. I've got some > C++ books from start of 90s here and none of them > mentions things like templates. > > The C++ from the 90s was very useful for companies, had it been > standardized sooner. > > Bjarne made c++ too complex however. > > College students who start C++ now, directly start using templates and > never learn how to actually DECLARE a variable anymore. > > Object orientation is the opposite of what modern processors are good at. > First of all object allocation and deallocation is real > slow and even the best C++ programmers have problems limiting the number of > allocations that makes their software real slow. > > Additionally putting together code and data, as well as things like > templates, makes code sizes real massive huge. > This where for crunching power we'll see more and more tiny processors > where having a lot of code is just slowing down. > > That said, C++ has basically a number of advantages over JAVA and C#. > Graphical you can do the same in visual studio > with C++ like you can do with c++, so there is no reason to program in C#. > In C++ you CAN incorporate C code easily > as well as compiler intrinsics, even entire assembler programs (gcc). So > you DO have the choice to hire a programmer who > can speedup your code. > > The good C++ programmers who are really good in getting code done, usually > have a low grade highschool, > no university or at most 1 year college or so, if at all and know relative > little about algorithms let alone optimization techniques. > > That's your typical C++ coder. Bugfree code that's ugly slow. > > Over the past years i've helped out dozens of PHD's who didn't know how to > speedup their C++ code at all. Not even where to start. > They know books from Stoustrup from head though and are in the knowledge of > all kind of details. Usually not seldom within days > that results in factor 2 to 3 speedup. > > Writing yet another book with things that even most C++ scares in C++0x is > not very interesting IMHO, and just shows how much of > a nerd a person can become. > > I'd argue there is a big need for a new language that is basically > imperative, where there is mechanisms, but not necessity, > to split code and data, where you can declare anywhere new temporarily > variables, and which has the potential to get the same > speed like C code and where the language constructs are not far away from > C/C++, to get programmers not extra confused. > > So instead of C++ something like Cr with the 'r' of 'realistic'. Something > that is really usable for companies to get fast code > at tiny processors meanwhile compatible with C libraries, which dominate > the open source world, with good reasons. > > So just the basic minimum that you need to make out of C a language that > big companies can use, without losing speed. > > Speed matters for mass software and highend. > > C++, JAVA and C# are just too slow to take a lecture with the below name > serious. > > Instead of trying to standardize the manner how to write a program in C++ > writing in clear statements that all kind of complex C++ > language such as templates should get avoided at all costs, except when it > has a clear benefit that other simpler straightforward code > doesn't offer the opposite is gonna get spoken out in the speech. > > What happens now with C++0x is yet another nerd addition to make worlds > most complex language even more complex. > > Vincent > > On Aug 22, 2008, at 6:31 PM, Peter St. John wrote: > > In this interview http://www.devx.com/SpecialReports/Article/38813/0/page/1 >> Bjarne Stroustrup talks about an upcoming C++ ISO standard, C++0x (the >> same nomenclature as "C89", "0x" means the specific year is undecided, it >> doesn't mean hex :-). >> >> He categorizes the additions in three ways, Concurrency, Language, and >> Libraries; the concurrency part is about multicore support. >> >> He writes, 'Basically, the "concurrency" features will standardize the >> basic layers needed to do systems programming in a multi-core world. >> Obviously, facilities for doing that already exist in C++ implementations, >> but they are not standardized. I'd have liked to see library support for >> some high-level concurrency models, but the committee didn't have the time >> or consensus for that.' >> >> Peter >> _______________________________________________ >> Beowulf mailing list, Beowulf@beowulf.org >> To change your subscription (digest mode or unsubscribe) visit >> http://www.beowulf.org/mailman/listinfo/beowulf >> > >
_______________________________________________ Beowulf mailing list, Beowulf@beowulf.org To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
