Interesting, Owen. I'm curious what some of D's features will result in, performance-wise. Particularly garbage collection, and the single inheritance hierarchy.
--Doug -- Doug Roberts, RTI International [EMAIL PROTECTED] [EMAIL PROTECTED] 505-455-7333 - Office 505-670-8195 - Cell On 8/5/07, Owen Densmore <[EMAIL PROTECTED]> wrote: > > Sun made use of C++ API's (that customers see) illegal. This was in > the 1995-2000 time frame. > > This was mainly because there was not a good binary standard for > shared libraries at that time that used C++. Also, it turned out > that there were a few studies done about software engineering in C++ > being a failure -- it just took too much time for various projects to > agree on their dialect. Basically C++ at the time simply had too > many ways to do the same thing. Even constructors had oddly > differing syntax and slightly different semantics. > > The Scott Meyers book "Effective C++: 55 Specific Ways to Improve > Your Programs and Designs" .. or as we called it "55 ways not to > shoot yourself in the foot" was the final proof. We simply could not > agree on what the hell all the issues were. > > So Sun decided it was fine to use C++ in isolation. Groups like the > multi media group I headed up for a few years decided on a C wrapper > around a fairly complicated "delegation" system, separating the > implementation from the interface. At the time it was the only way > to do so -- header files simply exposed too much of the > implementation and fouled up our agile programming techniques. It > also had the advantage of making GC simpler: a trivial ref counted > system allowed course grained GC to work very well at nearly no cost. > > This idea of C wrappers became the corporate standard, and folks > really loved it. (Interesting enough, we *did* allow projects to > interface to other project's C++ if they wanted to. Zero decided to > do so. Just memory management could not be agreed upon.) > > This was a sorta win-win situation: groups could use C++ in > isolation, but customers did not have to adapt our protocols and > dialects. And it all worked fine with binary shared libraries. > > I presume all this has been cleaned up. But I remember a long > conversation with Bjarne Stroustrup, who finally gave up saying: But > its not SUPPOSED to be a great OO system, just a better C++. Not > sure its there yet. Scott Meyers is still making a bundle trying to > guide folks around the horrors. > > HOWEVER: There is hope. Look at the D language, for something that > may actually solve all the C++ problems! Here's the usual pointer: > http://en.wikipedia.org/wiki/D_programming_language > > -- Owen > > > On Aug 5, 2007, at 4:07 AM, Russell Standish wrote: > > > C++ is not just an OO language, obviously, but are you saying that it > > isn't an OO language at all? > > > > I use C++ extensively, and use it procedurally, functionally, > > object-orientedly, generically, and often a mixture of all of the > > above, as appropriate for the problem at hand. > > > > I'm aware of C++ negative points (confusion between "." and "->", "[]" > > and "()", ";" needed after class defintions, but not function or > > namespace definitions), but all of these are superficial, and picked > > up by the compiler immediately. > > > > More significant C++ deficiencies... > > > > Generic programming (ie templates) is a bit more of a problem - the > > standard makes the inheritance model somewhat unintuitive. And > > different compilers seem to interpret the standard differently, > > meaning one needs to test all advanced template code carefully on > > different compilers. > > > > But having said that, using basic generic capability equivalent to > > what Java or C# offers, is unproblematic, and useful even to novice > > users. > > > > Finally, there is the renowned memory management problems. This comes > > from trying to program C++ using a Java or a C programming style. It > > is simple to avoid all such problems by using the simple rule "no bare > > pointers". Use a container, or a reference type (either the static > > built in type, or one of the dynamic reference types available in > > boost and/or TR1). The only reasons to use bare pointers is for access > > to legacy APIs (in which case you should wrap it into a C++ type), and > > for performance reasons, which you should only do after your code has > > been fully debugged. > > > > But I would still say that C++ gives me the ability to build more > > complex code, more efficiently, in about a similar or even reduced > > development time to other competitive languages. I couldn't give a fig > > whether it follows a pure OO model or not. > > > > Cheers > > > > On Sun, Aug 05, 2007 at 07:31:12PM -0400, Prof David West wrote: > >> > >> > >> > >> In my book - Object Thinking - I referenced a lot of material from > >> this > >> series of books re: Simula, Smalltalk, and C++ (Java was still absent > >> from the books) to make the point that a lot of so-called object > >> languages were never intended to be such and that the only reason > >> they > >> made the claim was for marketing purposes. And because programmers > >> failed to see why the history, purpose, and philosophy of a > >> language was > >> relevant to using the language, 98% of the programmers still have no > >> clue how to to OO. > >> > >> davew > >> > >> > >> On Sat, 4 Aug 2007 18:53:18 -0600, "Tom Johnson" <[EMAIL PROTECTED]> > >> said: > >>>> From time to time, some of us have expressed an interest in the > >>>> evolution of > >>> various computer languages. Turns our others shared our interest > >>> and did > >>> something about it. > >>> > >>> http://www.oreilly.com/pub/a/oreilly/news/ > >>> languageposter_0504.html --- > >>> The > >>> History of Programming Languages > >>> > >>> -- tj > >>> > >>> ========================================== > >>> J. T. Johnson > >>> Institute for Analytic Journalism -- Santa Fe, NM USA > >>> www.analyticjournalism.com > >>> 505.577.6482(c) 505.473.9646(h) > >>> http://www.jtjohnson.com [EMAIL PROTECTED] > >>> > >>> "You never change things by fighting the existing reality. > >>> To change something, build a new model that makes the > >>> existing model obsolete." > >>> -- Buckminster > >>> Fuller > >>> ========================================== > >> > >> ============================================================ > >> FRIAM Applied Complexity Group listserv > >> Meets Fridays 9a-11:30 at cafe at St. John's College > >> lectures, archives, unsubscribe, maps at http://www.friam.org > > > > -- > > > > ---------------------------------------------------------------------- > > ------ > > A/Prof Russell Standish Phone 0425 253119 (mobile) > > Mathematics > > UNSW SYDNEY 2052 [EMAIL PROTECTED] > > Australia http://www.hpcoders.com.au > > ---------------------------------------------------------------------- > > ------ > > > > ============================================================ > > FRIAM Applied Complexity Group listserv > > Meets Fridays 9a-11:30 at cafe at St. John's College > > lectures, archives, unsubscribe, maps at http://www.friam.org > > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org >
============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
