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
