Slashdot

C++ Answers From Bjarne Stroustrup

Posted by Roblimo on Friday February 25, @12:00PM
from the thoughtful-questions-get-thoughtful-answers dept.
Monday we had over 550 assorted questions and comments for and about Bjarne Stroustrup. Excellent moderation (Thanks, Monday Moderators!) helped cull this mass down to 10 extremely high-quality questions Bjarne has kindly answered in amazing depth, for which he deserves a loud round of applause. Update: 02/28 02:12 by R: Bjarne later took the time to dig through all the comments and reply to some of them. The additional material is appended to the end of the original Q&A session.

C++ Answers From Bjarne Stroustrup

1) Has OO run out of steam?
by rambone

After 20-some years, it's obvious that object-oriented programming is not a panacea. What are your thoughts on the future of the OO paradigm? What other paradigms do you see challenging it?

Bjarne:

Well. It was obvious to me 20-some years ago that OOP wasn't a panacea. That's the reason C++ supports several design and programming styles.

If you like long words, you can say C++ is a "multi-paradigm language," but simply saying "C++ is an OOPL" is inaccurate. I wrote a paper about that "Why C++ isn't just an Object-Oriented Programming Language" (download from my papers page). I presented that paper at OOPSLA - and survived.

In the first edition of "The C++ Programming Language," I didn't use the phrase "object-oriented programming" because I didn't want to feed the hype. One of the problems with OOP is exactly that unscrupulous people have hyped it as a panacea. Overselling something inevitably leads to disappointments.

That said, OOD/OOP is my favorite way of approaching design and programming. It just isn't the right style for every program and for every detail of a program. Some good abstractions are best represented outside class hierarchies. Trying to force everything into a hierarchy - especially into a single-rooted hierarchy - can give truly contorted programs.

I use a lot of simple data abstraction (classes without inheritance) and generic programming (templates and algorithms parameterized on types). However, I don't see these as "paradigms challenging OOP." Rather, they are complementary techniques. The key is always to find designs that fit the problems and use the language constructs that best represent the designs in the code.

Combinations of style can lead to very elegant code. For example,

void draw_all(list& lst)
{
for_each(lst.begin(),lst.end(),mem_fun(&Shape::draw));
}

Here, list and for_each() are examples of the C++ standard library's generic facilities. What they are used for is to invoke a virtual function of a base in a traditional class hierarchy.

You can even write a version of draw_all() that works for every standard container type with Shape* elements:

template
void draw_all(Container& c)
{
for_each(c.begin(),c.end(),mem_fun(&Shape::draw));
}

I chose this example to wake up people who still live in the dark ages and think that C++ is C with a few uninteresting additions.

Naturally, the code generated for draw_all() is as efficient as an list traversal code and the polomorphism used to call Shape::draw() boils down to a call of a function through an array of pointers to functions. The mechanism has been used to invoke device drivers.

New "paradigms" are touted every year, but most are not fundamental and few are genuinely new. Probably the most interesting are those based on "components" such as COM and CORBA. I'm undecided whether these constitutes a "new paradigm" or simply a new set of systems-level building blocks. Would we talk of Unix processes as a new paradigm? Anyway, my main concern with such components is that they are still less than perfectly integrated with programming languages, such as C++, and with the various "traditional" programming paradigms, such as OOP and generic programming.

2) C++ for systems programming
by ajs

C has long been the UNIX-world's systems programming language, and still remains that way. I know you don't like to compare languages, so I'll just ask if you feel that there are any core reasons why C++ either does not make a good systems programming language or failed to capture the interest of the systems C programmers.

Bjarne:

It is hard to teach old dogs new tricks.

Unix was first written 25+ years ago (I first tried in in 1973). All of its interfaces are defined in terms of C function calls, arrays, and structs. By the time C++ became available, there were 10+ years of tradition for almost exclusively using C.

There is no good reason for Unix programmers to avoid C++ and several good reasons to use it. However, there are no end of reasons/excuses offered. Let me list a few:

• C++ is slow
• C++ generates bloated code
• There are no good C++ compilers
• C++ is complicated
• C++ doesn't offer much to systems programmers
• "Advanced" C++ features are unsuitable for systems work
• C++ code isn't portable
• C++ doesn't have an ABI.

These are all either flat wrong or largely irrelevant. Some of these reasons make some sense on other systems (say on a minute embedded system without proper C++ tools), but not on Unix/Linux. Let me briefly try to explain why. Naturally, a complete discussion would take hundreds of pages because it is not possible to prove a negative. That is, it is not possible to prove that there isn't some problem that could be unsolvable for somebody.

• C++ generates as good code as C for equivalent programs. Just try it.
• C++ was designed to do that and current compilers deliver on that promise.

Naturally, you can write poor programs in any language. C++ is a powerful tool and in the wrong hands it can generate code that is *obviously* contorted and bloated. That may be preferable to the traditional spaghetti that poor programmers produce in C. Note that someone who is a good C programmer isn't automatically a good C++ programmer. Many problems have been caused by good C programmers assuming that they could adopt a semi-random collection of C++ language features and then magically become a good C++ programmer in a week.

A C programmer can benefit from C++ in a week, but only by sticking to a subset of C++'s facilities and by using libraries.

C++ supports powerful techniques that are at best weakly supported by C and learning these techniques takes time. C programmers might do well remembering how long it took them to become "master level" C programmers. I see no reason why it would take less time to become a "master level" C++ programmer.

The current generation of C++ compilers is far superior in standards conformance to compilers from a couple of years ago. The optimizers are shared with C. This can be a problem because it precludes some useful optimizations that cannot be done for C, but at least sharing of major compiler parts should convince sceptics that equivalent code it produced.

I'll deal with the roots of language complexity in my answer to question 9. Here, I'll just point out that many of the C++ facilities directly help people who needs to write efficient, reliable, and maintainable code. If you don't use these facilities, you typically end up simulating them with lower-level language constructs.

Even the "new"/"advanced" features of C++, such as templates, exceptions, and run-time type information (RTTI) are designed to meet the 0-overhead rule. If you need such features, it is more efficient (in run-time and memory space) to use them with a modern compiler than to fake their functionality in C. I do not know of a C++ language feature that has not been found useful and affordable by someone in some systems or embedded application.

Naturally, if you don't need a feature (often, RTTI is not needed) or if is unsuitable in a particular context (I can think of programs where exceptions would be unsuitable), you just don't use that feature. The 0-overhead rule is there to allow such decisions. This is not so different from not using a C feature that is unsuitable for a given application (in some embedded systems, malloc() is banned).

C++ is as portable as C. In both cases you need to encapsulate the system dependences to ease portability. Large classes of programs are portable across Unix platforms, and some programs can be made portable across other platforms also. The techniques are well known and when used well, C++ even has an edge when it comes to formalizing the notion of a system to allow trivial portability. For example, see the C++ library that defines the ACE platform (link on my C++ page).

The technical hardest problem is probably the lack of a C++ binary interface (ABI). There is no C ABI either, but on most (all?) Unix platforms there is a dominant compiler and other compilers have had to conform to its calling conventions and structure layout rules - or become unused. In C++ there are more things that can vary - such as the layout of the virtual function table - and no vendor has created a C++ ABI by fiat by eliminating all competitors that did not conform. In the same way as it used to be impossible to link code from two different PC C compilers together, it is generally impossible to link the code from two different Unix C++ compilers together (unless there are compatibility switches).

The current solution is usually a combination of using a single compiler and of providing C-level interfaces. This is not ideal - see also my answer to question 10.

That said, I think the main problem is educational. Many simply have seriously inaccurate ideas of what C++ is and what can be done with it. Often "inaccurate ideas" add up to a strong disincentive to learn. C++ is now very different from Release 1 from 1985. The ISO standard for C++ was ratified in 1998 and current compilers approximate it well enough for me to move programs that stress the newer facilities from compiler to compiler for performance testing on a variety of platforms. The standard library makes a difference here.

3) What would you do differently?
by spiralx

If you could go back to when you designed C++, what would you change and why?

Bjarne:

You can never go back. However, I think my most obvious mistake was not to introduce templates before multiple inheritance and not to ship a larger library with Release 1 of my C++ compiler. The two mistakes are somewhat related.

The reason I didn't ship a library was that I didn't know how to write one that was good enough. To get efficiency and type safety for containers, you need templates (and I didn't have an implementation supporting templates until 1988 or 1989). However, templates are not enough, you also need a design for containers and uses of containers that can deliver that safety. We didn't have such an architecture until Alex Stepanov came along with the STL. If you want a real firework of interesting opinions and insights, read this interview with Alex. The STL is the nucleus of the C++ standard library, providing the standard containers and algorithms, and the framework for their use and their extension with user-defined containers and algorithms. Naturally, this is extensively discussed in "The C++ Programming Language."

One problem with introducing MI before templates was that it encouraged further overuse of class hierarchies. Templates provide a simple and efficient alternative to some of the more contorted uses of inheritance.

Let me just mention something I wouldn't have done differently: compatibility. Had C not been there to be compatible with, I'd have chosen compatibility with some another language. Innovation should focus on improvements and what works should be left as unchanged as possible. That way, people keep their existing tools and techniques and can develop from a base that is functionally complete. Also it saves the effort to re-invent the wheel and to teach "new" stuff that is equivalent to old stuff. Thus, C++ is as close to C as possible - but no closer.

The flip side of this is that you have to deal with old mistakes and with compatibility problems. For example, I consider the C declarator syntax an experiment that failed. Nevertheless, I adopted it for C++. The alternatives and improvements I considered at the time would not have improved matters. I rate is as a minor problem. The more serious problem is to maintain closeness of language definitions as C evolves.

Also, there is no major language feature, I'd remove for Standard C++ - even in retrospect. New major facilities have to be added with care. Often, a library can provide functionality that people thought required language changes.

I think the C++ standards committee did a good job. It is not easy to create a consensus about a specification. Commercially competing companies have to agree and nations with conflicting traditions of standards work have to be satisfied. However, I think that the the time and effort was well spent. Standard C++ is a better approximation to my ideals than any previous version, and a great standard library to go with it. The time and effort is necessary unless you want to give free reign to "de facto standards" and proprietary languages. My 3rd edition describes ISO standard C++ and current C++ compilers approximate the standard.

4) Why no templated typedefs?
by Venomous Louse

Well, this is weird. Just the guy I wanted to talk to this morning!

It would occasionally be handy to have typedef templates (or template typedefs?! help!), something like this:

template< class T >
typedef bool (* func)( const T &r );

. . . but that doesn't seem to be legal. I don't recall seeing anything about this issue in The Design and Evolution of C++. So what's the deal?

Bjarne:

I, and the standards committee, underestimated the importance of templated typedefs. My guess is that they will be added in the future.

Actually, D&E (pg 357) does discuss templated typedefs and points out a technique that is often an alternative:

The extension is technically trivial, but I'm not sure how wise it would be to introduce yet another renaming feature.

Derivation also allows for partial specification of template arguments in the definition of a new type: template class X { /* ... */ };
template class XX : public X { };

I guess that in this case, my reluctance to add new features without a clear practical need caused problems. I'm more often accused of the opposite mistake - to be too aggressive in adding features - but as people learn to use what is available, new requests based on new experience are starting to appear.

Incidentally, your example "function of T returning a bool" is often best represented as a function object. And function objects are natural templates:

template< class T >
struct Predicate {
bool operator()(const T &r) { /* ... */ };
};

This way, you don't need a typedef; you can simply say:

Predicate* p;

Function objects also inline better than pointers to functions, so their use leads to faster code as well as cleaner code.

In general, I recommend "The Design and Evolution of C++" for people with "why is/isn't it like that in C++?" questions.

5) Question...
by MrHat

I (and maybe most of "us") know you solely through your creation of the C++ language and your assistance in authoring the ANSI standard for said language.

Aside from this one (albeit major) project, what do you work on from day to day? What projects are you currently involved in? Do you have any more language definitions/standards in the pipeline?

Bjarne:

C++ related work is a major part of my day. The standard is in "maintenance mode," but it still requires a bit of attention. I do some work related to libraries and programming techniques (I'll have a paper on "wrappers" in "The C++ Report" later this year), and I worry about the poor state of C++ education - and the way C++ is often seriously misused by misguided programmers. Look at me paper "Learning Standard C++ as a New Language" (download from my papers page). As you can see, I write a bit, give talks, and interviews.

In the standards committee, I'm spending most time on the performance working group. This group was created to investigate sources of inefficiency and implementation and programming techniques to deliver "lean and mean" code. Embedded systems is one area where this is needed. The current language allows close-to-optimal solutions, but not every implementation is well tuned for that degree of efficiency, and not every programmer knows the basic techniques for delivering compact and efficient code.

There is - as ever - much talk about extensions and new libraries on the net, but the C++ community still haven't learned to fully utilize the new facilities. My guess is that there is a lot of benefits to be had from better libraries. The Standard library in general and the STL in particular shows some of what could be done. Eventually, some of those new libraries will be standardized.

I'm trying to understand distributed computing better. To that end I read a lot and experiment with computerized gadgets. I worry about mobility, reliability, fault tolerance, and security. These areas of research were among the ones that led me to the design of C++, so in a sense I'm returning to my roots in "systems." Being a manager at AT&T Labs - Research also takes some time, but not as much as you might think, and it doesn't feel like real work: in that capacity, I don't produce code or technical literature.

6) Multiple inheritance
by MosesJones

Three linked questions:

a) Do you think that multiple inheritance is a requirement for a true OO Language?

b) When designing a system with multiple inheritance what do you see as the pitfalls to avoid, especially when it comes to maintainability?

c) Do you know of anyway to simplify the readability of multiple inheritance to enable first time users to do less damage?

Bjarne:

If you rely on static (compile time) typechecking, you need MI. If you don't have MI, many programs get contorted and you have to use explicit type conversion (casting) far too often. I wouldn't claim to know what - if anything - is "a true OO Language" but if you have to use explicit type inquiry essentially all the time, you don't have one.

I don't see MI as a particularly serious source of pitfalls. The obvious problem - which MI shares with single inheritance and every other powerful language feature - is overuse. I tend to use MI for simple aggregation and for adding implementations to interfaces. For example:

class network_file_error : public network_error,
public file_error {
// ...
};

and

class interface { // abstract class
// pure virtual functions
};
class base_implementation { // useful functionality
// data, functions, virtual functions
};

class my_implementation
: public interface,
protected base_implementation {
// data, functions
// override some base_implementation functions
// override all interface functions
};

In the latter case, you then have the users of my_implementation access it exclusively through pointers or references to interface. That was user code is independent on the implementation class and the system doesn't suffer from the so-called "brittle base class" problem. The implementation class can be exchanged for an improved version without recompilation of user code (except my_implementation itself).

Following those two styles avoids most problems. Naturally, you can find a more extensive discussion in "The C++ Programming Language (3rd Edition)" and in the new "The C++ Programming Language (Special Edition)." (See my home pages for details, sample chapters, reviews, etc.).

Actually, questions about multiple inheritance usually indicate that the questioner has been distracted into technicalities. To almost all programs, questions about use of abstract classes, templates, exceptions, and the standard library would bring far more benefits. MI is necessary in a statically typed language with inheritance, but it is not among the features that should be used most often.

If you focus on defining concrete classes to represent simple types and abstract classes to represent major interfaces, a good design is likely to emerge. Then, MI may or may not be needed to complete the program, but will be pretty obvious where it might be needed.

7) Questions
by Edward Kmett

Is there any hope for the introduction of constrained templates? Right now using templates is an exercise in willpower for the programmer. I know that constrained genericity went before the committee when templates were first introduced, but has there been any thought to revisiting that decision?

Another item that has gained a lot of momentum in the Eiffel community is Design by Contract, for which I would love to see a standardized approach in C++, but I doubt I'll ever see it.

Lastly, Bjarne, you were quoted once as saying 'When (not if) reference counting becomes available in C++ that it would be optional' (in a book on object oriented programming languages of which I cannot find on Amazon at the moment to post the ISBN). Has much progress been made on the front of making reference counted objects available? Or has your thinking changed since you were quoted?

Bjarne:

Actually, what I said was something like "When (not if) auotmatic garbage collection becomes part of C++, it will be optional".

Reference counting can be very useful for less frequently used resources, but I'm not advocating it as a general mechanism for keeping track of memory. C++ has good mechanisms for keeping memory management under control (such as constructors and destructors and the standard library containers), but if you need something more automatics, plugging in one of the available garbage collectors is the right answer (see section C.9.1 of "The C++ Programming language", my C++ page, or my FAQ).

Incidentally, the ISBN for the new hardbound "Special Edition" is 0-201-700735 and the ISBN for the softbound "3rd Edition" is 0-201-889544.

"Constraining" templates without taking away their power isn't as easy as it sounds. See D&E for a detailed discussion. One problem is that if you express template argument constraints in terms of base classes, you warp your system design towards a style where every property becomes a base class. This easily becomes a mess of over-used multiple inheritance and indirect expression of things that are better said directly. For example, It's clearer to say that a class must have a << operator than to say that it must be derived from "Printable" (that then has a << operator). The more direct code is shorter and generates better code than does the version where a base class was added to represent a constraint.

Specialization and partial specialization provide much of the expressive power that people want from constraints. For example, if I have a general sort template

template void mysort(Container& c);

and I want want special sort algorithms for vectors then I can simply write:

template void mysort(vector& v);

I'd like much better error messages from templates with type errors. Some of this can be done with better compiler technology (people are working on that) and some will be hard to do without some kind of template argument constraints/checking (but I don't know how to do that). Fortunately, a programmer can help. Consider the example I gave in my answer to question 1:

template
void draw_all(Container& c)
{
for_each(c.begin(),c.end(),mem_fun(&Shape::draw));
}

If there is a type error, it will be in the resolution of the fairly complicated for_each() call. For example, if the element type of the container is an int, then we get some kind of obscure error related to the for_each() call (because we can't invoke Shape::draw() for an int).

What I really wrote was:

template
void draw_all(Container& c)
{
Shape* p = c.front(); // accept only Shape*s

for_each(c.begin(),c.end(),mem_fun(&Shape::draw));
}

The initialization of the spurious variable "p" will trigger a comprehensible error message from most current compilers. Tricks like this are common in all languages and have to be developed for all novel constructs. In production code, I'd probably have written something like:

template
void draw_all(Container& c)
{
typedef typename Container::value_type T;
assert_equiv(); // accept only Shape*s
for_each(c.begin(),c.end(),mem_fun(&Shape::draw)); }

This makes it clear that I'm making an assertion. I leave the definition of assert_equiv() as an exercise to the reader :-)

This leads use to the second part of the question: design by contract. Since "design by contract" is a design style, you can apply it to C++. To do so you need to use asserts systematically. I personally prefer to rely on some specialized assert templates (see my 3rd edition). I agree that some such templates are good candidates for standardization as part of the library.

However, I don't think we'll see direct language support for things such as preconditions and postconditions. I don't think that pre- and postconditions written in essentially the same language as the program itself are a significant improvement on asserts(). Also, I'm not sure that the checking of class hierarchies afforded by language-supported conditions is worth the effort. For starters, people can gain very significant benefits today using current standard C++ simply by using assertions more systematically.

8) A quick question (ha!)
by jd

C++ is an Object-Based, rather than a "pure" (in a Software Engineering sense) Object-Oriented language. However, it's still centered around the notion of objects, rather than procedures.

However, all existing processors are procedural, and there is no real concept of an OO CPU.

Do you feel that OO languages, such as C++, will result in OO systems, at the hardware level, or will it always be easier to confine OO thinking to the abstract, using extremely complex compilers to translate between OO and procedural paradigms?

Bjarne:

One of the things I worked with before designing C++ was architectures for direct support of "higher level" facilities. I came to the conclusion that as long as hardware were growing cheaper and faster at a rapid pace, sowtware-based approaches would have an advantage over high-level hardware. These advantages are in cost, in flexibility, in the number of potential users, and in the vintage of computers that the software could run on (it takes longer to design and build a high-level machine than a traditional one).

In the forseeable future compilers mapping high-level constructs onto low-level hardware primitives will be the dominant approach.

9) C++ complexity vs. OOP simplicity
by hanwen

[Sorry for the potential inflammatory matter in this question].

How do you relate the complexity of current C++ with the much-touted simplicity of Object Oriented Programming?

Longer explanation:

Over the years, the C++ implementation has ballooned; If I recall correctly, your book the C++PL has more than doubled in size. C++ has become a very large and complicated language, and I doubt whether there are any individuals (besides you, that is) that know the entire definition by heart, let alone teams of programmers.

This means that it is not practical to use C++ fully in any project, and one also has to set strict guidelines for a project what features to use and which not. Seen, in this light, it is doubtful whether C++ has made writing software more manageable. So I think, that as tool for writing better software more efficiently, C++ is a failure.

C++'s evolution was motivated by a few mottos (you don't pay for what you don't use, C compatibility, etc.), and seen in this light, C++ is a success. Do you think that these mottos need reconsideration?

Bjarne:

Inflammatory? I think you are remarkably polite and technical here - and that your "editor/moderator" weeded out the real flames :-)

Complexity has to go somewhere and I think that putting it in the language in the form of direct support of common and powerful techniques is a good idea (or else I wouldn't have done it :-). Have you seen C code that simulates class hierarchies, parameterized types, or exceptions? Such code tend to be a complete mess of pointers, casts, and macros. In C++, such code can be clean and simple. Most importantly, the constructs have well-specified semantics rather than just comments explaining the intent of code fragments. What has happened is that the complexity has been transferred from the code to the language definition (and compiler).

You are right that there is little need to use all of C++ explicitly in every project. However, that doesn't mean that you need to impose restrictive "gudelines". When did you last use all of Unix or all of NT explicitly on a project? Would you like some manager to tell you exactly which OS facilities you could and couldn't use - independently of the nature of a project?

The typical "guideline" is straight out of the dark ages, based on information about the state of the world years ago and on strange assumptions on what is and isn't complicated. In the defense of people issuing such "guidelines," it must be said that the educational establishment has on average done a poor job at focussing students on the key programming techniques that are effective in C++. The results have been much muddled C-style code combined with bloated Smalltalk-style class hierarchies. The common denominator for these sub-optimal uses of C++ is losts of casts and lots of macros.

That said, I have seen many successful C++ projects (many more than failures) and much good C++. By good I mean, elegant, efficient, reliable, and maintainable. So, for many, C++ has delivered exactly what it was designed to deliver. Please remember that I made few, specific, and well-documented promises about C++ (See D&E and "The C++ Programming Language"). I was not a contributor to commercial OO hype.

I think I see a correlation between successful use of C++ and respect for its limitations (the deliberate constraints on its design) and a willingness to adapt design approaches to the facilities offered. For example, if you reject the use of abstract classes and build deep hierarchies with lots of data defined at each level, you really shouldn't be surprised by long compile times, frequent recompilations, and problems understanding what is defined where. Similarly, if you refrain from using C++ facilities and litter your code with C-style strings, arrays, plain structs, and lots of pointers into low-level data structures, you shouldn't really be surprised to get C-style problems rather than the promised benefits from C++.

The main tutorial presentation of the C++ language was 186 in the 1st edition, 282 pages in the 2nd, and 360 pages in the 3rd. Part of that increase is a greater emphasis on programming technique. The rest of the increase in book size (from 327 pages in the 1st edition to 1040 pages of the new special edition) is due to more information on programming and design technique, and the standard library. The "special edition" has 363 pages on the standard library - in addition to the uses of the standard library as examples in other parts of the book.

10) Questions for Bjarne
by scherrey

I was introduced to the C++ language in 1989 on the BIX online service by you and Greg Comeau whereupon the both of you set out to demonstrate (and finally convinced me) that this OO stuff wasn't just a fad and that C++ was a language that could efficiently implement it. This was during the time when Computer Language magazine had there "Language of the Month" feature article so languages had a tendency to come and go quickly back then.

As I recall, the two major goals that you stressed were a) to build a language that could get a handle on these huge projects that C was having difficulties with and b) to provide a balance of features and efficiency so that a developer should have to pay for features he doesn't use.

From my own experience using C++ in an extreme variety of projects (including very cramped embedded systems and large, multi-platform enterprise systems), there's no doubt that the great progress has been made on the first goal and that the second might have been fully achieved.

The biggest disappointment to me, however, has been the lack of ability to fully replace plain-old-C in system level development which is an area that stands to gain the most from the language's abstraction features and your stated goals of the language. I understand that early on, it would have been impossible to define standard ABI's since implementation techniques for things such as virtual method and inheritance resolution were very experimental. Now that a full decade has gone by and a surprisingly strong standard has been produced, these differences in implementations are more contrived than based on architectural considerations.

Presently the Open Source movement is growing wildly in popularity in commercial and non-commercial segments of the industry. Unfortunately, C++ cannot be used to provide linkable API's without either downgrading to severely limiting C-based linkage or forcing everyone to use the same compiler that wants to call your library because of non-standard representations of structures and calling conventions.

Do you think that standardized application binary interfaces should be a priority time now? If so, what should be the mechanism used to define these interfaces (defacto vs. formal standards, etc), who should do it, and what can be done to encourage this development?

Bjarne:

Hi Ben,

I think I nailed the efficiency, the generality, and to some extent the elegance. However, I underestimated the linker problems. I may also have underestimated the problems stemming from C compatibility.

If I were a platform provider, I would have made a C++ ABI a priority a couple of years ago, so that all vendors on my platform could be ready to provide conforming implementations when the compilers reached a high degree of standards compliance. I know such efforts have been started by Sun for SPARC and by a group of vendors for Intel's upcoming Merced architecture (IA-64, see http://reality.sgi.com/dehnert_engr/cxx/).

I would encourage everyone - and especially people who write software intented as part of a collaborative efforts - to encourage such platform ABI standards. If you are among people who can, lobby for a C++ ABI on your favorite platform. Unfortunately, I don't have specific suggestions on how to do this.

The compatibility with C at the system interface level has encouraged people to use C-style strings, arrays, and structs, where they would have been better off with some higher-level abstractions presented as classes or templates. Instead of leaving the low-level facilities at the system level and within the implementations of classes, people have let the low-level constructs - and pointers to them - permeate their designs. Type errors, wild pointers, array bounds errors, and memory leaks are the obvious results. Lots of macros and casts often adds to the obscurity of the code. It saddens me to see some of the unnecessary messes people get themselves into.

Poor educations is part of the problem and better education must be part of the solution. However, education can only do so much. Libraries and tools must that takes advantage of modern C++ must become ubiquitous before we can expect novice programmers to venture out of the C subset and apply more powerful techniques.

For starters, people ought to realize that starting to learn C++ is easier than starting to learn C. The optimal initial subset of C++ to learn is not "most of C" and C++ can provide a much smoother learning curve than is commonly done. See "Learning Standard C++ as a New Language" (download from my papers page) for a further discussion.

We have always had applications and specialized libraries that used C++ to give programmers a higher-level environment to work in. One significant aspect of the standard library is that it provides an example of that to everybody. Writing code using standard facilities such as string, vector, map, and algorithms really can change the way people program and the way people think about programming. I hope to see the techniques used for defining and implementing the standard library applied in many other areas to yield equivalent benefits in source code size, type safety, code clarity, and run-time efficiency.

I think the time has come to experiment with the more advanced/interesting parts of Standard C++. For example, my new Standard-Library Exception Handling appendix shows a style of programming that departs rather dramatically from "C common wisdom" yet leads to simpler code. This is not written for novices, though, but it gives a peek into the inner workings of the standard library.

Naturally, we must be more cautious in production code and there compatibility concerns with older code weighs stronger. However, we should not be so bound by older styles and compatibility that we never dare try out more modern and more effective styles. There now are native C++ styles, and we should use them.

-----------

I did take peek at the "raw questions" on slashdot.org. I had to resist the temptation to explain all of C++ here, and explain how to use it, and explain why the facilities are the way they are. For more information, have a look at The C++ Programming Language (Special Edition), The Design and Evolution of C++, and my papers.

It appears that I'll have to update my FAQ with several new questions, but that'll take me a few weeks.

Thanks for asking hard questions.

- Bjarne

---

Update: 02/28 02:14 by R: Additional comments...

Comment by Anonymous Coward
Friday February 25, @12:53PM EST (#44):

Some really, really interesting stuff. I'm going to forward this to everyone at work here.

My only negative question is did he have to plug his books so much?? It seems like he never passed up a chance to "refer to my 3rd edition of C++PL", etc..... I tend not to trust people who plug themselves and their products too much.

This, of course, is a minor concern. Thanks to /. for getting this great interview!

Bjarne:

Imagine a radio interview with a serious painter or sculptor. To such an artist, his/her work is what matters, but there is no way that work can be presented on the radio. You would expect many references to individual works and to museums where people can go to see such work. Descriptive words simply aren't enough. Poor artist can compensate by distracting the discussion away from their work and into their personal lives or politics, but that's not an option for serious ones.

I'm not an artist, but for an interview like this, I have a similar problem. I want to show code and serious discussions of problems, but the Q&A format doesn't allow that. My solution is to refer to my published work and to my homepages.

After all, my published work are the primary sources on C++. So, unabashed, if you want more see my home pages, read TC++PL, D&E, or my papers.

C++ and scientific computing
by J. Chrysostom on Saturday February 26, @12:32AM EST (#308)

As a soon-to-be graduate student in scientific computing, I sit and wonder sometimes why the support for mathematical and scientific computation in C++ is so limited. FORTRAN, the ugly and unmanageable beast that it is, is the only haven for computational mathematics.

Bjarne:

Have a look at the links to numeric libraries in C++ (such as Blitz++, POOMA, MTL, and ROOT). Maybe also track down some of the numeric C++ pages.

Comment by Davorama
Friday February 25, @12:37PM EST (#22)

These other questions were so great I didn't make the cut but maybe you folks have opinions you'd like to share?

What do you think of template meta programming? Do you consider it a boon, enabling clever programmers to do outrageously cool things like the Blitz project? Or is any benefit derived from it's use washed away by the obscure, nearly unreadable code it takes to implement it?

Bjarne:

I really like some of the things being done with C++ in numerics. The common thread is that templates are used to eliminate spurious temporaries. The results tend to beat Fortran in its own game while maintaining Math textbook notation. On my homepage you can find links to POOMA from LANL, Blitz++ from Warterloo U., and MTL from Notre dame. TC++PL has an explanation of the basic technique in the Numerics chapter.

I don't mind the obscure code in the implementations. Actually, I find most of that code far less obscure than, say, C kernel code. Where efficiency is paramount, you shouldn't complain too much about obscure optimizations, and anyway if you are a real user, you shouldn't read the implementation code.

Comment by sethg
Friday February 25, @01:12PM EST (#65):

A common theme in the answers seems to be "that complaint is based on outdated information; get a new compiler that follows the standard and use the STL."

For the benefit of us C++ newbies, does anyone maintain a chart showing which currently-available "C++" compilers violate which sections of the C++ standard?

Bjarne:

A first approximation: Compilers currently shipping from major suppliers are reasonably up to date (I use them). Examples include. Borland, GNU, Metrowerks, Microsoft, and SGI.

For more details see LANL's list (link from the POOMA site, see my C++ page) or a site in NZ that tries to keep track. Some vendors, such as Borland, keep the results of the Plumm Hall validation suiye public on their websites.

And, yes. It is my opinion that a very large proportion of problems reported with C++ can be traced to misunderstandings and misuse. A modern C++ implementation is a prerequisite for trying out some of the techniques that I'm suggesting, but please don't think that a new compiler by itself will help much. You need to actually change the way you work - and unfortunately there are many real-world factors that makes such changes hard (legacy code, lack of time to learn new techniques, co-workers, antique style rules, etc.). I dit not say it would be easy, just that it is possible and that many have succeeded.

Comment by hanwen
Friday February 25, @01:25PM EST (#77)

-- much stuff omitted --

Maybe nowadays some of my gripes may be soothed by the Standard Libraries, but I don't feel like learning yet another big C++ component, all the more because I know that afterwards C++ will still not be good enough (or will it ever have reflection, higher order functions, GC?)

In this light, I find your statement that "starting to learn C++ is easier than starting to learn C" dangerous, as are the examples in your "learning C++ as a new language paper" for they imply that any of these two languages can or should be a "first" language.

Do you really want people grow up with a language that has distinction between non-immediate objects on the heap and stack, no automatic garbage collection, pointers, no initialization, no higher-order anything?

You're educating people about C++: fighting misconception, telling them where it is good for. But you're not telling them what it is bad for. C++ is immensely popular, and people easily get the misconception that this popularity makes it a good language to start programming with, or to write their highly tweakable programs, etc.

Bjarne:

Actually, yes. I don't feel that it is right to start off people with a language that they don't have a chance using once they graduate. The Lisp and functional language community failed to make automatic garbage collection and higher-order everything mainstream even though they had the enthusiastic backing of the academic and educational establishment for more than two decades. Clearly, I don't feel that leaving people with a lower-level language like C is optimal either.

Given the current miserable state of programming and design education, C++ can be a major advance. Of course, people can also fail to take advantage of C++'s abstraction mechanisms and fall back to writing the equivalent of assembly code in C or C++. Through STL, the C++ community may have introduced more people to functional programming techniques and may have applied such techniques to more real-world problems than all previous languages put together. The fact that function objects are not the most flexible "closures" available doesn't detract from the fact that people understand them, like them, and use them.

The "Learning Standard C++ as a New Language" paper (link on my papers page) clearly states that I think that these approaches scale - and argues why. Looking at C++ as it was in 1988 (no templates, no exceptions, no RTTI, and no standard library) is really to look at a different language - one that simply doesn't support most modern C++ techniques.

If you want garbage collection, then there are excellent free or commercially supported garbage collectors available for C++ (see links from my C++ page). One reason that the C++ garbage collectors are so effcient is exactly that C++ has the distinction between stack-allocated objects and free-store-allocated objects.

Comment by Anonymous Coward
Friday February 25, @02:54PM EST (#118)

Yeah this is the guy who at one time usurped the name "C" for his new language, and was referring to K&R as "old C" around AT&T ... until Dennis Ritchie told him to knock it off :)

I think he does acknowledge that the committees have straightened out a lot of the problems in the earlier versions of the language, and I don't think he would claim current C++ is perfect.

Given his success and recognition, I'd probably be a bit arrogant myself :)

Bjarne:

I don't actually think that I'm seriously "humility deficient".

Remember, I worked with Dennis (though not closely) and closely with Brian Kernighan for more than a decade. I don't think I "appropriated" the name "C", but if I had, nobody would have had a better claim to it :-)

It was not me who referrend to C as "Old C." It was me who acted to defuse the confusion and the possible slur on Dennis by finding a name for "C with Classes" that was less likely to cause confusion: C++.

Also, I worked hard in the committee (few language designers have bothered with such "tedious details"), and I think the committee did a very good job.

<  Making Linux Beautiful | Mating Human Cells With Circuitry  >

 

Slashdot Login

Nickname: Password: Don't have an account yet? Go Create One. A user account will allow you to customize all these nutty little boxes, tailor the stories you see, as well as remember your comment viewing preferences.

Related Links

Linux Slashdot Intel papers page this interview with Alex D&E papers page AT&T Labs - Research my C++ page my FAQ papers page Standard-Library Exception Handling The C++ Programming Language (Special Edition) The Design and Evolution of C++ my papers my FAQ Bjarne R my home pages a site in NZ that tries to keep track questions and comments Bjarne Stroustrup R More on Programming Also by Roblimo

Interviews

Welcome to the interviews section - this is place to come to read the assorted conversations that Slashdot and the readers have had with various people involved in the Internet, computers, or anything of interest.

This discussion has been archived. No new comments can be posted.

One of Bjarne's articles on the Web... (Score:4, Funny) by mav[LAG] (m@verick.co.za) on Friday February 25, @12:18PM EST (#6) (User Info)

...came up at me like this: Why no single programming language can solve every need. By Bjarne Stroustrup The Red Herring magazine From the April 1999 issue Why would investors or executives care what programming languages their companies use? After all, customers don't care, and shouldn't. When I dial an 800 number, I don't stop to consider which language was used to write the program that translates it into the number of a phone on someone's desk. But software is crucial to the products and services we deliver -- and the programming languages we use to write that software can make the difference between success and failure. [an error occurred while processing this directive] LANGUAGE ARTS A good programming language allows programmers to express the ideas of an application simply, directly, and affordably. It gives programmers who want to improve on a program a decent chance of grasping the structure of the system. This is critical for a software development organization's effectiveness: a programming language that makes the structure explicit helps engineers and makes it easier for software tools to analyze and display programs. I'm not sure that the programming language used to write the software that generated this page has made that difference between success and failure :) "Am I paying for this abuse or is it extra?" - Edmund Blackadder

Server Side HTML (Score:1) by delmoi (delmoi at hot mail dot com) on Friday February 25, @02:47PM EST (#115) (User Info)

They were using serverside HTML on apache, as that the standard error message. I know that wasn't really the point of your post... but... [ c h a d   o k e r e ] "Subtle Mind control? why do html buttons say submit??

ObjC (Score:0, Offtopic) by PHroD (zephcATearthlinkDOTnet) on Friday February 25, @12:19PM EST (#7) (User Info) http://hotsos.8m.com

i just dig objective-c more than C++ ...i find it more elegant and easier to write for and read (comments are alomost unnecessary as the code reads almost like english!) I think most people that say they cant understand it just have to wrap their brains around a few ideas in it, and maybe some not-exactly-C syntax, and they will discover how powerful an OO language it can be :) "There is no spoon"-Neo, The Matrix "SPOOOOOOOOON!"-The Tick, The Tick "Redeyes! Didn't expect to see you so...SPOON!"-Blue Raja, Mystery Men

Re:ObjC (Score:1) by OaITw on Friday February 25, @12:59PM EST (#52) (User Info)

I would grant you that it is easy to write and read, but it suffers from bad association with the horrible compiler that apple puts out for NT. God am I glad I don't have to work with that everyday anymore. I never had a chance to try the compiler on the MACH system or on a MAC but I have been told by people who have that the IDE is weak compared to Visual Studio/Borland Builder type IDEs. Of course I do most of my programming on a SUN system without an IDE so that is not terrible critical. Now that I think about it, it was the IDE and WebObjects together that was buggy. Just random thoughts. Forgive.

Re:ObjC (Score:2) by anatoli (anatoli@my-dejanews.com) on Friday February 25, @01:14PM EST (#66) (User Info) file:///unix

As Bjarne once said, Smalltalk is the best Smalltalk around. And ObjC is just C that tries to be Smalltalk. -- Industrial space for lease in Flatlandia.

Re:ObjC (Score:0) by Anonymous Coward on Friday February 25, @05:24PM EST (#182)

It is in the interest of your personal safety that you read this. My name is Amadou. I was shot to death by N.Y. police officers for fitting the 'description' of a rapist. That is to say I was a person with dark skin. I was shot because my skin color mistakenly identified me as someone who might possess a gun and attempt to shoot police officers. I had no gun. I had no gun and now I am dead because I was unfortunate enough to have dark skin color matching that of a rapist. The New York police officers believed I would shoot them because of my skin color. The belief of danger means the four police officers were legally entitled to shoot me 46 times. I am dead. I had no gun. I was not a rapist. The police officers who shot me are found NOT GUILTY of any of the charges brought against them arising out of my murder. I was unfortunate enough to have dark skin and to find myself in front of a firing squad of white police officers who mistook me for a rapist with a gun about to shoot them. I still have dark skin but now I am dead. The officers walk free. They can shoot you next. They need only believe you to be a threat. I hope that you do not have dark skin.

Re:ObjC (Score:2) by alkali (alkali@my-deja.com) on Friday February 25, @07:06PM EST (#236) (User Info)

If you're up, around and posting to Slashdot, it's no wonder the officers were acquitted. Grim humor aside, police mistreatment of minorities is a serious issue. Your time would be well spent considering how you might do something more serious to address that issue than posting anonymously to discussions of object oriented programming, which serves only to make you look ridiculous.

[OT] Murder for the crime of BB in NYC (Score:0) by Anonymous Coward on Saturday February 26, @12:09AM EST (#306)

No more ridiculous than the cops who claimed that they thought the wallet that Mr. Diallo was holding looked like a gun. Which is why they felt it was necessary to shoot him 46 times. And why they felt it was was necessary to continue firing even after he fell to the ground. Or as ridiculous as the state's decision to have the cops tried in Albany rather than the Bronx. Gee, maybe because the Bx is so full of those dreadful colored people. They might get upset if the police were to continue killing for the crime of Being Black. Boy, that would look bad when Der Führer Giuliani goes for the Senate seat, wouldn't it? It makes me sick.

Re:[OT] Murder for the crime of BB in NYC (Score:0) by Anonymous Coward on Saturday February 26, @02:58AM EST (#326)

I'm with you, man. I haven't been able to stop thinking about this all night. It's obscene to see that prick Giuliani up there bragging about his great officers. How could that defense lawyer claim that Diallo "left the officers no choice?" They could have made the choice to just leave law-abiding people alone.

Re:ObjC (Score:1) by MacOSNeedsDeath on Friday February 25, @01:20PM EST (#76) (User Info)

I've also used Objective-C, and must say that it produced some of the most unreadable code I've ever seen, in part because people didn't feel the need to write comments. The other part is that prototypes are optional and there is no access control. If you can name a function, you can call it. This does not encourage readable code. Objective-C also doesn't fix some of the same parts of C that C++ doesn't fix (declarator syntax and others). Java, on the other hand, puts the best parts of Objective-C into a reasonable syntax. It'll be interesting to see how efficient the GCC Java front-end ends up being.

Re:ObjC (Score:0) by Anonymous Coward on Friday February 25, @01:49PM EST (#94)

You're criticizing Obj-C readability because of people not writing comments? I could criticize any language for that -- and what I'd really be criticizing is the programmer. Anyway, I can't stand C++/Java style message passing syntax. The Smalltalk/Objective-C style is so much more expressive. (And the typing system is much less confining.) I also don't see what's so "unreadable" about calling a function you can name. You don't have to use the feature, anyway, but when you need it, you tend to really need it.

Re:ObjC (Score:1) by Baki (plm@gmx.li) on Friday February 25, @04:41PM EST (#170) (User Info)

Java, on the other hand, puts the best parts of Objective-C into a reasonable syntax Hmm, for the past few months I've been programming Java (after using C++ for some time) and I have to say its syntax is completely spoiled by the type casts that need to be all over the place. As Bjarne said, the lack of MI in a strongly typed language means typecasts, everywhere. Especially since no such thing as templates exists. Brrrr. All containers (such as Lists) are containers of Ojbects. You must cast those back to what they were, each time with the risk of a Class-mismatch (causing exceptions). Not only is this ugly, you also loose all advantage of a strongly typed language.

Re:ObjC (Score:1) by osu-neko (osuneko(whirlpool)iname(spot)com) on Friday February 25, @06:07PM EST (#197) (User Info)

All containers (such as Lists) are containers of Ojbects. You must cast those back to what they were, each time with the risk of a Class-mismatch (causing exceptions). Actually, there's usually no risk at all of a Class-mismatch -- I know nothing has been put into the container other than Thingamabobs. What bothers me is, I know that what's coming out is a Thingamabob, and thus a run-time type check here is not necessary, but there's no way for me to tell the compiler that. Not only is this ugly, you also loose all advantage of a strongly typed language. You can avoid the ugliness by creating a specialized container (e.g. make a class ThingamabobContainer). This also means you don't need to typecast what comes out. Unfortunately, this doesn't really avoid the typecast, it just hides it (it occurs inside the code for ThingamabobContainer), and adds another level of crud into the code. This would all look much prettier and be more elegant if Java had simply given in and been the weakly-typed language it should have been. Of course, this is the opinion of a warped Lisp fan... -- I'm not a monotheist; the world was obviously designed by a committee.

Re:ObjC (Score:2) by jacobm on Friday February 25, @07:16PM EST (#239) (User Info)

I agree with you that it's a pain to have to do a cast on something the compiler ought to have figured out can't cause a type safety violation. Type polymorphism (ie, templates) is definitely the biggest thing missing from Java. Fortunately, they're adding it (see?). In fact, there's already an compiler that will do it- it's just not Sun-blessed. (But the .class files that GJ spits out are ostensibly bytecode-compatible with regular java, so no special JVM is required to run them.)

Re:ObjC (Score:1) by /ASCII on Friday February 25, @07:56PM EST (#260) (User Info)

I've found that interfaces and inner classes take away allmost ALL the needs for MI, and considering all the UGLY ambigouties (misspelled?) introduced by MI, I think it's a good thing (tm). But I have to agree with you on the template stuff though. All those stupid casts where you really KNOW what type everything is of. Plain silly. Either use a weakly typed language or non-awfull template implementations. But MI would in no way solve this problem. "The time has come", the Walrus said, "To talk of many things: Of shoes and ships and sealing wax, of cabbages and kings."

Re:ObjC (Score:1) by Art Tatum (jhclouse at hotmail dot com) on Saturday February 26, @07:08PM EST (#372) (User Info) http://www.gnustep.org

Honestly, I much prefer ObjC syntax; I find both C++ and Java confusing and hard to read. Maybe this is just preference, I don't know. Help! Help! I'm being repressed!

Re:ObjC (Score:2, Interesting) by Mr Neutron (neutron@doppke.com) on Friday February 25, @01:31PM EST (#82) (User Info)

Obj-C has advantages and disadvantages with reference to C++. I used a NeXTstation as my primary development platform 1992-1995 and became intimately familiar with Obj-C. Its elegance comes from the inclusion of only a minimal set of OO features - there's no multiple inheritance, no template classes, all object access is accomplished via reference variables (pointers), there's not even a public/protected/private distinction (everything is effectively protected). This greatly simplifies the resulting code. The object syntax, while elegant, is borrowed wholesale from Smalltalk and therefore looks somewhat strange when mixed in with C syntax. C++'s object syntax is definitely more consistent with its C origins. Also, Obj-C relies heavily on "run-time magic," which Bjarne specifically sought to avoid in C++. This dependence can increase the elegance of your source code at the expense of performance. Part of what made Obj-C so pleasant to use on the NeXTstation was the rich object class library that NeXT developed. My big indictment of C++ is its lack of such a library; the STL is nice, but it's only a small part of what we need. I think C++'s wide installed base actually hinders such an effort to a great degree. Java's JFC/Swing libs are certainly rich but somewhat strangely organized. Neutron I get my kicks above the .sigline, Sunshine.

Let the nominations begin! (Score:1) by osu-neko (osuneko(whirlpool)iname(spot)com) on Friday February 25, @06:12PM EST (#199) (User Info)

Java's JFC/Swing libs are certainly rich but somewhat strangely organized. I hearby nominate this for Understatement of the Month! -- I'm not a monotheist; the world was obviously designed by a committee.

Re:ObjC (Score:1) by Art Tatum (jhclouse at hotmail dot com) on Friday February 25, @10:21PM EST (#292) (User Info) http://www.gnustep.org

The object syntax, while elegant, is borrowed wholesale from Smalltalk and therefore looks somewhat strange when mixed in with C syntax. Personally, I find it much easier to read because of this. Perhaps it's just preference. C++'s object syntax is definitely more consistent with its C origins. Hmmm...I wonder if my preference is because I don't think traditional C syntax is very efficient for object oriented concepts. Also, Obj-C relies heavily on "run-time magic," which Bjarne specifically sought to avoid in C++. This dependence can increase the elegance of your source code at the expense of performance. As I understand things (and I may be wrong), the quality of ObjC compilers has risen to a point where messages are pretty close to regular C function calls. I have at least been told by "people who benchmark this stuff" that ObjC is on par with regular C now. Part of what made Obj-C so pleasant to use on the NeXTstation was the rich object class library that NeXT developed. I'll drink to that! Java's JFC/Swing libs are certainly rich but somewhat strangely organized. My dad is currently learning Swing and said that the book claims that it's related to NeXTSTEP. Perhaps I'll get the chance to take a look at it soon... Help! Help! I'm being repressed!

ObjC (Score:4, Interesting) by Julian Morrison (julian.morrison@virgin.net) on Friday February 25, @01:54PM EST (#98) (User Info)

From my way of seeing it, ObjC is way more similar to smalltalk or perl than it is to C++. So much is resolved at run time - and quite a lot is also left to programmer discipline. Coupled with the Foundation library, it can do neat tricks like opt-in reference counting, simple clean distributed-objects without ugly hacks like CORBA, and building "selectors" (function identifiers) at runtime and calling them on arbitrary objects. Plus, it's proof against "fragile base class" except with instance variables. ObjC's attitude reminds me of perl: "You wanna do something wierd? Your program, your problem; don't let me stop you." I'd pick ObjC over C++ any day for everything except kernel bit-twiddling or projects needing huge-scale multiparty co-ordination, but if I had my way I'd add in proper exceptions and some java-like threadsafety primitives.

Re:ObjC (Score:1) by JasonAsbahr on Tuesday February 29, @12:26AM EST (#393) (User Info)

Absolutely! One of the reasons I like Python so much is that working with it is like working with ObjC.

Re:ObjC (Score:0, Offtopic) by SquierStrat (colskywalker@dontspamme.thepentagon.com) on Friday February 25, @02:23PM EST (#110) (User Info)

Actually no, you're just a a loser. :-) Cuz the Matrix == 2nd only to Star Wars. "I'm just a sucker with no self-esteem!"-The Offspring

2nd? (Score:0, Offtopic) by Axe (Axe@HATESPAM@Mindless.com) on Friday February 25, @05:29PM EST (#183) (User Info)

To that kiddie crap? Who is the loser here... ----------------------------,

Who's a loser? (Score:0) by Anonymous Coward on Saturday February 26, @02:55AM EST (#325)

Why would anyone care what an Offspring fan thinks? Geez, they must be the absolute worst band ever. I'm not just being chippy, either, I mean it. They're terrible.

humility deficient (Score:1, Flamebait) by lophophore on Friday February 25, @12:20PM EST (#8) (User Info)

Wow! Can he do no wrong? I guess there's just nothing wrong with C++ at all. There's nothing that could have been better implemented. I was looking for some reference to "I wish I had done that better" or something. Even Gosling has his regrets... there are 3 kinds of people: * those who can count * those who can't

Re:humility deficient (Score:3, Insightful) by DaveHowe (DaveHowe@Hawkswing) on Friday February 25, @12:28PM EST (#14) (User Info)

Wow! Can he do no wrong? I guess there's just nothing wrong with C++ at all. There's nothing that could have been better implemented. I think this is far from a problem - what he is saying is that anything he saw as being wrong he has fixed or is fixing - If someone builds a tool, and it is perfectly suited to his hands and his reach, then you also use that tool, and find it less well suited, it just means you are different to him - not that either of you are "wrong" in some abstract sense..... --         -=DaveHowe=-

He had a tough crowd (Score:0) by Anonymous Coward on Friday February 25, @12:45PM EST (#33)

He did mention things that he'd wished he'd done better or different, like a better/earlier standard libaray (amen!) and promoting a C++ ABI. What do you want, a confession?

Yes, a confession. He is a criminal. (Score:0) by Anonymous Coward on Friday February 25, @02:14PM EST (#106)

Stroustrup is denying the validity of my opinions by refusing to agree with them. This is tyrrany. It's a symptom of the radical left-wing nature of the C++ programming language: It's completely -- one might even say brutally -- authoritarian. Linguistic sovereignty resides in the very broadest possible level of authority: The International Standards Organizaiton. I don't think I really need to clarify the implications of that, do I? Or maybe I do: Your mindless, slavish parrotting of the Party Line demonstrates a level of delusion and pure ignorance consistent with liberalism or worse. The very concept of coercive language design, much less a militantly centralized standards process, speaks of a violently dictatorial and anti-American point of view regarding programming. The language should be defined at the local level, by committees of Christian men of known good character. This, of course, will never happen: The socialist establishment is hell-bent on chipping away at every vestige of sovereignty left at any level below the UN. This is to serve their short-range goal of totally annihilating all wealth creation in the world. When they've done away with wealth, the world will be ripe for the next and final stage of their conquest: The imposition of an infinitely cruel medieval agricultural slave-state. Cambodia was their dress rehearsal, and it went well. Clinton came back from his apprenticeship in Cambodia ready to take on his assigned role as the so-called "Final Controller" of what the liberals call "The United States Occupied Zone". He has done well. We will not be permitted to remove him. We tried once, with undeniable evidence of his treasons and murders, and we were defeated. He will never leave office. His ultimate reward will be an appointment as the first King of the USA, which in its medieval slave-state form will be known in liberal terminology as "Subdued Slave Zone 53". Ignore the election. It's just window dressing, circuses to keep the plebians distracted while the real work of conquest is done. The real decisions have already been made. Your "excess" children will be ground up and sold as dog food in accordance with the protocols of the Gore Population Control Agenda.

Re:Yes, a confession. He is a criminal. (Score:0) by Anonymous Coward on Friday February 25, @03:42PM EST (#140)

Oh, now I get it. I guess I never thought about it that way before :)

Re:Yes, a confession. He is a criminal. (Score:0) by Anonymous Coward on Friday February 25, @09:13PM EST (#278)

Story By Mad Gerald The contents of this story is of sexual nature and does involve blackmail, and non-consensual sex. ANYONE WHO MAY BE OFFENDED BY THIS STUFF PLEASE DO NOT READ. YOU WERE WARNED OK! All characters are fictitious. Any resemblance to anyone either alive or dead is purely coincidental. This story is intended for ADULTS only. IF YOU ARE UNDER 18 PLEASE DO NOT READ. LEGAL STUFF: The attached story may be shared with others and freely posted in newsgroups and on the Internet, provided no money is charged to read this document, or if it is I am offered free entrance to that site in payment and no part of this document, including the notices and attached fiction are modified, and the original author is given proper credit for their work. My grateful thanks to First Independent Films for their story which I have borrowed material from. "G.I. JANE." an Adaption to the sexual by Mad Gerald. Synopsis (You've all seen it yeah, otherwise see it!!" Navy Intelligence officer Lt. Jordan O'Neil (DEMI MOORE) sets a historic precedent when she is recruited as a test case to be the first woman allowed to train for the highly covert operations unit known as the Navy SEALs. Selected for her courage, skills, and level headedness, O'Neil is determined to succeed in the most demanding, most merciless and most honoured fighting force in the world, in which 60% of her male counterparts will fail. Under the relentless command of Master Chief John Urgayle (VIGGO MORTENSEN), O'Neil is put through weeks of physical and emotional hell, and is not expected to succeed. Indeed, military and high ranking government officials including her sponsor, Senator Lillian DeHaven (ANNE BANCROFT) are counting on her to fail. However, to their dismay and perplexity, O'Neil perseveres. Part One. S.E.R.E. Training Facility Captive Island, Florida. A Helicopter interior. US Marine corps. "Survival evasion resistance and escape this is it tadpoles! Your target is inside of five miles if you are to locate this facility you are to gather as much intel as possible, within the allotted time frame and get the hell out of there you will be penalized for early extraction but you will be even further penalized for capture. trust me welcome to sere get ready stand up 30 seconds 1st man out go .go go.!" Lt O'Neil hit the water with a hard slam and made for the shore. she rose up out of the water slowly followed by the others of her unit. water gushed from every nook and cranny of her well muscled frame. They made their way to a line of driftwood, trees and bushes, and took up point positions. gathered around her, preparing their weapons "So were they drop us LT?" "A line of march TWO. ONE. ZERO. and just for shits and giggles lets switch to channel FIVE for tactical traffic. maintain casual dialogue on assigned channels. Slovolic it's TWO. ONE. ZERO. kotec lets move out, move out!" They moved off into the trees, from clump to to clump along the beech. "Four clicks 226!" whispered the radio guy. O'Neil looked at the map getting her bearings. Two of the others sniggered. "She don't even know where we're goin'" "Shut up" "Gotezlav you take my left flank, lets go!" they moved forward. Into the estuary. They moved through the shallow water on their belly and on to the sand on the other side. O'Neil slipped out of the water glancing about. The other moved up into the trees. Through the trees across the water lay the target. "Looks like she's right on the money!" "Yeah I had a busted watch once it was right twice a day!" "Cortez target ahead, belay my last new rally point my location." "Cool, Newberry, right side, flea you come with me, lets move out" "Listen up everybody, we need film from all angles, record of weapons, vehicles, count their guys, ranks if visible, Slav, Cortez check antenna for comms capability." "Mc Cool?" "There's nothing there O'Neil there are no prisoners and no guards, maybe we found this place a little too easy There's nobody here!" "Cortez, Cortez!" "Mc Cool 3 o'clock!" "What the hell are you doing? This is team leader to team fuck up! knock the grab ass off, get back to your positions. You are compromising the unit!" "That is an order do it now!!" Cortez and Slav were through the water now to the barge, slob moved forward to grab the helmet on the barge. "No Slav don't touch it man!" "Hey it's just a souvenir" "No Slav!" as he does automatic fire rips out of the undergrowth hammering into the barge. Tannoy speakers begin to blare out. "HEYHOHOHOHOHO WELCOME TO SUMMER CAMP BOYS AND GIRLS!! (Auto fire) FOR HE EXPECTED NOTHING AND SO HE SHALL NOT BE DISAPPOINTED!!" "All units!! Rond-a-vue at the rally point, lets get out of here!" O'Neil turned and sprinted back into the tree line, ducking and weaving as rounds flew around her. Flea followed on her heels he screamed as he tripped over some roots wrenching his knee. He rolled into the stream howling. "Oh Shitttt!" O'Neil dragged him out, and tore open the guys BDU'S above the knee, "Put your hand there! don't move you'll make it worse arghh Jesus!" Inside blood poured from a deep gash. Suddenly a thick plastic bag was thrust down over her face and pulled tight. O'Neil tore at it with her fingers desperate for air. She was dragged over backwards and away. She fought to stay conscious as she was dragged through the jungle and thrown heavily on her face. Then up again and she was picked up and thrown into a cage. She squealed in pain as she hit the hard wood floor. She scrabbled with her fingers and managed to tear away the bag gasping for breath. She looked about and found Flea in the next cage. "Flea! Flea are you OK?" "Yeah yeah I'm OK" The others of her unit were dragged into the compound and thrown on their knees. "Get down! who's in charge here? huh who's the officer in charge?" They started beating on them. and then they were all forced into similar cages. Lt O'Neil tried to keep her breathing shallow, her shoulders ached, 'She must not panic' she kept telling herself. 'Keep control' she could hear the heavy tread of their boots as they approached the cages. They stopped outside flea and took him away. She drifted off to exhausted sleep as darkness fell. The cage roof was lifted freezing water was thrown on her jerking her to consciousness, strong hands grabbed her upper arms, dragging her upright. There were two of them her arms were twisted around behind her and her wrists tywraped. They pushed her down the pier to the boathouse. She was shoved through the door inside Master Chief John Urgayle stood in the centre of the room grinning. "Hi Lieutenant time to play!" he laughed. She was shoved to the centre of the room and forced down on the small stool in the centre of the room. The rest of the room was bare apart from a bench like table. a fan span slowly from the ceiling. One of the guards walked slowly around her muscular frame. she sat legs open, bent before her, her arms painfully forced behind her. She stared at the floor. Sweat trickled down her forehead and dripped from her eyebrow. "What's your fathers name, it's a simple question Lieutenant no reason not to answer unless you want to bleed?" "Dad" "How about brothers and sisters you got any o'them?" "Dick, jane and spot!" Bright lights came on suddenly, above her. She blinked. "You for real O'Neil?" he came close, blew cigarette smoke in her face. " What's your favourite food Honey, perhaps we could get some to eat huh?" The master chief watched from the bench. He checked the monitor, pictures from the camera's look good. Then got up and walked behind her. "Green eggs and ham" Suddenly the master chief loomed over her, he punched her face hard throwing her head back. "Why didn't you carry out your wounded Lt. was he too heavy or were you just plain chicken shit!" he stared into her face. She smiled. "You ain't getting nothing out of me so you might as well put me back in the cage" He hit her again full in the face. She went over backwards to the side of the stool and landed with a groan, face down on the floor. She lifted her head and spat out some blood grimacing. "You are in a cage! right here right now!" "I'm sorry am I supposed to be afraid?" she managed. The master chief stood astride her back and gripped her upper arms from behind wrenching her up from the floor. She winced groaning in pain. "Right down to your worthless wound. This is my island!!" He threw her bodily into the wall. She struck it with a yell and bounced off, twisting, fell backwards on the floor, she grunted the wind knocked from her. Her legs falling open. He ran at her and kicked her exposed groin. Lt O'Neil screamed as pain lanced through her from her cunt. "You worthless piece of shit, bitch!" He nodded the two guards went over and hauled her up to her feet. She was leant forward, he grabbed her head locking it under his arm. "You think we should go easy on women O'Neil? do yer?" She gasped blood bursting from her mouth, "GO FUCK YOURSELF!!" The guards let go and he ran at the wall with her head slamming it viciously. She reeled back yelling. He threw her back over the bench pinning her bound arms to the edge. One of the others threw a chain over her head and snapped it taught around her neck almost throttling her. He fastened it to a bolt. She grunted and gasped in pain and shock. Her booted feet kicking trying to get purchase on the dusty planks. She gritted her teeth straining to get up. Jack went away and came back with a bucket. "The enemy I'm sure will take into account your gender while carrying out interrogation, one assumes!" He poured the freezing water down onto her panting chest. the water soaking her t shirt making her breasts ache as her teats went rigid. Both heavy mammaries were outlined beautifully by the wet material. "Especially when the P.O.W. has such big stiff hooters eh Lieutenant?" "Go to hell dickweed!" she spat groaning in pain. At a nod from Jack one of the guards thrusts a plastic bag over her face and drags it tight. O'Neil goes wild trying to pull free as Jack grips the neck of her shirt and cuts it open with a combat knife. Her breasts bounce free. two hard globes mounted by thick coral aureole and wrinkled stiff nipples. As she struggles the jiggle and jerk stiffly. Jack throws his leg over hers and sits astride them. He produces some thick cord and throws it around her back, pulls it tight and ties it off above her jugs. He cuts the rest off and repeats the process under them. then he pulls the sides together and lashes them, then between them now her breasts are two heavy jutting balloons. He nods and the pull up the bag. O'Neil gulps for air almost feinting from lack of it. Jack grins down at her. Her expanding chest forces more of her breast flesh to bulge out. "Y .Y .You bastard!" He pats her tits slowly. "Now now Lieutenant, we're only doing what the enemy would do to a nice piece of ass like you". He nods, the bag is thrust over her mouth again. She starts, arching her back trying to pull her head free. Her tits jut out and he grips her nipples between finger and thumb and yanks them out hard making her scream into the bag. "What d'you think boys are these good enough to ice or what?" He twists her nipples making her writhe, he nods the bag comes up. "Hey Lieutenant what was your mission objective?" She stares at him gasping for breath. "Come on Baby you going to keep quiet until we've all fucked you in the butt?" "GET THE FUCK OFF ME YOU PIECE OF SHIIIIII . .!!" The bag came down again stifling her cry. He wrenched and pulled her tits, his fingers kneading and pinching, pulling each breast hard, bruising. "Any o' you boys ready to blow yet?" "Oh yeah am I ready" one of the guards squeezes his cock through his pants. "Lets go then!" He yanks his cock out and begins wanking next to O'Neils bag encased features. faster and faster. "Say when man!" "When when!!" he groaned the bag came up. Lt O'Neil gasped for air her mouth wide in a desperate 'O' as she sought air. With a groan of pleasure the guard let loose a heavy spurt of semen straight into her suprised open throat. Then another. "Yeeeehaaaaa how'd yer like those cookies Lieutenant!!" Jack shouted as she choked and coughed, grimacing shutting her mouth as fast as she had opened it as more Jiz splattered across her face and lips. She spluttered and spat trying to get rid of his load. More went in her eyes and across her shaved head. "You know lieutenant I think he likes you!" They laughed. "Y You Filthy bastards I'll fucking kill you all (Cough, splutter) I will you pieces of fucking . . !!" the bag came down again. "My my that has made her pissed" they all laughed. O'Neil strained and wrenched desperate to get away her body screaming out for a few deep breaths. Jack rubbed and pinched her teats, making them ache and throb. Her chest thrust out hard as she fought. Jack nodded and the bag came up again. O'Neil gasped a huge breath, semen strung between her lips and teeth. She stared at him and spat. "You fucking shit! I'm gonna rip your dick off and ram it up your ass" Jack grinned at her, "Aw now you love it really O'Neil!" he pulled her nipples hard to emphercise the point. "Now you tell me your mission objective!" he grinned. "Fuck your mission objective . . Fuck your . . . uhhhh!!" At a nod the bag came down again, O'Neil jerks and struggled. "Hey Dobs get some of the others, get the ring thing too!" Jack gets off her squirming legs. She immediately began to kick. "OK lets get these BDU's off and see if the Lieutenants wearing pink fluffy panties today!" Her legs kick and fight viciously as they're hands grab them. The belt and waistband are torn open and she gurgles and moans as she feels them wrenched down off her hips, she strains trying to pull her legs free as the bag comes up and she gulps air spluttering. "Huh . . huh G . Get offa me get off you fuckers . . uhhh uhh I'll fucking kill all of you. You fucking creeps!!" she dragged her legs up hard. They strained trying to pull them out, her strong legs holding out. Jack punched her belly hard. She grunted and swore still straining. He rabbit punches her ribs, The bag come's down stifling her cry of animal rage as they forced her legs slowly out. More men came in and with whoops joined in, they're added strength forcing her legs out. Jack grabs her hips and drag's her ass off the edge of the bench. With a painful yelp O'Neil was now suspended by her bound arms and throat. Her BDU trousers were torn from one leg and her legs were wrenched cruelly wide. Her struggles became less as the lack of breath began to take it's toll. A guy on either side quickly ties thick cord around each knee and them to the bench legs. O'Neil slumps as she blacks out, as the thick cord bites into her strong muscles. Her ass hanging off the bench her strong legs spread wide, displaying her white panty clad pussy, which bulges against the material. Jack nods the bag comes up. He slaps her round and she groans and come too with a shuddering breath. UHHHH . . UHHHHH . . Y . you F . . Faggots!!" he grins into her face. Now with her ass unsupported and her whole weight on her knees, arms and neck, she realizes how helpless she is. She gulps in air as they stand around her admiring the view. Jack viciously punches her in the twat, making her gasp and choke in shock and pain her legs snatch and strain to no avail. "What's your mission objective Lieutenant?" "Ughhh . . OK Ok I get your point th . . this has gone far enough OK!" Jack grins and traces his fingers along her inner thigh to her pussy mound. He slowly feels it. She glares at him. "I asked you a question Lieutenant?" "Look cut the crap I get the picture OK . . . No don't . . don't do that!" He drags her pants to one side so they can all see her twat. "You know what happens when you get captured Lieutenant?" "I get the idea YEAH!" "THEN ANSWER THE QUESTION!!" He yanks her pants up hard and they tear, Then he rips them off. "ARGHHH YOU FUCKIN . . .UHHHHHHH!" the bag comes down again. She struggles to push her chin down to stop it but then she's struggling again. They watch as her tits bob about and her legs strain as she begins to panic. "Dobs! the gag, lets have some safe sex with this one huh I bet she bites!" Dobs brings the gag over and hands it to him he readies it then the bag comes up. As O'Neil gasps for breath Jack tries to force the two side shields between her molars she tries to pull her face away. Dobs grabs her face, she snarls, and he howls letting go, snatching at his bitten thumb. "AH AH NAUGHTY BAD GIRL!" Jack punches her face. and again stunning her. her mouth is rammed full of the gag which goes between her back teeth and behind her front sets. forcing her mouth into a wide 'O' leaving her tongue lolling about in her open maw. He fastens the belt around the back of her head tightly. "That's better now you see we got two holes to play with!" He steps back. "And now for number three" "Dobs where's that asshole Flea?" Flea was pushed forward and thrown on the floor. His arms tied behind him like hers. His leg was a bloody mess. He let out a cry of pain as they held him down. Jack stood over him. "Lesson Lieutenant, your troops will be used against you during interrogation!" He slams his foot down on Fleas injured knee. Flea screams in agony, writhing under him. O'Neal snatched at her bonds in anger and despair as Flea screamed. Her eyes flashed with anger. she mouthed stifled entreaties past the gag. "NOOOH NOH UU PHUKKER!!" "Only I don't want some crap intel. I want you to do me a favour Lieutenant. I want you to shit for us O'Neil, Believe me It's going to be far easier if you do. Otherwise we're going to have pound all that shit back up your ass. I don't think you're going to appreiciate the taste when we make you suck our cocks clean. So you have a nice long shit and I stop being nasty to Mr Flea here yeah!" He stamps down. Flea howls in agony, thrashing in mind numbing pain. O'Neil couldn't believe what he wanted her to do, her face twisting in disgust at his demand. "So what do you say Lieutenant? you going to shit for us or do we keep smashing this poor mans knee!" he stamps on it again. Flea screams sobbing and begging for him to stop. "I mean hey it's not like I'm asking you to piss now is it?" They all laugh as O'Neil slowly flushes with humiliation realizing that she's going to have to do it or Flea will never walk again. "You going to be able to live with that lieutenant? huh? this man crippled because you were too proud to take a shit?" His foot slams down again. Flea screams a bony crack coming from his knee as he writhes in awful pain. "OH HAY OH HAY OO ASTARD IYL OO ITT!!" "Now that's more like it lieutenant, you hear that Flea she's does give a shit! Ok O'Neil lets see that stuck up arse of yours take a dump" One of the men brought a metal bucket over and clanked it down under her. They all gathered closer. Lieutenant O'Neils eyes flooded with tears as a wave of awful humiliation went through her. She couldn't believe they're depravity. "C'mon we're waiting You shit or he never walks again cunt!" She closed her eyes and swallowing her revulsion pressed down. They watched in silence as her belly tightened up, her anus distending and pushing out. She grunted with effort, some of them sniggered heightening her humiliation as suddenly her sphincter eased open and she shat into the bucket. They cheered. O'Neil was mortified as more and more piled out. Eventually with a gasp she was finished. Jack laughed "See you were so full o'shit. I just love that, the way that tight little star spread open, an' then clamps shut. You're husband fuck you in you're ass O'Neil? I guess not, by the look of it huh? and now we're gonna fill you full o' Jiz honey!"" She shuddered in disgust and revulsion. Two of the guards come forward with a small table, on it are tubes and a large syringe (A veterinarian syringe 3" diameter and 10" long). Lt. O'Neils eyes are bulging as she sees the syringe, a wave of panic floods through her and she struggles. her eyes darting from item to item on the table. There's a rubber bung device as well. Jack picks up the tube and connects it to the syringe. "Now we ain't gonna Fuck your butt while it's full of all that feminist crap. Me and the guys like to get you all warmed up first, So we've had a little collection on the go." He holds the thick long syringe in front of her face. "We've been filling this with semen since you joined the course bitch, now I'm gonna wash your ass out with it!" He laughs. O'Neil goes wild struggling helplessly as he busies himself inserting the end of the tube up her ass. With one swift stroke, he jams the nozzle of the cum-syringe up between her shapely ass-cheeks and into her little brown starfish, and none to gently, either. Kneading her ass-cheeks while she yells in pain. She stiffens as it's forced in and he rams it deep into her rectum. Her big bound tits bounce and jiggle as he lets it go and grips the body of the syringe. "Gonna fill you up!" He sneers. "Phuck oou!" she replies. "Here we go Bitch!" He starts to press the plunger home. O'Neil Jerks and arches her back howling 'no' through he gag as she feels it start to squirt into her bowels. The muscles in her legs stand out hard as she tries to lift away. She gasps and groans, biting on the ring gag as Jack grins down at her. "OHHHHHH AWHHHHH AWWWWHHHH NOHHHH NOHHHH!!" she writhes. It's half way down now and Jack grins evilly. "Enough Lieutenant, full?" he queried. She nods enthusiastically "ESS! NOH ORE. NOH OREEEE!" "Unlucky whore!" He laughs, and forces the rest in hard making her sob and gasp. Her belly bloating with the warm slick enema. Suddenly with out warning the bag comes down over her face again she struggles for breath, unable to shut her mouth helplessly drawing the plastic in. Her body goes rigid as she asphyxiates. Jake yanks the tube out of her ass and snatches up the bung. He rams it into her anus twisting and forcing it until it's home. He quickly pumps the handle. It inflates cruelly wedging itself in her ass holding the semen in. He nods the bag comes up O'Neil gasps great gulps of air, her ass is aching and hot as if she's doing an enormous turd. Her belly cramps and her rectum spasms trying to shit but she can't. "There Lieutenant now it's really time to play". He slaps her twat hard making her cringe and squirm as it smarts. They drag the bucket away and Dobs kneels in front of her. He wrenches his pants open and pulls his hard cock out. He drags her cunt lips open and forces the head into her dry cunt mouth. She sobs and grunts as he forces it in a few inches. Then his fingers find her clit hood and he pinches it hard making her jolt and heave. "Oh yeah Lieutenant I've been waiting a long time for this cunt, you like that huh? huh?" he violently rams up into her while the others egg him on. forcing inch by inch into her cunt. His cock amplifying her need to shit as he forces into her. "Bag her! bag her!" the others shout and she shakes her head 'No' as it's rammed down over her features. He starts to fuck her hard enjoying her struggles. He flicks and rubs her clit as he grinds deep up her tight dry twat. Two others start to paw and pull her tits from each side. She twitches and writhes as they stretch and twist her nipples. Both are wanking their cocks. The bag comes up. One grabs her face twisting it he thrusts his meat into her helpless mouth and begins to shaft her face. She snorts and gags trying to breath as he starts to force into her throat. Dobs is viciously fucking her wettening cunt. his legs straight as he grunts and groans. He then stiffens as he hammers his load into her flinching cunt. O'Neil sobs as she feels his heat spurt into her. He pulls out and someone else eagerly mounts her. his cock larger and longer ramming in forcing her cunt walls to give with each hard thrust. The bastard holding her face groans and snorts and she jolts and struggles as her throat flash fills with semen. She gags and chokes, swallowing his heavy load to take a desperate breath. Her face is twisted and another soldiers load gushes over her face. She gasps trying to blink away the semen coating one eye. More fingers grab her hair snatching her face around to meet another cock which is shoved deep into her mouth. Her eyes flash open to see it's one of Jacks big Black soldiers his meat a thick hard dark pole, the head a wide fat slab. She tries to pull away as he heaves it into her throat. Impaling her face. Hard rough hands squeeze and pull her hips as her cunt aches and contracts around the thick pole which hammers at her cervix. Short, hard, deep thrusts. His pubes rubbing and teasing her hardening clit as he saws in and out. O'Neils belly cramps and aches as the contents of her rectum is forced back and too. Her anus squeezes and twitches around the awful bung filling it. Her rapist pulls out and lets loose a thick heavy stream of cum all over her belly. O'Neils head is held fast as four inches are firmly rammed mercilessly into her throat. It's not going anywhere but deeper. She could feel it was up against her tonsils. His glans banged against them. She starts to gag. He lunges hard feeling another two inches slip in. He now grips her shaved head refusing to remove his cock from her heaving mouth, he rocks his cock back and forth going deeper each time. As he was tries to piledrive another inch into her windpipe. O'Neil helplessly tries to swallow to ease the pain as he begins to fuck her face violently, shoving his prick in until his balls cram against her held open teeth and his cock is shoved wholly down her throat. In the middle of one of these plunges he begins to cum. O'Neil's body jolts and shudders as he does. Somehow she manages to gulp down his salty bolts of jism. Mouthful after mouthful he feeds into her. Instinctively she starts to gulp down each hard flood of sperm as it explodes in her mouth. There's a lot. The others laughed watching as her cheeks began to balloon with the amount of thick hot cum. She swallows as fast as she can trying not to choke. She snorts and sperm spurts out of her nose. Her belly was rapidly filling with his heat. as more and more pumps straight down her unwilling throat. She could feel someone pulling her cunt lips open, fingers ramming into her twisting and turning. Forcing her cunt walls open as more fingers were eased in. making the pressure in her ass unbearable. Another couldn't wait and spray's hot Jiz across the peaks of her bound jutting hooters. Her teats coated with thick globs of hot semen, which is quickly rubbed in by cruelly kneading hands. She had to breath, she was on the brink of blacking out again, all she could hear was the others chanting. "Fist her, Fist her!" As it all went black. End of Part One. Enjoy MG.

Re:Yes, a confession. He is a criminal. (Score:0) by Anonymous Coward on Friday February 25, @09:31PM EST (#281)

Part Two Thrown on her back over a bench in the beach house Her tywraped arms pinned to the edge. A chain over her head snapped taught around her neck almost throttling her. Fastened to a bolt. Thick cord around each knee lifting them to the bench legs O'Neil was now suspended by her bound arms and throat, her ass hanging invitingly over the edge. Her BDU's torn from her legs, a plastic bag thrust down over her face . . Jack looked on as O'Neil went limp he barked an order the bag was lifted. She sucked in a desperate breath. staying out. Greg, one of his Sergeants was ramming four fingers into her cunt. The others looked on avidly as he worked and twisted them forcing her cunt walls to give. The others semen coating his fingers as he worked them in and out. Jack grinned and admired her tits. Coming to a decision he leant over and gripped her teats. Pinching and twisting them. He yanked and pulled more of her bulging breast flesh through the taught ropes. She groaned and stirred he gripped her breasts hard and viciously yanked them. more of her tits ballooned out. He grabbed the knot he had placed earlier and partially undid it and with his muscles bulging he pulled and snatched it tighter. and then tighter again. Now her breasts were two big fat udders forced up hard, her teats two thick hard nubs. She shuddered and moaned he looked back down at her cunt Greg's arm was punching up into her twat only the heel of his wrist visible. Her swollen labia bulging on either side. He flexed his arm and pressed and twisted. He chuckled and thumbed her lips wider, stretching and easing them out as he pushed and pushed. Her body jerked and her hips began to lift as his hand slipped deeper. He thrust it in and up again her hips began to dance as he strained. The muscles on his arm stood out hard as suddenly her cunt walls gave up the fight and his hand slid home encased deep inside her spasming vagina. "UHHH NOH NOH UUUHHHAARGGHH!!" she bellowed snapping to conciousness as his hand filled her aching twat. "Wakey wakey Lieutenant you don't want to miss being fisted!" he gloated her whole body strained and shook as they laughed. Jack rubbed his hands over her bloated tits. her nipples were rigid her aureole thick and crinkled as his attentions forced them to thicken and swell. Slick with the sperm that he rubbed in. "What's the problem O'Neil feeling full?" The fist was rammed hard up into her making her stiffen. Her cunt lips clenched around his thick wrist, as her twat burned and ached. Jack pulled her nipples enjoying the way they resisted his pinching and twisting. "Dobs get Captain Blondell in here!" O'Neils eyes went wide as the Dobs disappeared and came back with the Navy Doctor. She looked matter of factly at Lieutenant O'Neils predicament. "My my we have been busy gentlemen, OK what do you want this time Jack?" "Hey less of the attitude captain! we can easily swap your little voyeurs nest back there with a place on this bench yeah, did you get off yet? or have we disturbed your frigging?" "Shut up! just tell me what you want?" she looked really flustered. "I want you to give the Lieutenant here one of those nice big shots in her titties here. You know the ones I mean". "OK I can only do it the once though you know that yeah!" she started to rummage in her bag. O'Neil struggled frantically as she readied a syringe and filled it. Jack squose up her left breast cruelly. She winced in pain as the hypodermic entered her aureole and it started to heat as Blondell emptied the syringe into it. "OHHH GOHD GOHD NOH NOH URHHHHH!!" Jack let it go as the needle came out. leaving a speck of blood. He gripped the other and forced it up. "OHH UHUH OUU PHUKKERS UUURRGHHHH!" The refilled syringe sank into the other teat. and the contents was thumbed home. Jack let go and roughly rubbed both sore nipples. "How Quick?" "Quick!" she smiled. "Now if you don't mind I'll let you get on OK?" She closed her bag and turned to leave. "You want a piece of this?" jack asked, she turned back. "Oh yes later" she smiled and went. "BOOYAHHH!!" the others yelled and O'Neil jolted in pain and shock as Greg began fisting her poor impaled twat again. Her tits were on fire, aching and throbbing her nipples were itching and burning. Jack grinned down at her watching as her breasts began to swell. Her nipples were now sat on thick stiff aureole, they were beginning to swell themselves. He flicked them hard making her writhe and scream through the ring gag. "Oh you like that whore Oh Yeah!" he started to slap them feeling how hard both globes had become. He squeezed them and bounced them and played with them roughly by lifting them and then dropping them. He then placed his fingers on her nipples, using all his fingers around each nipple so that he pulled them in towards the nipple and captured each one with all his fingers. He squeezed hard over and over again pulling his fingers up and around the nipples squeezing and pulling over and over. Her nipples were getting harder and harder. He squeezed tightly and pulled her nipples up, lifting each one of her tits as he pulled. He pulled harder and harder so that her chest was forced up pulling more of each heavy swollen breast through the ropes he saw tears in her eyes. He laughed enjoying her distress. "Oh yeah O'Neil I love these babies I will never tire of abusing these fuckers, hey you like how big they've got, I bet they hurt too. Oh yeah they ache don't they? and you know what, we're gonna fuck em till they're blue baby uh huh!" "Talking of babies whore, That stuffs gonna make your titties believe that's what you've had. Oh Yeah an then your gonna be one big uddered milky cow, you gonna be filling up for weeks!" O'Neil groaned and shook as Greg began to spread his fingers as he fisted her. jerking and heaving his hand inside her. Her guts were awful her butt seemed to be pulsing around the bung, her rectum spasmed with the need to shit. "Bag Her" Jack ordered. It came down as she gasped for air. Her head thrashed back and forth. He lifted and dropped each tit, watching as they bounced and formed their ballooned shape again. He lifted them up again and then let them go. he started slapping the stiff flesh the same way as before, hurting her more each time and letting them fall back each time, marvelling at the bounce of each luscious tittie. "Oh Lieutenant I love your titties and I'm going to love shafting the fuck out of them baby!" He started slapping her breasts lightly at first as she strained and struggled her chest jutting out as she fought for air so that they bounced, and bounced with each heavy slap. He started slapping them from underneath lifting them up so that they would bounce heavily down, shuddering into place. He slapped them from the side. Jack watched he loved seeing them getting redder and redder as he slapped them really hard. He knew that constantly slapping them made her sore as he hit them harder. He got enormous pleasure as they slammed against each other. as she winced and fought to pull them away. Trying to twist her chest away from his hard strikes. He nodded the bag came up she sobbed and gulped air as he started smacking her nipples with the tips of his fingers. His fingers were long and acted like little floggers on each nipple. He would hit one nipple several times in a row before switching to the other one. Then he'd alternate flogging each one with his fingers. He loved the smack Thwack Flap smack sound his fingers made on her tits. He knew her tits had to be sore O'Neils face bore it out. Her eyes showed her pain as did her face which was incredibly tense. As her vision cleared O'Neil couldn't believe the size of her breasts they seemed huge. and so tender. Her teats burned and throbbed as he teased them. She could feel her cunt contracting around the fist rammed in it and his thumb kept circling and sweeping over her clit. She knew they were turning her on her body betraying her animal sexuality. She was losing control she could feel it. If only she could get rid of this awful pressure in her ass. Greg pushed his face to her clit and began lapping at it. Dob's shouted out. "Hey This whores gonna cum Look at her ass lift! C'mon O'Neil you piece of shit!" Jack stopped his slapping and began rubbing and pulling her nipples, He Shouted at one of the others. "You! suck and play with teats c'mon we've got the whore going. Heh Heh O'Neil your gonna be our fuck slave no doubt about it honey!" The soldier jumped at the chance and put his head down and his lips caught one of the tight sore nips in his mouth. He started sucking it like he was a baby. Sucking and sucking on it strong and hard. "BAG!" Jack shouted. it came down setting her struggling instantly. Her cunt ground down on Greg's fist as she arched her back. Her clit was a tight ridged button, which he flicked and clamped his lips over sucking hard. Her ass danced and swerved as he pulled and drew on it, pulsing his hand inside her cunt tube. O'Neil was thrashing wildly as the soldiers fed from her both breasts, catching her teats lightly in their teeth. Chewing and running their tongues around them. They're hands squeezing and pulling worrying her breasts to their hungry faces squeezing and pulling and rolling them around. Jack inhaled, through the sweat, he could smell her arousal she wouldn't ever want to admit it but they had her and she was going to come. She struggled and strained her mind screamed for air and them, sucking, nibbling, pulling. Her cunt ache growing and growing as he viciously fisted her clenching cunt until it was too much for her. She whimpered her mouth pressed to the plastic her eyes dimming in asphyxia. Her body wanted sexual release and her nipples were excruciating hard deep throbs of pleasure and pain shot through each heavy mammary. Her cunt started to squeeze tighter and tighter on Greg's fist. Greg lifted his face from her heaving cunt "Boss boss she's there!" Jack grabbed the two soldiers by the hair and wrenched them from her breasts. They slapped back her teats two fat red nubs. Milk Squirted out from each, running down the fat globes in rivulets. Greg yanked his fist out as the bag came up. GULP,GULP . . . "NNOOOOOOOOHH NNOOOOOHHH!!" she wailed Her cunt was an open hot pulsing pink tunnel. Her breasts two quivering balloons as she thrashed and wailed desperate to achieve climax. She pumped and swerved her ass. Straining and pulling on her arms and legs. "Shit that was lucky Lieutenant you nearly came then!" they all burst out laughing O'Neil sobbed and wailed as her cunt started to twitch and her contractions waned. Greg knelt between her legs, Jack joined him. Greg began to lap at her clit like a dog, long wet slurps that made her stiffen and sob. Jack looked on grinning as her body tensed and tensed her thigh muscles standing out in stark relief the cord taut holding them open. Her belly was as tight as a drum as she started to lift her ass as high as it would go. Greg motioned with his hand. Jack gripped the bung in her ass and fucked her butt with it. she let out a deep animal groan . Her body as tense as it ever was going to be. Jack suddenly yanked the bung out of her ass and she howled in shocked horror and disbelief as all the semen gushed out of her ass pouring down her open cleft to the floor. She went wild her twat fluttering with hard fast contractions as her belly released. Her mind went in an explosion of white light as her orgasm ripped through her her rectum spasming and clenching in time with her uterus as hot cunt juice sprayed out of her pouting pussy lips. Her body arching shuddering and snatching at her bonds as wave after wave of excruciating pleasure shot through her. She had hardly come too when jack was over her. He reached over and plucked up a pair of nipple clamps off the bench. He gripped each fat balloon and he placed the tweezers over her nipple and rammed the small rubber ring over it tightening it around her teat. She squealed as he did the same with the other. Then he yanked them viciously tight and pulling them together clipped a chain to them so that her teats were dragged together. O'Neil shook her head pleading as he wrapped the chain around his fist and pulled her tits taut. he released his cock and pushed the head to her still gaping sphincter. She tried to pull away but couldn't as he forced the thick head of his tool into her slick ass hole. ramming it up into her ass. She jolted and groaned as it sank into her virgin bowels. "Oh yeah O'Neil I'm going to ream your tight 'mightier than though' ass out bitch! You ain't gonna forget this Lieutenant! You're our fuck toy now honey" he thrust up into her ass. "UUUHHHHHARGGHHHHHHHHHHHHHHHHHHHHHHH!!" she wailed as he forced deeper. Yanking on her chained tits. End of Part Two Enjoy MG.

Re:Yes, a confession. He is a criminal. (Score:0) by Anonymous Coward on Saturday February 26, @03:41PM EST (#362)

Stroustrup is denying the validity of my opinions by refusing to agree with them. This is tyrrany. It's a symptom of the radical left-wing nature of the C++ programming language... Someone has been spending a little too much time on freerepublic.com...

Re:humility deficient (Score:1) by RPoet (haakon@nilsen.com) on Friday February 25, @12:50PM EST (#38) (User Info) http://haakon.nilsen.com

Scuse my ignorance, but what is Goslings regrets with regards to Java? Lack of multiple inheritance? Lack of operator overloading?

Re:humility deficient (Score:4, Insightful) by jilles (jgurp@yahoo.com) on Friday February 25, @02:09PM EST (#104) (User Info) http://www.ipd.hk-r.se/jvg

If you look back in this interview, you'll notice that bjarne has very clear ideas about how multiple inheritance should be used. If you compare that to what Java supports you'll find that it actually supports this type of usage (namely multiple inheritance of interfaces). The problem with C++ is that it has no first class representation of interfaces (which is why you need multiple inheritance of classes to imitate this feature). Java has support for interfaces built into the language so it can prevent people like you shooting theirselves and the companies they work for in the foot by abusing MI. If you are still sceptical about this, I would like to point out that there have been empirical studies about the use of multiple inheritance and these studies make it pretty clear that the use of MI for inheriting code is a bad idea in most cases. I don't really see the point of having operator overloading. The advantage of being able to overload them is fully consumed by the resulting confusing code. I don't want my + operator to be overloaded. I don't want to work on code where I have to look up what the + operator actually means. If assumptions I have about such simple things as + and - no longer hold true I can't do my work properly. My main problem with C++ is not that it lacks features but that provides to much of them. Java as a language is much simpler and the only problem I see with it is that it doesn't have support for templates yet. On the other hand there are many features in it that you only get in c++ if you are a skilled and disciplined programmer. Take for instance a simple concept: package. The package construct allows you to group classes into packages. Packages can be nested and the package is part of the class name (which makes it possible to have class names with the same name in different packages). Of course this simple feature can (and should) be imitated for large C++ projects but its just not as straight forward as in Java. Another feature is that Java assumes that your functions are virtual rather than static (as in C++). C++ obviously can't do this without breaking compatibility with C so OO programmers are doomed to type virtual in front of every method they declare. Another thing is the C compatibility. I don't see the point of it. True, in isolated situations it may be handy to be able to quickly port old C code (but then why not redesign it while you are at it?). In most situations though you are better of resuing the old code base in the form of libraries (as you do in Java with native methods). These little, well designed language features make life easy for a programmer. And that's exactly what a language should do. C++ programmers always complain about lack of features in Java but this is in sharp contradiction with actual productivity of programmers using C++ and Java. Also the fact that C++ is so close to C prevents it from doing certain optimizations (according to Bjarne in this interview). I'm not in favor of a one size fits all language. Especially if that means making compromises all over the place. C++ is one big compromise towards C compatibility and performance. In many projects C compatibility is not essential or even redundant and performance is not the primary quality requirement. C++ therefore is not the most suitable language for this growing category of projects. In many cases using C++ makes your programs needlessly complex and confuses the programmers. True, if you no what you are doing it can be a handy tool but unfortunately many programmers are not in that position. In the interview I noticed some frustration with the fact that there are still hordes of programmers using C (for non valid reasons). I feel a similar frustration towards the use of C++ and Java. True there have been and there are performance problems with Java. But just like most of these issues resolved with C++, most current issues with java will be resolved over time.

Re:humility deficient (Score:2, Informative) by HarpMan (smolitor@erac.com) on Friday February 25, @05:44PM EST (#189) (User Info)

You said: "Packages [in Java] can be nested and the package is part of the class name (which makes it possible to have class names with the same name in different packages)." It's the same with namespaces in C++: namespace Foo {       class Bob {}; } namespace Bar {       class Bob; } Namespaces can also be nested. They're not quite the same as Java packages (namespaces are strictly a logical concept, and can be spread across several files), but still they are very useful. Personally, I enjoy coding in C++ more than Java, mainly because of templates and the STL. The STL really changes ones approach to programing. Java's lack of template is a significant omission to me. I also appreciate the static type checking in C++. I don't see what the big deal is with interfaces vs. abstract classes -- they are equivalent concepts. It seems that your argument is that people who don't know what they are doing can screw up worse in C++ than they can in Java. This is probably true, and I can see why corporations would prefer a "dumbed down" language. But, I do know what I'm doing, and I prefer using a language that gives me lots of options. My biggest gripe with Java is that is proprietary. I prefer using a language that isn't controlled by a single company. The biggest problem with C++ is the way that most programmers use it -- using c strings instead of std::string, c arrays instead of vectors, etc. This is a matter of education. Steve Molitor Stephen Molitor steve_molitor@yahoo.com

Re:humility deficient (Score:2) by jilles (jgurp@yahoo.com) on Saturday February 26, @07:07AM EST (#342) (User Info) http://www.ipd.hk-r.se/jvg

I didn't know about the namespaces construct. I don't think it is exactly the same from what you said here. Abstract classes can indeed be used to imitate java interfaces. Yet there is a subtle difference: abstract classes may contain implementation whereas interfaces do not contain any implementation. This explicit separation between interface and implementation is very usefull. C++ can provide a similar mechanism (with a small performance hit) but does not enforce the separation. I protest against your qualification of Java as a 'dumbed down' language. I think it is a very smartly designed and elegant language.

Re:humility deficient (Score:0) by Anonymous Coward on Saturday February 26, @12:28PM EST (#352)

I think it is a very smartly designed and elegant language. That's because you're a jackass. Abstract classes can indeed be used to imitate java interfaces. Yet there is a subtle difference: abstract classes may contain implementation whereas interfaces do not contain any implementation. Well, then you're not using them to imitate the jave interface then are you? If you want a java interface class, make a pure virtual class, otherwise don't.

Re:humility deficient (Score:1) by HarpMan (smolitor@erac.com) on Saturday February 26, @06:55PM EST (#370) (User Info)

"I protest against your qualification of Java as a 'dumbed down' language." Fair enough. Java is a good, and powerful language. I personally enjoy programming in C++ more, since it has some features, like templates and the STL, that I really like. You're right Java packages and C++ namespaces are not exactly the same. Java's packages has some nice things about it, like package-local variables. I think this is similar to using file-local static (or anonymous namespace) variables in C/C++, but better since it's not dependent on the header/source file distinction. On the other hand, C++ namespaces are a completely logically concept that allow you to spread a namespace across multiple files and directories as one sees fit (but of course one could misuse this feature). I don't see what the big deal is over Java interfaces versus C++ pure virtual classes. They are exactly the same concept. The slight difference, as you mention, is that a Java interfaces may not contain implementation. But you can achieve the same effect in C++ just by not putting any implementation into your pure base class. Java makes this explicit, yes, so score one point for Java. On the other hand, C++ lets you build up incrementally to a concrete class, adding some more implementation in each derived (but still abstract) class. So, C++ gets a point for flexibility. Interfaces are not a feature that Java has and C++ lacks. Both languages support the concept, with some syntatic differences. Arguing which approach is better is hair-splitting. Interspaces exist in Java to make up for a feature that C++ has and Java doesn't -- multiple inheritence. The Java approach is simpler and less prone to abuse. The C++ approach offers more flexibility, if used properly. In general, where C++ opts for power and flexibility, at the cost of added complexity, Java opts for simplicity, at the cost of some power and flexibility. Java is gradually getting more and more complicated, however. The newest version of the Java "standard" is several times the size of the C++ standard. Stephen Molitor steve_molitor@yahoo.com

Re:humility deficient (Score:0) by Anonymous Coward on Friday February 25, @06:40PM EST (#216)

"The package construct allows you to group classes into packages [..] Of course this simple feature can (and should) be imitated for large C++ projects but its just not as straight forward as in Java." Well, maybe you haven't been around for quite some time, but C++ already has a similar (and much better, IMO) feature: namespaces. From my experience, the myth about Java being a simple language were maybe true 5 years ago, when it was an overly immature toy language. As with any other language, the maturation and growth of Java has led to fragmentation, deprecation of older features (RMI vs. EJB is only one example), and addtional features that make it much more complicated than it had been (weak references, reflection, and several others). Btw, the claim that overloading + is a bad idea didn't impress Java designers when they allowed string objects to support concatenation through an idiosyncratic form of an overloaded +. If overloaded + is good for strings, why isn't good enough for complex numbers, Date objects and matrices?

Re:humility deficient (Score:1) by RPoet (haakon@nilsen.com) on Friday February 25, @07:48PM EST (#255) (User Info) http://haakon.nilsen.com

Using the + operator for string concetenation is extremely natural. I can't think of any ways "Hello " + "world" wouldn't "sum up" to "Hello world". For more complex structures such as dates and matrices there could be confusion, and having "add" methods instead of "special function" operators seems far better (although perhaps not from an efficiency stance?).

Re:humility deficient (Score:0) by Anonymous Coward on Wednesday March 01, @02:36PM EST (#399)

What if you were using strings because (e.g.) they were a fast-n-easy way to store byte vectors? A reasonable result for ("Hello" + "world") might then be "\337\324\336\330\323". Of course this is slightly tongue-in-cheek; I'm just pointing out that (IMO) operator overloading, except for certain carefully controlled cases, is a crock. Algernon Swinburne

"weak references"? (Score:0) by Anonymous Coward on Saturday February 26, @12:51AM EST (#313)

Since when does java have weak references? Do you even have a clue as to what that term means? I don't think you do.

Re:"weak references"? (Score:1) by Wastl (wastl@wastl.net) on Saturday February 26, @06:10AM EST (#337) (User Info) http://www.wastl.net

Since JDK 1.2 you can declare references "Weak", "Soft" or normal, affecting the behaviour of the garbage collector. According to the documentation, one usage of this is to implement "memory-sensitive caches". See the java.ref package for more details. Sebastian

Java fails to produce (Score:0) by Anonymous Coward on Saturday February 26, @06:42AM EST (#341)

I have a couple main problems with Java, that cause me to prefer to program in C++. My main problem with Java is that it fails miserably on one of the main things it was advertised to guard against - resource leakage. Because there is no commonly-named destructor or close method in a java class, there is no real easy way to call one without having to think about it. Look through the whole of the Java class libraries and see how many ways there are to instruct a java object to free the resources it holds, how many different names they have. Further, there is no way to guarantee they get called at any particular time or in any order. The finalize method is too vague to be of any real use. I read on in Sun's newsletter about using a finally clause for resource termination, so I guess you would do: try{ Foo a = new Foo(); a.doSomething() }finally{ a.terminate(); } and you can reasonably guarantee that the object frees its resources. But compare this to C++: Foo a; a.doSomething // a is destroyed when it goes out of scope My point here is that Java was hyped as a language where you could write quality, complex code without having to be an expert or having to manually remember to do certain things, but that is simply not true, and the workarounds are worse than the common way in C++ simply because they're not standardized. Java has been heavily advertised as not having memory leaks, but in my experience memory leaks are one of the biggest problems with it, just because of the garbage collection - keeping a reference to something around and keep megabytes of data in memory! Diagnostic tools help, but really shouldn't be necessary. My other problem with Java is simply that it doesn't support programming to an OS'es native API's in any reasonable way. If you have a particular function or a few functions you want to call, you can write a JNI library. But before you'll see me using Java in any widespread way, I'll expect to see documented and supported class libraries that interface with the OS I want my code to run on. That's right! I want to target Java for an individual OS. I know this is quite antithetical to Sun's "pure java" scheme, which is part of its strategy to wrest control away from windows. I'm not saying I want to use Microsoft's Java. What I'd like is to write Java on _any_ platform and get native-quality support. I wrote an application that used the javax.comm package to do serial communications with a scientific instrument. I was converting a MacOS C++ application to Java so it could be cross-platform. Javax.comm supports enumerating port names as user-readable strings, so on the Mac, the user could see "printer port" and "modem port" when selecting where to communicate, while on Windows, they would see "COM1:" and "COM2:". The problem was that the javax.comm package was originally written by Sun for Unix, and didn't have the concept of printer and modem port icons. When a Mac user wants to know where to plug in the cable, they expect to see a little picture of a printer or a telephone. The concept just didn't exist in javax.comm. I know it's kind of a minor and a petty thing, but it really irritated me at the time. Swing is nicer than AWT, but I still see it as least-common-denominator, just with the LCD raised a bit. I'm a long-time MacOS and BeOS programmer, and I really pride myself on writing nice user interfaces. I just can't get that in Java. What I get is UI's from (pardon me) some OS that doesn't value quality UI design just sort of dressed-up to look like the Mac. Mike Crawford GoingWare - Expert Software Development and Consulting http://www.goingware.com crawford@goingware.com

Re:Java fails to produce (Score:2) by jilles (jgurp@yahoo.com) on Saturday February 26, @07:37AM EST (#343) (User Info) http://www.ipd.hk-r.se/jvg

I'm not sure I follow you on the subject of "resource leaking". I never experienced any problems in that area. Obviously you are unaware of the finalize method you can declare to do exactly what you want. The whole point of garbage collecting is that you don't need to worry about it. As a consequence you don't control when an object is destroyed. Rather it becomes eligible for destructions when there are no references to it anymore. A manual destruction would make java unsafe since you no longer can enforce that objects need to be unreferenced before destruction. BTW you can tell the garbage collector to collect the garbage when you need to do so but usually it is a better idea to let the garbage collector figure out a suitable moment to do so.

Re:Java fails to produce (Score:1) by HarpMan (smolitor@erac.com) on Saturday February 26, @07:01PM EST (#371) (User Info)

"Obviously you are unaware of the finalize method you can declare to do exactly what you want." I think he wants to be able to ensure that a resource gets freed immediately when an object goes out of scope. You can't do that with finalize. Finalize just guarantees that the resource will get freed sometime. For example, lets say I have an object that opens a file. I could use finalize to make sure the file gets closed, but I'm not sure when that's going to happen. That file might be and important resource that I want to get freed immediately after my object goes out of scope (and can't possibly use the file anymore), so that other objects can open the file. C++'s destructor mechanism guarantees that; finalize just guarantees that the file will be closed sometime before the program exits. Stephen Molitor steve_molitor@yahoo.com

Re:Java fails to produce (Score:2) by jilles (jgurp@yahoo.com) on Sunday February 27, @05:04AM EST (#376) (User Info) http://www.ipd.hk-r.se/jvg

I don't see how the destructor mechanism guarantees anything since you still have to make sure it is called yourself. Rather I think that this is a major source for bugs in C++ (people forgetting to destroy an object or doing it too early). In Java it is typically a bad idea to release resources late (since A you don't know when the object will be destroyed and B you probably don't need the resource throughout the lifetime of an object. The try catch finally mechanism provides a great replacement since this captures the notion that using a resource is a bit like a trans action: book the resource, do your thing, handle possible errors, release the resource. The only problem that I detect here is that someone is trying to do C++ style programming in Java. While it works it is probably a better idea to adopt the java style. I think differences in programming style between Java and C++ are one of the reasons so many C++ to java porting projects fail. It's just sub optimal to program Java in a C++ style.

Re:Java fails to produce (Score:1) by HarpMan (smolitor@erac.com) on Sunday February 27, @05:20PM EST (#379) (User Info)

"I don't see how the destructor mechanism guarantees anything since you still have to make sure it is called yourself." In C++, the destructor is ALWAYS called when the object goes out of scope. You NEVER have to call destructors yourself; it's usually considered very bad form to do so. That's why destructors provide a guarantee in C++. So, you don't need try...finally in C++ -- the destructor takes the place of the finally block. Destructors are always called (guaranteed), and you know exactly when they will be called. You can accomplish the same thing in Java with try...finally, but you have to litter your code with try...finally blocks. In C++, a resource is encapsulated as an object, and you only have to write the cleanup code in the destructor once. And you NEVER have to call it yourself. I repeat -- you do NOT have to make sure its called yourself. Destructors are automatically called when the variable goes out of scope. I'm not sure how pointing out the differences between Java and C++ regarding resource handling (and having an accurate understading of those differences) translates into trying to do C++ style programming in Java. Undestanding the differences between the two languages would seem to be the way to AVOID misapplying approaches that are appropriate in one language to the other. Perhaps if I misunderstood C++ as much as you do, that would make me a more "Java" style programmer? Stephen Molitor steve_molitor@yahoo.com

Re:Java fails to produce (Score:2) by jilles (jgurp@yahoo.com) on Monday February 28, @02:34AM EST (#386) (User Info) http://www.ipd.hk-r.se/jvg

In Java, keeping a resource for the entire lifetime of an object is bad programming style since you cannot know for sure when the object is going to be destroyed or even when it gets out of scope (potentially a long time). That's why it would be bad style in Java to release resources in the destructor (you needlessly occupy resources). You are probably right about C++. Though I know some of the language I never bothered programming in it. I learned C when I studied at the university and I've seen a host of other languages as well (some very exotic). Anyway judging from your post you misunderstand Java as least as much as I misunderstood C++.

Re:Java fails to produce (Score:1) by HarpMan (smolitor@erac.com) on Monday February 28, @10:32AM EST (#392) (User Info)

"In Java, keeping a resource for the entire lifetime of an object is bad programming style since you cannot know for sure when the object is going to be destroyed or even when it gets out of scope (potentially a long time). That's why it would be bad style in Java to release resources in the destructor (you needlessly occupy resources)." Exactly. I know that -- in Java you don't know exactly when destructors will be called, so you can't use them to manage resources. You can't truly encapsulate a resource as an object via Java. I'm not saying I would try to do this in Java. I might want to, but I can't. In Java, if you needed to control exactly when a resource gets freed (and this happens, especially for non-memory related resources), you have to use try..finally, not the destructor (since it won't do what you want). C++ is nicer than Java is this respect. Please tell me where I have made inaccurate statements about Java. I think I understand Java's approach to resource allocation, destructors, etc., pretty well. Stephen Molitor steve_molitor@yahoo.com

Re:Java fails to produce (Score:0) by Anonymous Coward on Wednesday March 08, @01:33AM EST (#406)

Freeing resources is an assertion that you aren't using them and neither is anyone else. Not an assertion to be made lightly (and certainly not automatically) unless you really enjoy debugging.

Re:Java fails to produce (Score:0) by Anonymous Coward on Sunday February 27, @09:56PM EST (#382)

Finalize just guarantees that the resource will get freed sometime. that's not true. you have no guarantee that a finalizer is called, that's the problem. read the jdk 1.2 docs and you'll now why.

Re:Java fails to produce (Score:0) by Anonymous Coward on Sunday February 27, @09:53PM EST (#381)

Obviously you are unaware of the finalize method you can declare to do exactly what you want. read his article again, he said: The finalize method is too vague to be of any real use. obviously YOU are unaware of the fact that finalizers may or may not be called. you just can't be sure that an object is destroyed properly (connections and resources are closed).

Re:humility deficient (Score:1) by HalB on Saturday February 26, @12:09AM EST (#305) (User Info)

Okay, this is slightly tangential but I think it is worth mentioning. 8') I don't really see the point of having operator overloading. The advantage of being able to overload them is fully consumed by the resulting confusing code. I don't want my + operator to be overloaded. I don't want to work on code where I have to look up what the + operator actually means. If assumptions I have about such simple things as + and - no longer hold true I can't do my work properly. Try to make a transparent persistent store without operator overloading. I've been trying for quite some time to make on in Java, and I can't seem to do it. Perhaps you, or someone more clever than I can manage it (please tell me how!). But until then, I find Java to be insufficient for my needs because of this key lack of facility. I also think this reflects a fundamental problem with Java that you have touched on. It is restrictive such that developers can't write code which they consider good form and useful unless the Java designers also consider it good form. Specifically because they break their own rule in one case and overload operators with string types (and I'm glad they let us have some better string facilities, don't get me wrong) but they won't let us make our own operators on our own types which we think are useful! Coding standards are certainly good, and I certainly recommend it within an organization. For a language meant for many different organizations, however, it is this kind of arrogance that leaves a bad taste in a lot of developer's mouths and make people like myself not want to use what is otherwise an excellent language.

operator overloading (was Re:humility deficient) (Score:1) by jejones on Saturday February 26, @10:35AM EST (#347) (User Info)

What makes operator overloading particularly obnoxious in C++ is that you're limited to the existing operators--which carry their own connotations (hard won over years, or in the case of the usual arithmetic operators, nearly a lifetime, of drill and use). These connotations mostly work for types with some algebraic structure, but once you get away from them, you're guaranteed confusion--the primordial example being the overloading of the shift operators for stream I/O. In contrast, Algol 68 provides a wide variety of possible operator symbols--and if C assignment operators yielded reference modes like Algol 68 assignment operators, it would be convenient to use the operators for I/O that actually carry the connotations that make sense, += and -= (doing output appends to a stream, doing input removes something from it.

Re:humility deficient (Score:1) by dkixk on Wednesday March 01, @02:40PM EST (#400) (User Info)

In favorite programming languages, operating systems, editors, et cetera... to each his/her own. However... I don't really see the point of having operator overloading. The advantage of being able to overload them is fully consumed by the resulting confusing code. I don't want my + operator to be overloaded. I don't want to work on code where I have to look up what the + operator actually means. If assumptions I have about such simple things as + and - no longer hold true I can't do my work properly. I think operator overloading has provided a valuable tool for allowing code to define types which can be used anywhere that a builtin type can be used and in exactly the same way that a builtin type can be used. For example, I personally can not stand having to switch between java.lang.Integer and int in Java code. One can not overload the operators for the builtin types and so the meaning for these types is set-in-stone. Why would it surprise you to have to search for the meaning of an operator for a user-defined type? And why should the use of something like TYPE::operator+ be any more confusing than something like TYPE::plus(). For example, consider if one were to define a class for complex numbers in Java and one wanted to be able to add them together. Without operator overloading, one would have to do something similiar to public class Complex {     void plus(Complex rhs) {         // Do stuff here     } } Why is this any more clear than the C++ approach of using operator+? However, the true advantage of the overloaded operator for C++ is that one can, for example, write a generic function such as std::accumulate which will work on ints as well as Complex, etc. One could not do this in Java. Another thing is the C compatibility. I don't see the point of it. True, in isolated situations it may be handy to be able to quickly port old C code (but then why not redesign it while you are at it?). In most situations though you are better of resuing the old code base in the form of libraries (as you do in Java with native methods). I think that compatability with C is very useful. I have just finished working on a project in which we were writing Java code which needed to make use of various C/C++ libraries for which we were unable to find a Java replacement and for which we were unable to devote the time to write a Java version. True, the Java Native Interface allows Java code to incorporate C/C++ code but I find writing JNI code to be a couple of orders of magnitude more difficult than simply using extern "C" /* something or other */ and running with it. And the reality is that there is a lot of C code and C libraries out there which provide a lot of useful functionality and are of significant complexity and/or magnitude such that reimplementing them all over again would be expensive both in terms of time spent and salaries paid. On the other hand there are many features in it that you only get in c++ if you are a skilled and disciplined programmer. Take for instance a simple concept: package. The package construct allows you to group classes into packages. Packages can be nested and the package is part of the class name (which makes it possible to have class names with the same name in different packages). Of course this simple feature can (and should) be imitated for large C++ projects but its just not as straight forward as in Java. Actually, I believe that the ANSI/ISO C++ addition of the namespace provides the same degree of functionality as does the Java package. In addition, I wish that there was a Java equivalent to the C++ feature of being able to provide an alias for a namespace. However, I think that our main differences of opinion on C++ and Java can be summerized by your following statement My main problem with C++ is not that it lacks features but that provides to much of them. Java as a language is much simpler [...] My main problem with Java is that it tries to force the coder into its own narrow view of what is "the right way" to program. When designing and implementing a solution to a problem, TIMTOWTDI. Which solution is the best frequently depends on any number of different circumstances and so having an number of different options available is a strength, not a weakness. C++ allows different ways to do MI while Java only allows interfaces. C++ can do everything Java does with an interface and more. Why is this a weakness of C++? Stroustrup mentioned his having made a conscious decision to make C++ a multi-paradigm programming language. However, Java allows for only "one true way" and that way is object orientation. Why is this a weakness of C++? In C++, the default is for explicit memory management via new/delete. However, if one wants to use garbage collection, it is possible to incorporate it. However, with Java one can only use garbage collection and can not opt to use explicit memory management if it would be useful. Why is this a weakness of C++? Since when does greater flexiblity, adaptability, and more options mean worse, weaker, and less desirable. <pause> Hopefully I won't be guilty of committing a programming analogy of the blunder that social-Darwinism commits by misapplying theories in the wrong domain but <breath> doesn't evolutionary theory give a useful example of why flexibility, adaptability, and having lots of options is a good thing? As far as I see it, the only true advantage that Java has over C++ is the free availability of an enmorous class library for networking, database access, et cetera, and the fact that it is an interpreted language allows for more dynamic, run-time bindings than does C++; e.g. the Java URLClassLoader. However, C++ has class libraries that match the Java libraries in functionality (e.g., RogueWave, the Adapative Communications Environment (ACE), et cetera) and some of them (e.g., ACE) are also free. So, while C++ may be more complicated than Java, I believe that this added complexity is due to C++ being a much richer language than Java and not because C++ is poorly designed or "chaotic". No language is perfect but I believe that C++ does a good job.

Re:humility deficient (Score:3, Insightful) by LordEq on Friday February 25, @01:03PM EST (#57) (User Info)

> I was looking for some reference to "I wish I > had done that better" or something. "I think my most obvious mistake was not to introduce templates before multiple inheritance and not to ship a larger library with Release 1 of my C++ compiler." "I, and the standards committee, underestimated the importance of templated typedefs. My guess is that they will be added in the future." "I guess that in this case, my reluctance to add new features without a clear practical need caused problems." "I underestimated the linker problems. I may also have underestimated the problems stemming from C compatibility." There you go. --LordEq "And the tree was happy... but not really."

RTFA (Score:0) by Anonymous Coward on Friday February 25, @01:05PM EST (#61)

I was looking for some reference to "I wish I had done that better" or something. Have you considered reading what he wrote? That might be a good way to find out what it says. God knows the man has an ego, but your comment just isn't accurate.

Re:humility deficient (Score:0) by Anonymous Coward on Friday February 25, @02:54PM EST (#118)

Yeah this is the guy who at one time usurped the name "C" for his new language, and was referring to K&R as "old C" around AT&T ... until Dennis Ritchie told him to knock it off :) I think he does acknowledge that the committees have straightened out a lot of the problems in the earlier versions of the language, and I don't think he would claim current C++ is perfect. Given his success and recognition, I'd probably be a bit arrogant myself :)

Re:humility deficient (Score:1) by brausch on Friday February 25, @04:18PM EST (#154) (User Info)

from Bjarne's web site: http://www.research.att.com/~bs/bs_faq.html Why is the language called C++? For the first few years, I called my language ``C with Classes.'' However people had taken to calling C with Classes ``new C,'' and then C. This abbreviation led to C being called ``plain C,'' ``straight C,'' and ``old C.'' The last name, in particular, was considered insulting, so common courtesy and a desire to avoid confusion led me to look for a new name. I picked C++ because it was short, had nice interpretations, and wasn't of the form ``adjective C.'' In C, ++ can, depending on context, be read as ``next,'' ``successor,'' or ``increment,'' though it is always pronounced ``plus plus.'' The name C++ and its runner up ++C are fertile sources for jokes and puns - almost all of which were known and appreciated before the name was chosen. The name C++ was suggested by Rick Mascitti. It was first used in December of 1983. There have been at least a dozen languages called D. See D&E for more name trivia.

plain C (Score:1) by delmoi (delmoi at hot mail dot com) on Friday February 25, @04:37PM EST (#169) (User Info)

Actually, I usually call C "Straight C", I may have to start calling it "Old C" though, just so I can be as insulting as I can. Perhaps "backwards-thinking C" (Or C--) :P [ c h a d   o k e r e ] "Subtle Mind control? why do html buttons say submit??

Re:humility deficient (Score:1) by delmoi (delmoi at hot mail dot com) on Friday February 25, @04:27PM EST (#160) (User Info)

I was looking for some reference to "I wish I had done that better" or something. Even Gosling has his regrets... Well, maybe he does Think C++ is perfect. I mean, if there was anything he didn't like, he could simply take it out. Stuff has been removed from C++ you know (such as reassigning the this pointer). Do you think its impossible for someone to spend 20 years working on something, and in the end, not think it was perfect? He said that there were things that still wanted to implement, but chiding someone for not having humility for humility's sake is kind of silly. Steve Wozniak comes across as having a high opinion of himself in writing as well, but no one could argue that he doesn't deserve it... [ c h a d   o k e r e ] "Subtle Mind control? why do html buttons say submit??

Re:humility deficient (Score:2) by mindstrm (moctodemohtamrtsdnim) on Friday February 25, @07:32PM EST (#249) (User Info)

I don't look at it that way. It souds to me like he doesn't dwell on it! It was one of many projects he's worked on, and not somethign that defines his existence. When asked if he could go back and change anything, his answer starts with 'But you can't go back...'.. which is true.

Thank You Moderators... (Score:2, Interesting) by GoofyBoy on Friday February 25, @12:22PM EST (#9) (User Info)

...for picking good questions and moderating down that old joke/fake interview about C++/job security and any questions associated with it. Moderation worked.

Re:Thank You Moderators... (Score:1) by Valur (patcasady at netcarrier dot com) on Friday February 25, @12:36PM EST (#21) (User Info)

I was a moderator Monday, and I thought the fake inverview was funny. ;)

Re:Thank You Moderators... (Score:2) by roblimo (roblimo.nojunk@slashdot.org) on Friday February 25, @01:17PM EST (#70) (User Info)

The fake interview *was* funny - but it wasn't a question... - Robin

Re:Thank You Moderators... (Score:0) by Anonymous Coward on Friday February 25, @06:47PM EST (#220)

>...for picking good questions and moderating >down that old joke/fake interview about C++/job >security and any questions associated with it. > >Moderation worked. Actually, he has addressed this insipid joke so many times before. Look at his homepage and see what he says about it (yes, that "interview" is a total fake). www.research.att.com/~bs -> FAQ

Complexity the cause of poor education? (Score:5, Interesting) by raph (raph+slash@acm.org) on Friday February 25, @12:26PM EST (#12) (User Info) http://www.levien.com/

Bjarne mentions the poor education of C++ programmers frequently in this interview. I can't help but think, is this poor education a direct result of the complexity of the language? I think that it's a much shorter learning curve to learn the C language fairly well than C++. I think this has helped in the Gnome project, although I'm sure there are people who feel differently. That said, many of the historical reasons for disliking C++ are becoming obsolete. In particular, the language seems to be settling down standards-wise, and there are now decent implementation to be had, both free and non. I've only used C++ sparingly in my own work so far, but I look forward to expanding my use of the language.

Re:Complexity the cause of poor education? (Score:5, Insightful) by DaveHowe (DaveHowe@Hawkswing) on Friday February 25, @12:35PM EST (#19) (User Info)

Bjarne mentions the poor education of C++ programmers frequently in this interview. I can't help but think, is this poor education a direct result of the complexity of the language? More likely the fact that C++ tends to be taught by lecturers more familiar with C. I suspect better training for lecturers would result in better training for students :+) I think that it's a much shorter learning curve to learn the C language fairly well than C++. I think this has helped in the Gnome project, although I'm sure there are people who feel differently. I suspect a lot depends on what you have learned before it - I found C easy to learn having already studied Basic, Cobol and Pascal - all procedural languages. Had I went from a base of OO language to C++, I would probably have regarded the C subset as a primitive reminant suitable only for things not worth wasting the full glory of objects on..... That said, many of the historical reasons for disliking C++ are becoming obsolete. In particular, the language seems to be settling down standards-wise, and there are now decent implementations to be had, both free and non. I've only used C++ sparingly in my own work so far, but I look forward to expanding my use of the language. I am being dragged kicking and screaming into C++ :+) well, I might not be THAT badly off, but the Microsoft Visual C++ compilers seem to go out of their way to make using classic C awkward, so I am having to adopt C++ in self defence. --         -=DaveHowe=-

Re:Complexity the cause of poor education? (Score:2, Insightful) by Steve Burnap (sburnaplinux@attSPAMSUX.net) on Friday February 25, @12:58PM EST (#51) (User Info)

More likely the fact that C++ tends to be taught by lecturers more familiar with C. I suspect better training for lecturers would result in better training for students :+) Odd, one of the problems I've seen is that lecturers concentrate on the C++ aspects of C++ too much and give the C aspects short-shrift. The biggest problem I see in day to day coding maintaining stuff written by people who are poor C++ coders is overuse and misuse of the advanced parts of C++. If I had a nickle every time multiple inheritance was used unneccesarily...

Re:Complexity the cause of poor education? (Score:0, Flamebait) by Zurk (zurk@SPAMSUCKSgeocities.com) on Friday February 25, @02:04PM EST (#100) (User Info)

The problem with C++ is that it basically sucks - it was meant as a powerful offshoot of C but instead turned into a large and *really* complex language..went waay too far out in the left field. Hell, even experienced C programmers cant pick it up easily. On the other hand, Java, besides its lack of multiple inheritance and all, was C++ done right. Java is easy to use, forgiving, has memory protection, easy to debug etc etc. In other words people - if you invent a proigramming language invent a forgiving one and one thats simple to understand for newbies. not everyone is an expert and this results in a cruddy mess of code like C++. there may be nothing wrong with C++ as a language or a compiler, but for most humans its a mess and the learning curve is simply *too steep*.

Re:Complexity the cause of poor education? (Score:2, Interesting) by nevets (srostedt AT stny DOT rr DOT com) on Friday February 25, @03:30PM EST (#132) (User Info) http://home.stny.rr.com/rostedt

I'm sorry, but did you read the interview? Ok, if you don't have time, let me point out the paragraphs that relate to your post. 1. Naturally, you can write poor programs in any language. C++ is a powerful tool and in the wrong hands it can generate code that is *obviously* contorted and bloated. That may be preferable to the traditional spaghetti that poor programmers produce in C. Note that someone who is a good C programmer isn't automatically a good C++ programmer. Many problems have been caused by good C programmers assuming that they could adopt a semi-random collection of C++ language features and then magically become a good C++ programmer in a week 2. C++ supports powerful techniques that are at best weakly supported by C and learning these techniques takes time. C programmers might do well remembering how long it took them to become "master level" C programmers. I see no reason why it would take less time to become a "master level" C++ programmer. 3. Let me just mention something I wouldn't have done differently: compatibility. Had C not been there to be compatible with, I'd have chosen compatibility with some another language. Innovation should focus on improvements and what works should be left as unchanged as possible. That way, people keep their existing tools and techniques and can develop from a base that is functionally complete. Also it saves the effort to re-invent the wheel and to teach "new" stuff that is equivalent to old stuff. Thus, C++ is as close to C as possible - but no closer Basically, he is saying: treat C++ as a new language but I will base it off of one that is familiar. It is a true language, as for Java, that doesn't scale. C++ is a lower level language that incorporates OOP but with lower overhead and still keeps the speed of C. Java is best for high level apps (or applets) and C++ is good for the real programs. Steven Rostedt -- "The MaTux has you." with Bob McLaren's Neo Tux!

Re:Complexity the cause of poor education? (Score:1) by lient (lient@mrs.umn.edu) on Friday February 25, @08:46PM EST (#275) (User Info) http://www.mrs.umn.edu/~lient/cgi-bin/funkpalace.cgi

Ok, I know BJarne doesn't like comparisons but I think they are important in software decision making. I used both C++ and Java regularly and I can say that both languages have definite advantages. On one hand, Java is a safer language to program in. It does not allow pointers, implicit booleans with ints, has garbage collection built in, ... These things being said, Java is a beast. In it's current state, I don't think any serious programmer is going to design a program that requires any sort of high performance execution in Java. C++, on the other hand, does efficiency very well. When used correctly, it can also be reliable, leaner, meaner, and trimmer than Java. The features that are dangerous were mostly inherited from C, and it was a realists design decision, rather than an OO purists. From reading BJarnes comments, I don't think he was after being "pure" anyway. Another defense of C++ is templates, templates, templates. Everywhere in Java, you have all sorts of casting everywhere. To clone you have to cast, to get an element of a specific type out of a Vector you have to cast, etc... Aside from being just plain ugly, this also introduces more Runtime ClassCastExceptions that could be avoided. Another reason Java is more bloated looking is the lack of operator overloading. Here is a good example of Java code bloating. Java: // define a Vector // ... int i=((Integer)v.elementAt(1)).intValue(); C++: // define a vector // ... int i=v[1]; These issues are way oversimplified, but these are some important ones. Overall I think the final decision to use one or the other depends on the project, and the coder. The project because some things such as system programming cannot be done in Java. The coder because the languages operate on different philosophies. Java's philosophy is that it doesn't trust the coder. Since other people have made mistakes with useful features in the past, it just got rid of them. C++ is feature rich, gives you a lot of options, and let's you break your own neck with them if you want to. Java gives you training wheels so that you can't do that. Once you mature as a coder, you won't need them as much, and you will start getting really annoyed with them when your doing the Iron Man. -Tommy G Out

Re:Complexity the cause of poor education? (Score:0) by Anonymous Coward on Friday February 25, @09:28PM EST (#280)

I don't think any serious programmer is going to design a program that requires any sort of high performance execution in Java I was in Java training classes this week and the instructor claimed that Sun has a new compiler coming out with the same level of performance as C++..........heard that one before though, I'll believe it when I see it.....

Re:Complexity the cause of poor education? (Score:2) by DaveHowe (DaveHowe@Hawkswing) on Saturday February 26, @06:41PM EST (#367) (User Info)

Odd, one of the problems I've seen is that lecturers concentrate on the C++ aspects of C++ too much and give the C aspects short-shrift. The biggest problem I see in day to day coding maintaining stuff written by people who are poor C++ coders is overuse and misuse of the advanced parts of C++. If I had a nickle every time multiple inheritance was used unneccesarily... I've obviously been away from Academia too long <grin> - When I learnt C, C++ was still in it's new, shiny wrapper, and most of the lecturers were obscessed with Pascal anyhow :+) --         -=DaveHowe=-

Lecturers (Score:0) by Anonymous Coward on Friday February 25, @07:04PM EST (#235)

More likely the fact that C++ tends to be taught by lecturers more familiar with C. I suspect better training for lecturers would result in better training for students :+) More familiar with C? What a luxury! My first C++ instructor was a COBOL programmer who seemed to be learning C++ along with us... he'd read off his notes, and if we asked a question he would have to look in the text for the answer (like we couldn't have done that ourselves). But what are you going to do, who wants to make academic money if you really know how to program? My second professor knew the language, but that of course meant he was more focused on his consulting work and put as little into our class as possible. Thank goodness my third professor was both a good programmer and genuinely interested in academia so that I finally got a brainload of good stuff! The problem is how to get people like him in the classroom and keep them there... that's how we will get good programmers.

Re:Complexity the cause of poor education? (Score:1) by Harri on Monday February 28, @04:23AM EST (#387) (User Info)

>> I think that it's a much shorter learning curve to learn the C language fairly well than C++. I think this has helped in the Gnome project, although I'm sure there are people who feel differently. > I suspect a lot depends on what you have learned before it - I found C easy to learn having already studied Basic, Cobol and Pascal - all procedural languages. Had I went from a base of OO language to C++, I would probably have regarded the C subset as a primitive reminant suitable only for things not worth wasting the full glory of objects on..... I can confirm that... I came to C++ from Java. I did learn some BASIC first, but I've almost forgotten it. Nobody ever taught me what was good functional programming style. However, my degree course was based around Java and OO programming. When faced with C++ I was able to make the conversion fairly painlessly: it wasn't the objects that were the problem, just the pointers! At this stage my C++ may or may not be a very good style example (I hope it is!) but I know it's better than anything I could hope to write in C after a similar learning time. I just don't know how to write functional programs. I'd be forever trying to write C++ in C, rather than getting on with learning C and writing that instead - just the mistake C programmers make when they learn C++. Only, there are plenty of trendy texts explaining OO style to C programmers, and a lot less explaining functional programming to OO programmers.

Moderate this up, please! (Score:4, Insightful) by adubey (non_sequitur_boy@yahoo.com) on Friday February 25, @01:19PM EST (#73) (User Info)

(Refering to the post I'm replying to). In my experience, much of the unavoidable complexity of C++ comes from the fact that you can use either pointers or references to refer to objects. Note the distinction between "unavoidable" complexity and the avoidable complexity of templates and multiple inheritance - often you can't get around this. References are nice because the "->" operator is brain-dead: why should the programmer keep track if something is a pointer or not when a type-safe compiler can figure out if "." or "->" is suitable. But references, unforutnately, can't be used everywhere. The lack of an ABI might be one reason. The fact that Linux/Unix only has 'C' style interface is another, related reason. (NB: Windows _does_ have MFC to abstract OS functionality, if you want it. From what I hear, it doesn't abstract that functionality very well, though...). But you sometimes have to mix pointers and references for the simple reason that you can't re-assign references. In code, this might be no problem, but what about classes? Another unavoidable complexity deals with the language's decision not to have proper "interface"/"implmentation" files. On one simplistic level, it means I have to unnecessarily type in: #ifndef __MY_HEADER_H__ #define __MY_HEADER_H__ ... #endif But there are other annoyances. For example, you can't statically initialize static member variables! To be honest, you can, but not the way that a programmer would naively expect: class {         static int foo = {1,2,3,4}; }; just doesn't work. Things like this are the gravest error a language designer can make: if the language doesn't work in the way a naive programmer would expect, you *need* to become experienced and learn the special cases. Re: bloatedness. Stroustrup makes the assertion that if you use C++ right, you won't have bloated code. With G++ at least, it is difficult to use STL in *any* way without bloating your code. Perhaps this is a shortcoming of g++ rather than C++. However, I think that the design of C++ makes it difficult for compiler writers to make efficient STL code. In some sense, I feel like C++ is like Windows: people use it because they have to, not because they want to. And "have to" doesn't mean it's imposed, sometimes it just means that tools have been developed for it that are unavailable elsewhere. In many languages, I simply can't use yacc, makedepend, the Unix API, etc, etc.

I love pointers (Score:0) by Anonymous Coward on Friday February 25, @06:25PM EST (#209)

References are nice because the "->" operator is brain-dead: why should the programmer keep track if something is a pointer or not when a type-safe compiler can figure out if "." or "->" is suitable. The "->" operator is not brain-dead, but needed because of the precedence of "." over the "*" dereferencing operator. Pointers Rule!

Re:I love pointers (Score:2, Insightful) by adubey (non_sequitur_boy@yahoo.com) on Friday February 25, @08:00PM EST (#264) (User Info)

Yes, it is brain-dead. I could write a "C--" language which only used the "." operator. Using type analysis in my context-senstive analysis, I could replace the "." with a "->" when necessary, and output code that a normal C compiler could generate. So why does C have a "->" operator anyways? Because it's brain-dead.

Re:Moderate this up, please! (Score:1) by osu-neko (osuneko(whirlpool)iname(spot)com) on Friday February 25, @06:35PM EST (#212) (User Info)

(NB: Windows _does_ have MFC to abstract OS functionality, if you want it. From what I hear, it doesn't abstract that functionality very well, though...). I have the dubious distinction of being an experienced coder for both MFC and for the bare Windows API sans MFC. Rather than saying MFC "doesn't abstract that functionality very well", it would be more accurate to say it "doesn't abstract that functionaily very much". MFC is a rather thin wrapper around the Windows API. Frankly, it doesn't really abstract away from it at all. It just adds some nice wrappers so you can use it using OO syntax. -- I'm not a monotheist; the world was obviously designed by a committee.

Re:Moderate this up, please! (Score:1) by Harri on Monday February 28, @04:33AM EST (#388) (User Info)

> But you sometimes have to mix pointers and references for the simple reason that you can't re-assign references. In code, this might be no problem, but what about classes? That's the one thing that I miss from Java - not being able to say class Jobby{ public:     MyObject& anObject; // a null reference     Jobby(MyObject obj); } Jobby::Jobby(MyObject obj){     anObject = obj; } Perhaps being a Javaist makes me overly wary of pointers. But I _like_ references!! And I don't like that nasty -> thing!

Re:Moderate this up, please! (Score:0) by Anonymous Coward on Wednesday March 08, @12:50AM EST (#405)

This works: class Jobby { public:         MyObject &anObject;         Jobby(MyObject &obj): anObject(obj) { } }; Note that null pointers exist but null references don't; unless you initialize anObject (before the body of any constructor!) using it is undefined behavior. Keeping a reference to an argument passed by value (instead of by reference, as I wrote) is a Bad Idea - that object goes away as soon as you return. That's just one of the many pitfalls of claiming to know the lifetime of every object you use, as well as paying for all the fine-grained bookkeeping.

Re:Complexity the cause of poor education? (Score:1) by deacent on Friday February 25, @01:43PM EST (#88) (User Info)

Bjarne mentions the poor education of C++ programmers frequently in this interview. I can't help but think, is this poor education a direct result of the complexity of the language? I think that there is a great deal of confusion caused by C++'s resemblance to C. There is a whole different way of thinking involved in using an object oriented paradigm versus a functional one. I've seen so many functionally thinking programmers learn C++ in an effort to broaden their horizons without really taking the time to understand the difference. This leads to situations such as not knowing how to use classes properly. There are some who seem to think that classes are just C++'s way of doing a struct, much less appreciate templates. They start to make assumptions about some of C++'s features by trying to equate them to C's features, such as using streams in place of printf. But then they fail to recognize the power of these features and try to use them just like they would in C. This creates all sorts of ugly code and usually leaves the programmer with a feeling that C++ is too complicated to be worth it. think that it's a much shorter learning curve to learn the C language fairly well than C++. I think this has helped in the Gnome project, although I'm sure there are people who feel differently. That said, many of the historical reasons for disliking C++ are becoming obsolete. In particular, the language seems to be settling down standards-wise, and there are now decent implementation to be had, both free and non. I've only used C++ sparingly in my own work so far, but I look forward to expanding my use of the language. It has always been a matter of vendor implementation. The language itself started out reasonably strong and has grown stronger. The big stumbling blocks were vague areas of the language that vendors chose define (and sometimes rely on) and how efficient the compilers and linkers have been. Of course, the more experience a vendor has at creating programming utilites, the more efficient they tend to be as long as you don't try to keep cramming more crap into them (hello MS). -Jennifer

Re:Complexity the cause of poor education? (Score:2) by fprintf (fprintf@iname.dot.com) on Friday February 25, @01:48PM EST (#93) (User Info) http://stuarthall.net

I think the difficulty in new users learning C++ is the inability to read Bjarne Stroustrup. Seriously, I have had his 3rd edition book for about 6 months now, and I have yet to be able to figure out the first couple of chapters. It has now become an issue of pride that every opportunity I get, I try and understand still yet another paragraph (good bathroom reading material). His writing style is definitely geared towards a technical, engineering personality. I realize most of these questions were not directed at newbies, most of those questions were answered in the FAQ, but just reading Bjarne's thoughtful responses gave me flashbacks to the bathroom this morning. :-)   If I could offer you only one tip for the future, sunscreen would be it.

Re:Complexity the cause of poor education? (Score:0) by Anonymous Coward on Friday February 25, @03:02PM EST (#123)

> I think the difficulty in new users > learning C++ is the inability to read > Bjarne Stroustrup. > Seriously, I have had his 3rd edition > book for about 6 months now, LOL, take a look at the 1st ed some time ... what a bloodbath.

Re:Complexity the cause of poor education? (Score:0) by Anonymous Coward on Friday February 25, @01:53PM EST (#96)

I think it is a result of the complexity of the language. I found the learning curve for doing powerful things to be quicker for the Smalltalk/Objective-C line of languages. Java too. C++ just has too many features interacting in subtle ways; it's easy to get trapped by details.

Re:Complexity the cause of poor education? (Score:0) by Anonymous Coward on Friday February 25, @03:32PM EST (#134)

Ok, here is an idea. IF YOU HAVEN'T READ A C++ PRIMER AND D&E AND C++PL: Shut the hell up and stop whining about a language you don't even know. IF YOU HAVE READ THEM: Stop whining and write some code. IF YOU ARE STILL WHINING: Write code that is more than 20 lines. The larger the project is, the more obvious C++'s usefulness becomes. IF YOU ARE STILL WHINING: Get a life. Get some maturity. Get some intelligence. And lastly, shut the hell up and stop bothering people who have all of the above. And let me remind you /.'ers about something: just because Linus didn't write Linux in C++, doesn't mean he wants you all to attack someone with far more intelligence than you all put together will ever have. (Stroustrup) Grow up.

Re:Complexity the cause of poor education? (Score:0) by Anonymous Coward on Friday February 25, @04:04PM EST (#148)

Sorry, Bjarne. We didn't mean to piss you off.

Thanks, finally someone said it! (Score:0) by Anonymous Coward on Friday February 25, @06:34PM EST (#211)

I agree with you, I don't get the bitching and moaning a bit. I learned C++ after already knowing three other languages, and my reaction was THIS IS THE COOLEST BY FAR. The power and flexibility of C++ is great, the problem is everyone wants that power without doing the work to learn it. If you can't handle the language, go dick around with Visual Basic and SHUT UP.

Re:Complexity the cause of poor education? (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @10:21PM EST (#291) (User Info) http://CubicMeterCrystal.com

DOWN!!! DOWN WITH THE COBOL CODERS AND VB SCRIPT KIDDIES!!! DIIEEEEEE!!! 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:AND C GTK SUCKS (Score:1) by Grimlord on Friday February 25, @03:34PM EST (#136) (User Info)

For the very reasons he stated GTK SUCKS. They tried to produce a class structure with a language that does not support classes. For this very reason GTK is both slow and non flexible. QT smokes GTK due to its great object design.

Re:AND C GTK SUCKS (Score:0) by Anonymous Coward on Friday February 25, @09:10PM EST (#277)

> For the very reasons he stated GTK SUCKS. They > tried to produce a class structure with a > language that does not support classes. For this > very reason GTK is both slow and non flexible. > QT smokes GTK due to its great object design. Firstly, I would like to say that I'd not consider myself a pro-GTK or pro-Qt zealot, and intend to comment objectively. GTK is not 'slow' as you put it, or at least I can't see any noticeable difference in performance than with QT, except that Qt apps tend to use more memory. This doesn't make Qt bad. Qt is an instance of *bad* C++ design. The run-time object system is very powerful, yet not good C++ design, impedes theoretical performance, and also adds the moc step. This is irritating. Of course, programming with Qt is much nicer, save this annoying aspect. Inheritance in an inheritance friendly language is always easier, and not having to deal with excess typecasts is great. GTK is an instance of *good* C design, following the logical object paradigm for visual controls, and doing it in the best manner C can offer. The foresight of making GDK is also respectable. For the most part, GTK-- offers what I would consider a better C++ design than Qt, but unfortunately often falls behind GTK. As far as their use goes, I'd say they're both a joy. Qt may be a bit easier, since it uses a subset of C++ for the actual toolkit, but that's a matter of individual taste.

Re:AND C GTK SUCKS (Score:0) by Anonymous Coward on Friday February 25, @09:34PM EST (#282)

learn how cfront worked, and then how modern C++ compilers work. Otherwise you just look like an idiot. You think because the compiler hides some of that code that it magically executes instantly?

Re:Complexity the cause of poor education? (Score:0) by Anonymous Coward on Friday February 25, @04:08PM EST (#151)

I know a few people who consider themselves C++ programmers because they can create a dialog box in VC++.

Re:Complexity the cause of poor education? (Score:1) by jorend on Friday February 25, @05:22PM EST (#181) (User Info)

I think that it's a much shorter learning curve to learn the C language fairly well than C++. I think this has helped in the Gnome project... I feel differently. (C: GNOME is C; KDE is C++. Both projects have done extremely well. I would hesitate to say that the difference between C and C++ has affected the two projects at all. This is because few people learn the language in order to contribute to the project. Most of the interesting contributions to either project have come from people who knew C or C++ beforehand.

Starting off with C++ the cause of poor education? (Score:1) by link2NULL (link2null@hotmail.com) on Friday February 25, @06:53PM EST (#225) (User Info) http://shrike.depaul.edu/~nmckinne/

I'm tempted to think some of the problem is schools that introduce programming with C++. University CS departments seem to be doing this quite often, I guess because students don't want to learn a language that's not going to earn them big bucks ASAP (and it's hard to blame them since they need to get internships or part-time jobs, and this is not easy if all you know is Pascal). I learned to program with BASIC (yes, a long time ago, 1981) and Fortran77, and I think this helped a lot when I began learning C++. Intro to Programming courses that utilize C++ seem to be so focused on the language (because, yes, it is complex) that programming techniques become a side issue at best. I really like the language, but it's hard for me to believe it's the correct one to start with.

Re:Starting off with C++ the cause of poor educati (Score:1) by norton_I (hobbes@utrek.dhs.org) on Friday February 25, @10:30PM EST (#295) (User Info)

I definately agree. I think people who learn procedural programming first make better OO programmers in the long run--they are much more likely to understand the benefits, limitation, and tradeoffs associated with using those OO features that people who start off in C++ overuse, or use poorly. Personally, the thing I dislike about C++ (and Java even more so) is that it turns too many warnings into errors. Computers exist for me to tell what to do, not the other way around, and if I write something that is syntactically correct and well defined, a compiler has no business telling me I can't do it. Yes, I even thing that accessing a private member of a class should only be a warning... If I have a legitimate cause to use a classes private variables, don't make me "#define private public"

Re:Complexity the cause of poor education? (Score:1) by timmyd on Friday February 25, @07:45PM EST (#254) (User Info)

It is complex but I have never seen it taught right in the first place. I taught myself C++ when I was twelve. I took APCS as a highschool freshman and the teacher didn't know how a for loop worked. I passed the AB APCS test thought because I already knew the language. Now I am taking it again because i missed the first two weeks and because i took it during my independant study. This time the teacher knows how to write a loop but she is pretty pitiful to. She has made very many errors while she was teaching and I have a very good feeling that she does not know crap about what she is talking about. She doesn't even know what to teach the fscking students for the APCS test. And I don't have a say in it so hopefully it won't be offered again because anyone that acutally knows the lanugage isn't going to be teaching!

templates? (Score:1, Interesting) by shitface (bondowine@yahoo.com) on Friday February 25, @12:28PM EST (#13) (User Info) http://www.geocities.com/bondowine

I am currently a first-year comp-sci student who is learning/learned c++. The book(s) that I have used have in my opinion sucked and did not explain templates at all. Can anyone suggest a good c++ book? I understand that Bjarne's book, whatever the name is, is not a pure programming book- but would his book help me understand templates? Bondowine, pure and legit now

Re:templates? (Score:0) by Anonymous Coward on Friday February 25, @01:00PM EST (#54)

I've been and am somewhat still in that same boat. when I took my first comp sci course. I was on a mission to dethrown stroustrup as the jedi master c++ programmer, (of course Im still in training). but my suggestion is spend a few hours at the barnes and noble or your local bookmark and browse around. the books I saw are usuallu expensive. but... "21 ways to improve your c++" or something similar to that. is excellent. as I was. I just looked it up. "Effective C++..." by Scott Myers. I have both editions. The key to being good is mastering the basics. then everything is easy.

Is it on the exam? (Score:1, Interesting) by Anonymous Coward on Friday February 25, @01:17PM EST (#69)

If not, don't even worry about it. Templates aren't going to be meaningful until you're reasonably comfortable with the rest of the language. For getting "reasonably comfortable" with the more commonly used features, I'd recommend C++: The Core Language from O'Reilly (the authors are Sapir and somebody else, IIRC). Templates are not covered in that book, but when you've mastered what is in that book, you should be able go to Stroustrup and deal with templates. C++ is very large and complicated and you can't learn the whole thing at once. Stroustrup's TC++PL is an absolutely rotten tutorial, because it was never meant to be a tutorial. It's a reference for experienced programmers. It's not "Son of K&R". Stroustrup isn't Kernighan, sorry. It's often damned hard to decipher what he's getting at, and his discussion of templates in TC++PL is totally unsuited for beginners. Here's the most simple and trivial template example I can think of: template<class T> class foo { public:     T data; }; foo<int> bar; bar.data = 8; foo<int> bar creates an instance of a class based on foo, with the type argument (int) substituted for each appearance of T in the template. Thus bar.data is of type int. The above example is, of course, not useful code. If you can't imagine any uses that are useful, learn C++ first (or contemplate what it would be like to write one linked list, and then use that one for the rest of your life on any data type you want). You'll eventually start to "get it".

Oh, yeah, one more thing: (Score:0) by Anonymous Coward on Friday February 25, @01:19PM EST (#75)

If it is on the exam, you're fucked. Sorry.

Stroustrup isn't Kernighan, sorry (Score:0) by Anonymous Coward on Friday February 25, @01:55PM EST (#99)

Amen! Thankfully, there are two writers who do c++ justice. Scott Myers, and Herb Sutter. Scott's books (now he has everything on one low-priced CD-ROM) are mandatory for any c++ programmer, beginner or expert. Herb's book is a compendium of the 'guru of the week' posts on comp.lang.c++.moderated.

Thanks, I'll check those out. (Score:0) by Anonymous Coward on Friday February 25, @02:17PM EST (#108)

.

Re:templates? (Score:0) by Anonymous Coward on Friday February 25, @01:28PM EST (#80)

Though it may not be the best book to learn a first programming language from, I would encourage anyone interested in C++ to struggle through Bjarne's The C++ Programming Language, 3rd Edition (the "wave book"). It does an excellent job of explaining why features are the way they are, presenting clear examples of subtle points and inculcating the proper mindset to have to program effectively. I read the 2nd edition (the "gray book") so frequently that the binding broke and all the pages separated -- I guess I loved it too much --, and the 3rd edition was heading that way until I started redirecting my non-work efforts into Linux, Python and internet stuff -- though with KDevelop I will be getting back into the C++. C++ can be a difficult language to use effectively (or rather, it is an easy language to use improperly), but it is an absolutely essential language -- as close to the metal as one can get without writing assembly (I recall Bjarne stating that one of his objectives was to obviate the need for any language between assembly and C++), but providing the abstraction tools necessary for the structuring of larger-scale projects. What I like about C++ is that it adds to C the bare minimum of higher-level features necessary to accomplish this goal. Higher-level languages like Java or Python are great (I have given up writing smaller (several hundred line) programs in C++ unless they are very speed sensitive, and now write them in Python), but in a way C++ is like the sports car that gives the driver total control while these other languages can at time feel plush-upholsteried, automatic steering, automatic transmission Cadillacs. Bottom line: long live C++, long live Bjarne!

Re:templates? (Score:1, Informative) by Anonymous Coward on Friday February 25, @01:52PM EST (#95)

The best C++ learning book I've found is the C++ Primer by Lippman and Lajoie. It covers all the features and has simplified explanations with more detailed sections for those who want them. The Effective C++ series by Meyers is damn near essential. It was the first book to really explain why some things were done the way they are.

Re:templates? (Score:1) by scc (scc@ScottCollins.net) on Friday February 25, @02:19PM EST (#109) (User Info) http://ScottCollins.net

Essential C++ by Stanley B. Lippman ...only 276 pages long. This book is an excellent place to start, and covers templates in chapter 6.

I think Bjarne is right about the state of C++ edu (Score:0) by Anonymous Coward on Friday February 25, @02:39PM EST (#113)

I'm a 3rd year computer engineering major and so far I've taken a lot of really crappy programming classes. No one even mentioned templates until the 3rd or 4th programming course I took, even though our programming assignments would have been much much easier with generic containers. Luckily I was curious enough to read ahead. Also, the textbook I had only mentioned multiple inheritance in passing, and didn't explain at all how it was implemented and how it might be used. To this day not a single class I have taken has even mentioned C++ exceptions, which (now that I know what they are) are a very powerful tool. I was really getting fed up with C++ and a lot of things that I wanted to try but couldn't figure out how to code because I didn't really know how to use the language (or what features the language really had). I read (well I'm about 2/3 of the way through) Bjarne's The C++ Programming Language, 3rd ed. and it's been consistently answering every question I've had about the language, like questions about templates and their capabilties, why certain language features are the way they are, and how all the language features were designed to be used together. I would very enthusiastically recommend TC++PL if you're already comfortable with programming and want to learn how to effectively use the advanced features of C++ (or learn what they are if your classes aren't explaining them), but like others on this board have said, it's not a programming tutorial, so if you're just starting to program it might be wise to hold off for a little while. -Mike

This is the book you need... (Score:0) by Anonymous Coward on Friday February 25, @03:19PM EST (#128)

"Teach Yourself C++", by Al Stevens is the most readable introduction to C++. The book is short, concise, and complete. I've read Meyers, Bjarne, and many others but this is the clearest book of all. Reading it in one afternoon as a brush-up helped in nailing an important job interview. You can buy it here with free shipping for $14.95.

Re:templates? (Score:1) by tombo on Friday February 25, @07:38PM EST (#251) (User Info)

At the Index at the top of the FAQ, click "What is the best book to learn C++ from?"; this item includes Have a look at the ACCU (The Association of C and C++ Users) site. This is one of the best sites for book recommendations by experienced programmers who are not afraid to speak their mind (booksellers tend to give rosy reviews, and reviews of the form "This book is perfect, I love it, I have read almost three chapters, and can't wait to read more" are worse than useless - why anyone would take advice on how to learn C++ from someone who completely lacks C++ experience beats me). The ACCU rates books for level of experience required and overall quality.

Re:templates? (Score:0) by Anonymous Coward on Friday February 25, @01:29PM EST (#81)

MUUUHHHAAAHHHHAA!!! That's +5 Funny!

What about Java? (Score:3, Interesting) by tdrury (tdruryNOSPAM@mindspring.com) on Friday February 25, @12:32PM EST (#16) (User Info)

I'm amazed that no question regarding his opinion on Java didn't make it through moderation. Does he feel Java is a competitor? or just another implementation to solve a different set of problems (e.g. web-programming)? Or maybe this is in the FAQ? -tim

Re:What about Java? (Score:2, Insightful) by DaveHowe (DaveHowe@Hawkswing) on Friday February 25, @12:44PM EST (#30) (User Info)

I'm amazed that no question regarding his opinion on Java didn't make it through moderation. I'm sure it scored highly - but when you are limited to ten, it's difficult to select such a small subset to give from such a wide pool of possible queries. One point I did find interesting was the statement that he "peeked" at the raw questions on /. - and wondered if it would be possible to have a more interactive layout for this - maybe even convice some of our potential questionees to take part in the initial trawling and guide some of the comments with short replies. Does he feel Java is a competitor? or just another implementation to solve a different set of problems (e.g. web-programming)? I am slowing learning this too <grin> but also see it as aimed at a different set of problems - one where compatibility and visual effect is more important than power and scope. I could be wrong of course :+) Or maybe this is in the FAQ? Not that I have ever seen. --         -=DaveHowe=-

Re:What about Java? (Score:1) by Maryck on Friday February 25, @12:53PM EST (#45) (User Info)

I think a discussion of Java would have also been somewhat redundant. He has made his views on Java fairly well known on several occasions, so asking him here would have been slightly pointless and would probably have been major flamebait too. Even so, you can pick up some of his attitudes towards java (or more generally, strict OO langs) simply based on the answers he presented here.

Re:What about Java? (Score:0) by shitface (bondowine@yahoo.com) on Friday February 25, @12:55PM EST (#46) (User Info) http://www.geocities.com/bondowine

His expresses quite a bit about his java views on his faq page. Look under the question thatgoes something like "If you hadn't designed c++ is Java the language you would of like to of made." He right away says no and explains that java is not really platform independent and a whole bunch of other goo. Bondowine, pure and legit now

bondowine -- pure and legit (Score:1) by delmoi (delmoi at hot mail dot com) on Friday February 25, @05:06PM EST (#177) (User Info)

Why don't you just register a new nic, that way you'd start out at +1 instaid of +0. [ c h a d   o k e r e ] "Subtle Mind control? why do html buttons say submit??

Re:bondowine -- pure and legit (Score:0) by shitface (bondowine@yahoo.com) on Monday February 28, @08:49AM EST (#391) (User Info) http://www.geocities.com/bondowine

I have thought about getting a new account since i saw the light and went legit, but I do not think it is right. I really made a mess of my karma and now I am paying for it- but people are taking me seriously and my karma is starting to come around. Bondowine, pure and legit now

Re:What about Java? (Score:1) by warmi on Friday February 25, @12:55PM EST (#47) (User Info)

This is in the FAQ. Go and check it out - it is quite interesting.

Java is covered in the FAQ (Score:2, Informative) by RPoet (haakon@nilsen.com) on Friday February 25, @12:57PM EST (#50) (User Info) http://haakon.nilsen.com

Or maybe this is in the FAQ? It is, right here. You should read it, it's worthwhile. In particular I like the quote "Java isn't platform independent; it is a platform." :)

Re:Java is covered in the FAQ (Score:1) by gid-foo (gid-foo@telecom-digest.zzn.com) on Friday February 25, @01:36PM EST (#86) (User Info)

Wow, he's even more of a man than I thought. That little section on Java in his FAQ rules. What a bad man. Damn, this whole /. interview thing kicks ass.

Re:Java is covered in the FAQ (Score:1) by tombo on Friday February 25, @06:16PM EST (#205) (User Info)

More from Stroustrup on Java:       Q: What is your take on the Java revolution?       A: What Java revolution? (read the complete interview by Chuck Allison from the C/C++ Journal,   1996, at http://www.research.att.com/~bs/cuj_interview.html)

Bah ! (Score:0) by Anonymous Coward on Friday February 25, @06:49PM EST (#223)

Not to advocate Java but: Every 'language designer' "promotes" her/his language. Do you really think e. g. Niklaus Wirth would say "Pascal stinks, C++ is better". And obviously the designer thinks his/her language is best! Frank

Re:Bah ! (Score:1) by toriver on Saturday February 26, @11:31AM EST (#348) (User Info)

Every 'language designer' "promotes" her/his language. One could almost say that the success of a language is measured in the number of proponents of other languages who find it necessary to write "MyLanguage vs. YourLanguage" articles. For Java, there is the already-mentioned digs from Stroustrup, plus what some vocal Perl advocate wrote a few years ago, and IIRC some of the religious Eiffelians tend to spout their mouths off every now and then about how much better their insignificant little plaything is.</flamebait> All this points to Java as a winner.:-)

His opinion on Java? He doesn't get it! (Score:1) by porky_pig_jr on Friday February 25, @06:16PM EST (#204) (User Info)

I remember seeing someone his comment on Java. He just don't get it! 'Don't understand what all fuzz is all about' or something like that ...

Correction on the Standard-Library link (last Q) (Score:3, Informative) by MarcoAtWork on Friday February 25, @12:34PM EST (#17) (User Info)

Here is the correct link: Appendix E: Standard-Library Exception Safety

Maybe /.ers have an opinion then? (Score:3, Interesting) by Davorama on Friday February 25, @12:37PM EST (#22) (User Info)

These other questions were so great I didn't make the cut but maybe you folks have opinions you'd like to share? What do you think of template meta programming? Do you consider it a boon, enabling clever programmers to do outrageously cool things like the Blitz project? Or is any benefit derived from it's use washed away by the obscure, nearly unreadable code it takes to implement it? Davo -- Utopia would be free speech, free software, AND free beer.

High Quality? (Score:2, Insightful) by Anonymous Coward on Friday February 25, @12:39PM EST (#25)

And the very first question of the lot:                     1) Has OO run out of steam?                     by rambone                     After 20-some years, it's obvious that object-oriented                     programming is not a panacea. What are your thoughts on the                     future of the OO paradigm? What other paradigms do you see                     challenging it? I can just imagine Bjarne's eyes rolling back, and then him taking a deep breath when he read this question. Thanks for wasting Bjarne's time with dribble.

Re:High Quality? (Score:0) by Anonymous Coward on Friday February 25, @12:40PM EST (#27)

yep TRoLL

Re:High Quality? (Score:2) by DaveHowe (DaveHowe@Hawkswing) on Friday February 25, @12:52PM EST (#43) (User Info)

I can just imagine Bjarne's eyes rolling back, and then him taking a deep breath when he read this question. I can see how the style it was written in (confrontational and almost a direct attack) could be a little daunting, but there *is* a important question in there, and I think he made a game attempt to answer it - what it comes down to is "How tied is C++ to the OO methodologies, can it evolve to whatever is or could replace it in the near future, and if it can, in what directions would you expect it to evolve?" --         -=DaveHowe=-

if C++ isn't really OOPL, then why C++ at all? (Score:1) by porky_pig_jr on Friday February 25, @12:39PM EST (#26) (User Info)

As far as OOP is concerned, that is a number of language far better than C++, by 'better' I mean more compact, consistent, and less confusing. Why bother with C++ then? I"ve been hearing 'because it inforces the programming's discipline whereas C doesn't. Give me a break. A lack of programming discipline is something you can't just inforce with a particular language, right to the contrary, a language such as C++ or Perl, both feature rich and both confusing as hell don't do anything toward better programming discipline. In short, C++ is abomination. A crime against nature.

Name one that isn't! (Score:2) by zorgon (norm at bee bee ess arr dot ee dee yew) on Friday February 25, @01:02PM EST (#56) (User Info)

Well, come on, PPJ, you have to tell us now. What are the languages that you refer to that are not abominations and crimes against nature? Restrict your answer to languages that are actually useful, and meet your criteria of OOPed, more compact, more consistent and less confusing, while encouraging better programming discipline. Otherwise your comment is just hot grits. I ask this question in genuine curiosity and without sarcasm. "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off." -Stroustrup

Re:Name one that isn't! (Score:0) by Anonymous Coward on Saturday February 26, @08:02AM EST (#344)

Original Oberon if someone would ask me...... even Oberon-2 In fact funny that he does not talk about Wirth family languages at all when he talks about languages getting bigger all the time as a natural law Wirth's languages are getting smaller all the time (algol -> pascal -> modula/2 -> Oberon)

Re:Name one that isn't! (Score:2) by zorgon (norm at bee bee ess arr dot ee dee yew) on Sunday February 27, @09:28AM EST (#377) (User Info)

Thanks! I will look up info on Oberon. Interesting point about Wirth languages getting smaller. That's also an interesting sequence you drew there. I didn't even know there was a followup to m/2 from Wirth. Is it actually a followup or a new thread? Wirth might argue pascal doesn't belong in the same room as m/2 -- what did he say, something like "it's an instructional language, stupid!" cheers z "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off." -Stroustrup

Re:if C++ isn't really OOPL, then why C++ at all? (Score:1) by Steve Burnap (sburnaplinux@attSPAMSUX.net) on Friday February 25, @01:03PM EST (#58) (User Info)

Why? Because I can use C++ to write a purely OO language, a purely structured language, or anything in between. The language doesn't constrain me to use a certain paradigm.

Re:if C++ isn't really OOPL, then why C++ at all? (Score:1) by bakreule (apocalypse29_99@yahoo.spam.com) on Friday February 25, @01:06PM EST (#63) (User Info) http://slipstream.dynip.com/apocalypse/

Um, why do you think it's an abomination?? Don't just shot something down without giving a reason. What projects have you participated in using C++ that have failed so much or left such a sour taste? I'm assuming that you have used C++ for something and haven't just read the book and then burned it.

Re:if C++ isn't really OOPL, then why C++ at all? (Score:0) by Anonymous Coward on Friday February 25, @03:32PM EST (#135)

Absolutely! C++ is indeed a poor OOPL. Its backwards compatibility with C (and the CPP) make it needlessly complex. One has to be extremely careful with C++ if one intends to engineer reliable OO software systems efficiently. A better OOPL would foster good techniques without being overly restrictive. Check out Ian Joyner's paper "C++??: A Critique of C++" and the book it spawned "Objects Unencapsulated: Java, Eiffel, and C++??" for a thought-provoking and thorough analysis of the language. You won't regret it!

Poor coding (Score:2) by 348 (beeoch22@hotmail.com) on Friday February 25, @12:41PM EST (#28) (User Info)

Naturally, you can write poor programs in any language. C++ is a powerful tool and in the wrong hands it can generate code that is *obviously* contorted and bloated. That may be preferable to the traditional spaghetti that poor programmers produce in C. Note that someone who is a good C programmer isn't automatically a good C++ programmer. Many problems have been caused by good C programmers assuming that they could adopt a semi-random collection of C++ language features and then magically become a good C++ programmer in a week. Elegantly said. C++ is a little tougher and takes a little effort to learn. The key word being effort. As a PHB I've found that developers who write marginal code in C did write poor code in C++, however I think this comes down to both a person who uses tools and resources targeted to meet a specific purpose and people who stay whith what is comfortable to them reguardless of the fact they may be using the wrong tool for the job. The interview questions were very good, Glad to see the good ones get bubbled up to the top. Also thanks to Bjarne Stroustrup for taking the time to answer them fully and completely, it's obvious that he spent some time with this. Logic is a systematic method of coming to the wrong conclusion with confidence.

Re:Poor coding (Score:2) by DaveHowe (DaveHowe@Hawkswing) on Friday February 25, @12:49PM EST (#37) (User Info)

Elegantly said. C++ is a little tougher and takes a little effort to learn. The key word being effort. As a PHB I've found that developers who write marginal code in C did write poor code in C++, however I think this comes down to both a person who uses tools and resources targeted to meet a specific purpose and people who stay whith what is comfortable to them reguardless of the fact they may be using the wrong tool for the job. Guilty as charged <grin>. I have largely ended up writing C code thinly disguised as C++ for years - not really due to comfort or singlemindedness though, but due to the fact I can write decent C, and if I had to suffer through my C++ puppyhood in a production environment, my job would be on the line. It took me four or five years to learn to write decent procedural-language paycode - and how many employers are willing to have an employee currently producing usable code effectively not there for that length of time? --         -=DaveHowe=-

Re:Poor coding (Score:4, Insightful) by 348 (beeoch22@hotmail.com) on Friday February 25, @01:05PM EST (#60) (User Info)

Honestly, not many. What we learned (the hard way) was that C developers that were good, were also good in adapting/learning/etc. C++. On the other hand, we did get out of the training business by trying to port C developers to C++. The expectations I had were quite misguided. I understood C++ to be just the next version of C, for the longest time I just never got it that C++ was different. When we did, we looked for C++ developers and stopped the pain, and increased the quality of our code overall. Logic is a systematic method of coming to the wrong conclusion with confidence.

Re:Poor coding (Score:2) by DaveHowe (DaveHowe@Hawkswing) on Saturday February 26, @06:53PM EST (#369) (User Info)

When we did, we looked for C++ developers and stopped the pain, and increased the quality of our code overall. Hmm. I hope this doesn't become a problem for those of us still using C rather than C++ - we may find ourselves pushed out of our current jobs as the job spec changes to requrire C++ skills our employers aren't willing to support our retraining on.... --         -=DaveHowe=-

Re:Poor coding (Score:1) by 348 (beeoch22@hotmail.com) on Monday February 28, @07:48AM EST (#390) (User Info)

Honestly, if you were working for our company it would. The PHB's way up above have made a concious shift to use C++ rather than C. The reasoning? I really have no idea, maybe they think it's better, etc.,Maybe they want to standardise the development efforts to a suite of tools to gain synergies across development shops. Too bad really, because C isn't the only one, their standardising, HTML tools, Graphics tools, business apps etc. It tends to really cripple the advantages of having folks develop with the tools they are comfortable with. Ernie Logic is a systematic method of coming to the wrong conclusion with confidence.

Systems level programming (Score:4, Interesting) by grappler (thegrappler@DIE_SPAMMERS.usa.net) on Friday February 25, @12:44PM EST (#31) (User Info)

I believe the entire BeOS operating is written in C++, with an object oriented framework and a microkernel on which several "servers" handle system tasks. It is by no means slow or bloated. Of course, for R5 they are scrapping the Net server in favor of one more closely tied to the kernel to improve performance, and I think they're doing something similiar with 3d acceleration. Anyway, the point is, they use C++ for system level stuff and it works great. Of course, the Be people are by no means "old dogs". There is nothing legacy about BeOS. -- grappler #include <std_disclaimer.h>

Re:Systems level programming (Score:2, Informative) by Otter (jsinger@leeta.net) on Friday February 25, @01:04PM EST (#59) (User Info) http://members.tripod.com/jbsinger/index.html/

I believe the entire BeOS operating is written in C++, with an object oriented framework and a microkernel on which several "servers" handle system tasks. On the contrary, despite Be's C++ orientation, the kernel is written in C. Someone posted some relevant links when this issue came up while questions were being asked.

Re:Systems level programming (Score:0) by Anonymous Coward on Saturday February 26, @01:53AM EST (#318)

The kernel of BeOS as stated in one of the newsletter was written in C. It uses structures to mimic C++.

Actually, the BeOS kernel and drivers are in C (Score:1, Informative) by Anonymous Coward on Friday February 25, @01:18PM EST (#71)

I do BeOS programming as a hobby and think it is fabulous, but the system-level stuff isn't in C++. According to Be, it is about 95% straight C and 5% assembly. The programming interface, however, is a really well-designed set of C++ classes along with some C functions. It is really quite straightforward (and fun) to write GUI-based apps using these objects (usually your own inherited versions). For anyone interested in learning C++, I would highly recommend trying BeOS (especially since they are about to start giving it away for free). There was a Be newsletter article around the holidays entitled something like "Using C++ in the kernel" that explains why, in general, you can't write BeOS drivers in C++. It was way over my head, but it had something to do with the order in which libraries are loaded in the two languages.

Re:Systems level programming (Score:5, Interesting) by brad.hill (hillbrad@NO_SPAM.pilot.msu.edu) on Friday February 25, @01:26PM EST (#78) (User Info)

Of course, the Be people are by no means "old dogs". There is nothing legacy about BeOS. On the other hand, IBM (the oldest dog in the book, but with more new tricks than anybody) entirely rewrote AS/400 in C++. They claim it was the largest OO project ever undertaken and was a spectacular success. Also, it seems that having an OO architecure at the core of the OS allosed them recently to integrate a JVM into the AS/400 kernel that's amazingly fast and scalable. I actually find it strange that C++ is thought of as unsuitable for systems programming. To me it seems exactly suited for that, while Eiffel or Java are much more suited to business programming. Perhaps the argument is more fundamentally that OOP is unsuitable for systems level development, which the above example blows to bits, of course.

Re:Systems level programming (Score:1) by TheQuestion (ltubbs@PLEASEDONTSPAMME.silverleafresorts.com) on Friday February 25, @02:58PM EST (#121) (User Info) http://home.sprintmail.com/~ltubbs/

In Frank G. Soltis' book Inside the AS/400, he mentions that the low level hardware interface for the AS/400 was designed and implemented in C++. The OO nature of the OS made C++ the best choice for abstracting the hardware. The AS/400 is many things, but slow isn't one of them. This tells me that high performance, system level programming is indeed possible with C++. I suppose it is easier when you are designing the hardware and software, and you can build a closed system. But still, I agree with Bjarne. C++ can be used at the system level even in an open system, as long as programmers are mindful of what they are doing. ?

Re:Systems level programming (Score:1) by Oblio (jjlupa at CreativeSolutions dot com) on Saturday February 26, @02:02AM EST (#319) (User Info) http://www.jamdata.net/~jjlupa

Guh. I actually worked on that many years ago (not the lower level but the programming API - MessageHandler to be specific). In any event, I don't know which "hardware interface" he is talking about but I'm pretty sure the lowest level was a glom of C and ASM. There were a couple hardware emulation and abstraction layers that sat real close to the iron that were written in C++ though. What was _great_ was the developement environment- They had an IDE called LanDE which ran on the RS6000s and AIX. I loved it. Of course, this had to be 8 years ago, and I can't remember what I ate for dinner last week, so its worth what you paid for it. :) Pax -- JJL

Re:Systems level programming (Score:1) by gram (gramster@bigfoot.com) on Saturday February 26, @05:02AM EST (#334) (User Info) http://www.cequrux.com

My company develops FreeBSD-based Internet firewalls and VPN gateway products. All of our coding is done in C++. We get far more code reuse, consistency and robustness as a result. For example, part of our class hierarchy is Process->Server->Proxy->Relayer. With this C++ library for writing servers and proxies, adding new servers or proxies that have consistent authentication methods, log message formats, etc etc, is usually always a trivial exercise (for example, it took only a few hours to implement a POP3 server, most of which was writing the new classes to handle maildrops). I *love* using C++ for systems programming! Graham Wheeler Cequrux Technologies Internet Firewalls/VPN Routers/Encryption Software

Re:Systems level programming (Score:0) by Anonymous Coward on Sunday February 27, @01:27PM EST (#378)

The BeOS Kernel is written in C. Everything else is C++.

Of C++ and Purple Dinosaurs? (Score:2, Funny) by powerlord (SPowerlordAM@worldnet.att.net) on Friday February 25, @12:44PM EST (#32) (User Info)

First off the interview was great. I'll be the first one to admit that parts of it went over my head (too many I fear... time to brush off the dusty old text books and review) but I also had another problem, I couldn't stop chuckling. Did anyone else keep picturing a large purple dinosaur as the 'mastermind' behind this new language designed, not to 'help everyone love each other' but to 'take over the world'. Yes... its Barney's evil twin (doesn't everyone have one?) Bjarne. "Ooops" --Shannon Foraker ("Ashes of Victory:Honor Harrington Volume 10" by David Weber)

Re:Of C++ and Purple Dinosaurs? (Score:1) by locust (locust@ieee.org) on Friday February 25, @04:05PM EST (#149) (User Info)

Yes... its Barney's evil twin (doesn't everyone have one?) Bjarne. Me thinks someone has been playing too much illuminati. --locust

Re:Of C++ and Purple Dinosaurs? (Score:1) by osu-neko (osuneko(whirlpool)iname(spot)com) on Friday February 25, @06:55PM EST (#228) (User Info)

Me thinks someone has been playing too much illuminati. They say it's only a game... ...they lie! -- I'm not a monotheist; the world was obviously designed by a committee.

As long as we're talking C++... (Score:0) by Anonymous Coward on Friday February 25, @12:52PM EST (#42)

Trying to use gdb with the STL drives me nuts! I get stuff like: (gdb) print Rollover $1 = {start = {cur = 0x8061544, first = 0x8061510, last = 0x8061710, node = 0x80604a4}, finish = {cur = 0x8061554, first = 0x8061510, last = 0x8061710, node = 0x80604a4}, map = 0x8060498, map_size = 8} (gdb) print Rollover.start $2 = {cur = 0x8061544, first = 0x8061510, last = 0x8061710, node = 0x80604a4} (gdb) print *Rollover.start.first $5 = 0 Is there a better way to get to the debugging info I want without wading through the STL intestines? MS VC++ seems to handle that much more cleanly... (as much as I hate to say it)

Re:As long as we're talking C++... (Score:2, Insightful) by benwb (benwb@hotmail.com) on Friday February 25, @01:15PM EST (#67) (User Info)

Not meaing to go completely off topic, but I will anyway. This is one of the reasons that I think that there will always be a place for commercial software. There's lots of stuff that is just boring, complicated, and generally a pain to program- ie stuff that no one is going to do for fun, like getting gdb to wade through the STL symbols output by gcc and display them intelligently. Dollar signs have a way of overcoming these little shortcomings.

GDB sucks.. (Score:0) by Anonymous Coward on Friday February 25, @01:19PM EST (#74)

compared to every other debugger out there. Yes, I know it's portable and free. But I'd rather use almost *any* other debugger for actually debugging.

Re:GDB sucks..NOT! (Score:1) by Monolith (jkillen at bigfoot dot com) on Friday February 25, @02:31PM EST (#111) (User Info) http://www.bigfoot.com/~jkillen

GDB is the greatest. What should I use instead... dbx...xdb...or some graphical thing. What debugger do you know that accepts things like c 100 to skip this breakpoint the next 99 times. Great when doing things like looking for a certain record in a file. May your soul reach heaven before the devil realizes you are dead

RTFP. Goddamn Slashbot . . . (Score:0) by Anonymous Coward on Friday February 25, @04:20PM EST (#157)

Read his fucking post, he had a specific and valid criticism or a problem which makes gdb a massive pain in the ass to use with C++. Address the issue or fuck off. This is a discussion about C++, remember?

Re:GDB sucks..NOT! (Score:0) by Anonymous Coward on Friday February 25, @04:30PM EST (#162)

What debugger do you know that accepts things like c 100 to skip this breakpoint the next 99 times. Great when doing things like looking for a certain record in a file. Well, the only debugger that I know anything about does - VC++.

Re:GDB sucks..NOT! (Score:1) by PD (pdrap@startrekmail.com) on Friday February 25, @04:36PM EST (#168) (User Info) http://freetrek.linuxgames.com

You can try ddd. It's a really nice shell on top of gdb.

Re:GDB sucks..NOT! (Score:1) by Micah (yeah@right) on Friday February 25, @05:38PM EST (#187) (User Info)

DDD is nice, but it (and probably ever other gdb based debugger) has the same problems with the STL as GDB. I would really like to see an answer to this question. IS there a way to skip over STL crap in GDB, or for that matter, ANY Linux-based debugger?

Re:GDB sucks..NOT! (Score:1) by lubricated (mpalczew@spam.u.washington.edu) on Friday February 25, @08:09PM EST (#269) (User Info)

Have you tried kdbg

Re:GDB sucks..NOT! (Score:1) by Micah (yeah@right) on Saturday February 26, @03:08PM EST (#359) (User Info)

no, but I thought that was just another GDB add on. I think *anything* based on GDB would have the same problem. Might be worth looking at though...

Re:GDB sucks..NOT! (Score:1) by partingshot on Friday February 25, @08:35PM EST (#272) (User Info)

pretty much every debugger I've seen will do that. VC++ will even let you specify the condition on which to break within the debugger. Have you ever done any work where a graphical display of the data would have been of any help? DDD is good at that sort of thing, the Insight debugger is also good.

Bjarne (Score:1) by bakreule (apocalypse29_99@yahoo.spam.com) on Friday February 25, @12:53PM EST (#44) (User Info) http://slipstream.dynip.com/apocalypse/

Some really, really interesting stuff. I'm going to forward this to everyone at work here. My only negative question is did he have to plug his books so much?? It seems like he never passed up a chance to "refer to my 3rd edition of C++PL", etc..... I tend not to trust people who plug themselves and their products too much. This, of course, is a minor concern. Thanks to /. for getting this great interview!

Re:Bjarne (Score:1) by Steve Burnap (sburnaplinux@attSPAMSUX.net) on Friday February 25, @01:06PM EST (#62) (User Info)

I suspect that part of the reason is that a lot of the questions and criticisms, especially those that didn't make it into the interview, are answered at length in The Design and Evolution of C++ It can be annoying answering the same question over and over.

Re:Bjarne (Score:1) by abelsson (henrik at tpu dot org) on Friday February 25, @01:44PM EST (#90) (User Info) http://kit.tpu.org

i doubt he did it to make another buck or two, it sounded a lot more like he was trying to point out where you could find more info where the complete explanation was too long to write in this interview.

Re:Bjarne (Score:0) by Anonymous Coward on Friday February 25, @06:45PM EST (#218)

all you people with funny names tend to stick together.

Re:Bjarne (Score:2, Insightful) by OaITw on Friday February 25, @02:09PM EST (#105) (User Info)

I do not presume to know Bjarne's motivation but I do disagree with your judgement of people plugging their work. Have you noticed that people do the talk show circuit only when the have a project to sell. Do you distrust them for this. Talk show, book signings, taveling to a conference to give a talk, all the same thing. I found the way he pluged his papers and books very comforting. He's just a guy (bright and talented) that is working for a living and has produced some stuff that he is proud of and is rewarded for financialy. That makes him seem more real to me.

Re:Bjarne (Score:1) by osu-neko (osuneko(whirlpool)iname(spot)com) on Friday February 25, @07:04PM EST (#234) (User Info)

I tend not to trust people who plug themselves and their products too much. Funny, I always trust people more when their motivations are obvious, when they make no effort to hide them. Ted Kopple(sp?) made a similar point recently when asked about Sam Donaldson, who tends to be very open with what his own opinions are on some shows (e.g. This Week). The questioner seemed to think this made it harder to trust Sam's reporting on issues when you knew what his bias was. Ted pointed out that, like everyone else, Ted has his own biases. Are you better off trusting a new report by Ted, who keeps his biases hidden from view? Seems to me its easier to evaluate the story presented by Sam, since you know what his bias is and can take it into account, than it is to evaluate the story by Ted. By not airing his own views, Ted presents the illusion of being unbiased, but in answer to this questioner, his openly pointed out that this is a complete illusion, he does have his biases, same as any other reporter. In short, it's a lot easier to trust someone when their motivations are plain, open, and blatant. Only a fool trusts people more when they know their motivations less... -- I'm not a monotheist; the world was obviously designed by a committee.

Re:Bjarne (Score:1) by Art Tatum (jhclouse at hotmail dot com) on Friday February 25, @10:35PM EST (#298) (User Info) http://www.gnustep.org

Seems to me its easier to evaluate the story presented by Sam, since you know what his bias is and can take it into account, than it is to evaluate the story by Ted. While I understand your point--and in application to Bjarne Stroustrup, this makes perfect sense and is correct--the mark of good journalists is that you can't tell what their own views are by simply watching their presentation of events. I know this is off-topic, and I apologize profusely... Help! Help! I'm being repressed!

question.. (Score:0) by Anonymous Coward on Friday February 25, @12:57PM EST (#49)

does alan cocks/linis trovalds use this in the kernel or is it mainly C?

It's definitely a question of background (Score:2) by JohnZed on Friday February 25, @01:01PM EST (#55) (User Info)

I have to agree with what some of the other folks have been saying here. I first learned C++ (well, a shoddy mix of C and C++), and, especially as I've learned more about its features, I've found it painful to go back to purely-procedural languages. I've had to do tons of C in school, and it always leaves me wanting for the power of C++, Java, or even the convoluted object-extensions of Perl5.     Of course, now we have Brian Kernighan here as a guest lecturer and he's trying to convert everybody to use awk instead. . . (great guy, though) --JRZ

char *'s, structs, and other C madness... (Score:1) by jolly_cola on Friday February 25, @01:10PM EST (#64) (User Info)

I don't think people use char *'s and structs and write their own vectors because they are too lazy to use the STL. It seems like so many compilers don't even come with it!! We use Sun's C++ compiler and it comes bundled with RogueWave instead, and frankly RogueWave sucks, especially if you are trying to write code that ports to win32. Frustration with mediocre libs is what drives me to use my own low-level C constructs. * Bjarne writes: * * The compatibility with C at the system interface level * has encouraged people to use C-style strings, arrays, * and structs, where they would have been better off * with some higher-level abstractions presented as * classes or templates. Instead of leaving the low-level * facilities at the system level and within the * implementations of classes, people have let the * low-level constructs - and pointers to them - * permeate their designs. Type errors, wild pointers, * array bounds errors, and memory leaks are the obvious * results. Lots of macros and casts often adds to the * obscurity of the code. It saddens me to see some of * the unnecessary messes people get themselves into.

Why I use char *'s: No choice. (Score:3, Interesting) by Venomous Louse (thevoom@howce.com) on Friday February 25, @02:32PM EST (#112) (User Info)

In an ideal world, all the code one uses would use the same string class, and all the old C libraries one links with would be rewritten in C++ and available in source form so you could compile it yourself and not have to worry about name-mangling and whatnot. On earth, we're stuck with legacy code that uses its own string classes, MFC (pray for us poor sinners) which uses their own (broken) string class, and OS API's (and other C libraries) which use char * and various typedefs thereof. We should probably all be using std::string, but I've found it sort of perplexing the few times I've bothered with it. In any case, it came along so late in the game that other string classes had already proliferated and are now immortalized by bassackwards compatibility. However, all of these string classes have some way to get at their char *'s, and they'll all construct from char *. So char * is a sort of lingua franca or least common denominator that lets us work with all this inconsistent crap and still get code written. It's a bummer, but it's better than nothing. I think the first thing Stroustrup should've done by way of C++ libraries was write a good solid string class while CFront 0.1 was still wet from the womb, and proselytize it endlessly. Of course, if he had, ten years later we would've ended up with a standard string class inconsistent with the rest of the STL. Oh, well. You can't have everything. "Christianity neither is, nor ever was a part of the common law." -- Thomas Jefferson

Four string classes in a project. (Score:1) by nonya on Friday February 25, @03:06PM EST (#125) (User Info)

About a year ago I worked on a project with 4 string types: Aphelion (an image processing library) used AphString in their C++ code. Aphelion, the same damn library, used char* in many parts of their library that was based on KBVision, an old product of theirs. Notice it was a char* - not a const - so the other string classes were not automatically converted. C++ standard string class. mfc's CString. Anybody got that beat? So much for the Pragmatic Programmer's "Don't Repeat Yourself" principle.

Re:Four string classes in a project. (Score:1) by jesser on Friday February 25, @08:08PM EST (#268) (User Info) http://www.palosverdes.com/jesse/

C++ standard string class What's this "standard string class" I keep hearing about? I have three compilers (borland 3.0, djgpp, borland 5.0), and only one (borland 5.0) knows what "string" is. It refers to it as "A specialization of the basic_string class". -- slashdot: I miss my free time, Rob.

Re:Four string classes in a project. (Score:2) by auntfloyd (rcl211@is9*fluffybunny*.nyu.edu) on Saturday February 26, @12:33AM EST (#309) (User Info) http://www.csoft.net/~rcl/

Yes, and your Borland compilers are out of date (3.0? That was in 1992!). I don't know what gcc version DJGPP uses, but I wouldn't be surprised if it didn't have all the latest C++ features just yet. And you might want to get Borland 5.5 sometime. Why not? It's free, as in Surge (Surge being preferable to beer) ~~~~~~~~~ auntfloyd See the auntfloyd thread

Re:Four string classes in a project. (Score:1) by partingshot on Friday February 25, @08:31PM EST (#271) (User Info)

CString cString std::string CVString StringExt the ubiquitous char* doesn't count

Re:Four string classes in a project. (Score:1) by toriver on Saturday February 26, @12:45PM EST (#354) (User Info)

Add RougeWave's Tools.h++ to your project and you can play with RWString as well... :-)

how well do various compilers track the standard? (Score:4, Interesting) by sethg (sethg@ropine.com) on Friday February 25, @01:12PM EST (#65) (User Info)

A common theme in the answers seems to be "that complaint is based on outdated information; get a new compiler that follows the standard and use the STL." For the benefit of us C++ newbies, does anyone maintain a chart showing which currently-available "C++" compilers violate which sections of the C++ standard? -- "But, Mulder, the new millennium doesn't begin until January 2001." "Nobody likes a math geek, Scully."

Re:how well do various compilers track the standar (Score:1) by llewelly on Friday February 25, @03:36PM EST (#137) (User Info)

gcc.gnu.org sourceware.cygnus.com/libstdc++ One of the best compilers. If you have $$$, SGI's MIPSpro (7.3.5 or later) is good, as is KAI C++. But gcc gives the most bang for the buck ... :-)

Re:how well do various compilers track the standar (Score:2, Informative) by bcombee (combee@techwood.org) on Friday February 25, @05:51PM EST (#193) (User Info) http://combee.techwood.org/

One comparison chart is at http://animal.ihug.co.nz/c++/compilers. html. Its a little out of date (CodeWarrior Professional is currently at 5.3, with 6.0 expected out later this Spring), but good detail.

Why unix developers still prefer c (Score:1, Interesting) by Anonymous Coward on Friday February 25, @01:18PM EST (#72)

they do because they don't do a lot of gui work. systems programming can be done in c, and there is not reason to learn all the complicated stuff in c++ just for the sake of using c++. When you start working with gui elements and abstract interfaces you will quickly realize how tedious and unusable c is for that sort of work

Re:Why unix developers still prefer c (Score:1) by Steve Burnap (sburnaplinux@attSPAMSUX.net) on Friday February 25, @02:56PM EST (#119) (User Info)

One thing that people seem not to really understand is that you don't have to use "all that complicated stuff" to get benefit out of C++. After all, here is "hello world" in C: #include <stdio.h> int main(void) {         printf("Hello, World!\n"); } Here is the same program written in C++: #include <stdio.h> int main(void) {         printf("Hello, World!\n"); } The key to understanding being that if your job is just to say "Hello, World", there is no point in using multiple inheritance. Once you've done this, then you can pick and choose elements of c++ that are advantagous to you. To take a simple example, this C++ program: #include <iostream> int main(void) {           char* Name="Steve";               cout << "Hi, " << Name << "!\n"; } is much less error prone then this C program: int main(void) {           char* Name="Steve";           cout << "Hi, %d!\n", Name); // Crash, boom } Thus, you gain benefit without dealing with "all that complex stuff".

Why no one likes a nitpicker :-) (Score:1) by Dictator For Life on Friday February 25, @04:47PM EST (#172) (User Info) file:/bin/false

Here is the same program written in C++: #include <stdio.h> int main(void) { printf("Hello, World!\n"); } Don't you really mean something like this? #include <cstdio> int main() {         printf("Hello World!\n");         return 0; } DFL Never send a human to do a machine's job.

Re:Why no one likes a nitpicker :-) (Score:1) by Steve Burnap (sburnaplinux@attSPAMSUX.net) on Friday February 25, @04:58PM EST (#174) (User Info)

No, I don't! I specifically mean what I wrote! The point being that you don't have to do anythingnew if you don't want to. C++ is about added features. The standard namespace is another added feature. You can use it or not. Besides, I'll nitpick your nitpick. To get that to compile, it should be: #include <cstdio> int main() {                 std::printf("Hello World!\n");                 return 0; } Though I know at least Visual C++ gets this wrong... (But you're right, I did forget the return.)

Re:Why no one likes a nitpicker :-) (Score:0) by Anonymous Coward on Friday February 25, @07:04PM EST (#233)

maybe you didn't forget return 0; after all: in C++ (but not in C), main() implicitly performs return 0; if you don't have a return statement. Yet another loophole of C that C++ has fixed...

Better yet... (Score:0) by Anonymous Coward on Friday February 25, @07:29PM EST (#247)

why return an int... just do void main() { ... }

Re:Better yet... (Score:1) by partingshot on Friday February 25, @08:30PM EST (#270) (User Info)

soon the standard will require you to return an int. Plus its nice to tell the user of the program the exit code (ever write a shell script?)

Re:Better yet... (Score:1) by timster (timster@earthling.net) on Saturday February 26, @05:00AM EST (#333) (User Info)

That's not standard C++ anymore, GCC will give a warning now.

Doh! Nitpicker Caught in Own Web (Score:1) by Dictator For Life on Friday February 25, @10:24PM EST (#293) (User Info) file:/bin/false

Duh, I forgot about the namespace. :-( In my defense, though, g++ doesn't handle them right yet either. So std::printf("Blah\n"); and printf("Blah\n"); are effectively equivalent. Actually, I also mistook your point. I thought your point was that the equivalent C++ program was exactly the same length as the C version. Sigh. Some days it doesn't pay to nitpick... DFL Never send a human to do a machine's job.

Better do this on at least one UNIX compiler... (Score:2) by Greyfox (nride@uswest.net) on Friday February 25, @06:15PM EST (#202) (User Info)

One of the UNIX C compilers in my lab (I forget which UNIX) apparently doesn't guarantee a return of 0 unless you actually return 0. This dinged me for a few minutes when I was checking the return code from a program. Someone had to put all that chaos there!

hahaha that's funny (Score:1, Flamebait) by RuntimeError (slashdotter@dr.com) on Friday February 25, @03:28PM EST (#131) (User Info)

C program using cout You don't know what the hell you are talking about, do you ?

better than C is not good enough (Score:5, Interesting) by hanwen (hanwen@cs.uu.nl.nospam) on Friday February 25, @01:25PM EST (#77) (User Info) http://www.cs.uu.nl/~hanwen

Thanks for answering my question. Now that I am reading your replies (and of course after reading your FAQ as well), I've started to notice that your replies center on the fact that             C++ is better than C Or maybe even the less subjective         Complicated programs in look better in C++ than in C This is patently true, of course. C++ has support for various nifty features that make a large C project more easy to manage. In fact it describes precisely what I felt when I traded C++ for C: no more hassling with function pointer tables was needed. I could simply use a virtual function, great! My problem is "better than C" is no longer good enough for me. I've grown a lot in my programming skills, and my projects have grown with me. A little detour: my pet project is GNU LilyPond, a music typesetter (free software of course) written and maintained largely by myself: it consists of about 55000 lines of C++. The problem with this application is that         1. music typesetting is _very_ complicated         2. every formatting detail should be tweakable. Since I've started it almost 4 years ago, I've learned a lot, and also came in touch with languages like Python, Haskell and LISP. Half a year ago we made the step of converting large portions of the C++ side to GUILE (the embedded Scheme interpreter of the GNU project). This step has dramatically simplified most of the code in LilyPond: now we have garbage collection, generic types without the overhead templates!, a clean way for users to plug into this system using Scheme, etc. (if you want details of what kind of uglyness went away, tell me, I can explain). This revelation caused to me reconsider C++ as the ultimate language. In python, I can simply write         for x in func1, func2:                 [some complicated code with x] in C++, I'd have to go through the hassle of defining the correct function signature as a typedef, then build an array, and then loop through that array using an integer, eg.         typedef void (*fptr)();         ..         fptr[2] = {&func1,&func2}         for (int i=0; i And usually, I don't go through the hassle , and just copy and paste [something complicated], which is also a Bad Thing. Maybe this is a slightly contrived example (I'm not sure about the typedef), but learning Python and LISP has made writing C++ a generally painful experience for me. Maybe nowadays some of my gripes may be soothed by the Standard Libraries, but I don't feel like learning yet another big C++ component, all the more because I know that afterwards C++ will still not be good enough (or will it ever have reflection, higher order functions, GC?) In this light, I find your statement that         starting to learn C++ is easier than starting to learn C dangerous, as are the examples in your "learning C++ as a new language paper" for they imply that any of these two languages can or should be a "first" language. Do you really want people grow up with a language that has distinction between non-immediate objects on the heap and stack, no automatic garbage collection, pointers, no initialization, no higher-order anything? You're educating people about C++: fighting misconception, telling them where it is good for. But you're not telling them what it is bad for. C++ is immensely popular, and people easily get the misconception that this popularity makes it a good language start programming with, or to write their highly tweakable programs, etc. Han-Wen Nienhuys -- LilyPond (http://www.lilypond.org)

You should consider learning C++. (Score:0, Flamebait) by Anonymous Coward on Friday February 25, @02:48PM EST (#116)

You sound like somebody who writes a 10,000 line C program all in main() with goto's, and then turns around and starts bitching about what a rotten language C is because it doesn't have line numbers. A good C programmer would spend ten minutes with such an idiot trying to explain how C is used, and if the idiot still insisted that C was BASIC, the good C programmer would use an important language feature called a baseball bat to modify the idiot's life-expectancy. You're missing the point in a very profound way. You're using a saw to drive a nail, and cursing the saw. typedef void (*fptr)(); .. fptr[2] = {&func1,&func2} for (int i=0; i ... True, that stuff's a hassle in C, but in C++ you can use an STL container for whatever you're keeping a list of, and use std::for_each() to call a function on each item in any given container. If you need to pass some arbitrary argument to your function, it's perfectly trivial to write a single (one, only one, single, solitary, not plural, only one, the number between zero and two, as in ONE) function template that takes an extra argument and passes it to the callback for each item. The problem here is that you don't know C++, and yet you're bitching about it. You are not using the relevant features of the language, and you're complaining that they're not there because you are too arrogant and lazy to RTFM and find out about them. learning Python and LISP has made writing C++ a generally painful experience for me. Learning C++ would make writing C++ considerably easier, if you were bright enough to grasp the fact that you do not understand what you do not know. I don't feel like learning yet another big C++ component, So quit whining. If you don't want to learn the language, that's your problem, not ours. In any case, it's not just the library you're not learning: You're refusing to learn a very important and central feature of the language (templates), and along the way you're utterly refusing to come to terms with the way the language was meant to be used.

Re:You should consider learning C++. (Score:1) by hanwen (hanwen@cs.uu.nl.nospam) on Friday February 25, @03:00PM EST (#122) (User Info) http://www.cs.uu.nl/~hanwen

I have learned C++, thank you. I am under the distinct impression that you have no clue. Please go here, and tell me on what you base your assertion that I don't know about C++. it's perfectly trivial to write a single function template And that is precisely my point: a function template takes up 5 lines of code, and using it another 2 (constructing the list, iterating). Contrast that with the one line python. that's a sevenfold increase in code size. Multiply the amount that you do loops over two element lists in a 50000 line program. That's a lot of preventable complexity. Han-Wen Nienhuys -- LilyPond (http://www.lilypond.org)

You have a lot to learn (Score:0) by Anonymous Coward on Friday February 25, @04:30PM EST (#161)

I have learned C++, thank you. I am under the distinct impression that you have no clue. Please go here, and tell me on what you base your assertion that I don't know about C++. I went there, and I agree with the previous poster. Sure you may know the syntax, but your code is terrible (sorry, but there's no better way to put it). I picked a random file, translator-group.hh. I see needless function pointer typedefs (you should make these functionoids). Virtual inheritance: you should rarely ever need to do this, and it's likely a symptom of a bad design. A friend class that's defined in a separate compilation unit - bad practice. Protected members - should rarely be needed in a good design. You have a destructor and copy constructor, but no assignment operator. That likely means serious problems if someone tries to assign to an instance of this class. This class's public interface looks pretty bloated. From just looking at one header file, I can tell that your OO design is very poor, and no doubt very well documented, and that you really don't know how to use the features of the language appropriately. It looks like you've tried to go through every feature in the book and use each one in your code. It looks like you've tried to hack your way around any problems you encounter by using C++ features. It looks like you've TRIED to make it complicated. Your code is extremely unwieldly, and I think you should have spent a *lot* more time thinking about your design, and about SIMPLIFYING things. It's good that you know the language relatively well, and are good enough to put together a large project with it. But you also need to learn that just because a tool seems to work OK doesn't mean it's the best tool for the job. I'd suggest reading a few books on object-oriented design, and on best practices in C++. Books that have worked well for me are: C++ FAQ's, Design Patterns, Object Oriented Software Construction, Effective C++ and More Effective C++. I was writing 10's of thousands of lines projects before I really learned how to use the language properly too. Don't be fooled into thinking that just becuase you've managed to write a relatively big project you know everything.

Re:You have a lot to learn (Score:2) by Baki (plm@gmx.li) on Friday February 25, @05:04PM EST (#176) (User Info)

I'd suggest reading a few books on object-oriented design, and on best practices in C++. Books that have worked well for me are: C++ FAQ's, Design Patterns, Object Oriented Software Construction, Effective C++ and More Effective C++. I was writing 10's of thousands of lines projects before I really learned how to use the language properly too. Don't be fooled into thinking that just becuase you've managed to write a relatively big project you know everything The fact that someone who manages to write a tool like Lilypond (can't be an idiot), and also yourself, has to read lots and lots of books and learn through writing 10's of thousands of lines on how to really use the language, is not a good sign. As for myself, I have about 5 years of exp. with C++ and two years now with STL. It is a big improvement (STL), I can write nice programs in C++ after all these years. BUT: I think it takes too long, and average people may never make it to understand the language and use it effectively. Currently I'm using Java, swearing a lot and longing back for C++ often. Still I'd really like to try Phyton or Scheme once. There must be an easier and more fool-proof way to do the nice things that can be done in C++.

Re:You have a lot to learn (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @07:18PM EST (#240) (User Info) http://CubicMeterCrystal.com

The fact that someone who manages to write a tool like Lilypond (can't be an idiot), and also yourself, has to read lots and lots of books and learn through writing 10's of thousands of lines on how to really use the language, is not a good sign. Hes not an idiot in the knowledge sense, but an idiot for refusing to accept the fact that he does NOT understand C++, and does not know how to write good code. The evidence is right there, written with his own hand, but until this individual realizes that his code has much room for improvement, it never will! This says nothing about the complexity of C++ in and of itself, other than the fact that some people consider themselves very skilled C++ coders because they managed to cludge together a pile of crap that doesnt drop core. As for myself, I have about 5 years of exp. with C++ and two years now with STL. It is a big improvement (STL), I can write nice programs in C++ after all these years. BUT: I think it takes too long, and average people may never make it to understand the language and use it effectively. I think the average person doesnt want to invest the effort into refining and honing their skills. Perhaps the mindset of the lillypond guy is indicative of the average C++ coder which would certainly explain why, after many years and lots of code, they STILL cant write C++ code that is worth the bytes its stored on. 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:You have a lot to learn (Score:0) by Anonymous Coward on Friday February 25, @07:57PM EST (#261)

"Perhaps the mindset of the lillypond guy is indicative of the average C++ coder which would certainly explain why, after many years and lots of code, they STILL cant write C++ code that is worth the bytes its stored on." It's amusing you don't think this reflects at all poorly on the tool.

Re:You have a lot to learn (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @10:10PM EST (#289) (User Info) http://CubicMeterCrystal.com

Hey, good tools have been written with assembly! and assmebly sucks for development! The tool may kick ass... i dont know. But bad code doesnt ALWAYS mean a bad product. And great, eleagant code doesnt always mean a great product either. They are two separate pieces of the whole, although often related. 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:You have a lot to learn (Score:2) by auntfloyd (rcl211@is9*fluffybunny*.nyu.edu) on Friday February 25, @11:29PM EST (#302) (User Info) http://www.csoft.net/~rcl/

I think he meant that you're blaming everything on the programmer, while ignoring potential problems with the tool (in this case, the C++ language). C++ is complex and cumbersome, and yes, a great deal of time must be invested in order to learn it. I can't help but wonder if that time would be better spent in more productive languages (Lisp, Dylan, Smalltalk, etc). Sigh...if only Gwydion Dylan were more advanced, we'd have all the benefits of C++ (OO, speed, small executable size), without all the problems (the language itself) on Unix. ~~~~~~~~~ auntfloyd See the auntfloyd thread

Re:You have a lot to learn (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @11:51PM EST (#303) (User Info) http://CubicMeterCrystal.com

In this case I AM blaming the above gripes on the programmer. The deisng of this individuals application is horrid, and hes passing off judgment on the language because of it. All of the issues I have seen him make so far with respect to C++ being a poor choice in light of Scheme or Python are due to implementation and design issues. And he obvously discounts these right off, as he knows what hes doing and how to utlize the powerful features of C++. That is the part thats pissing me off, and that is the part that I am criticizing... 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:You have a lot to learn (Score:0) by Anonymous Coward on Friday February 25, @09:47PM EST (#286)

I think the average person doesnt want to invest the effort into refining and honing their skills. Perhaps the mindset of the lillypond guy is indicative of the average C++ coder which would certainly explain why, after many years and lots of code, they STILL cant write C++ code that is worth the bytes its stored on. I think I read somewhere the average professional computer programmer writes code professionally for three years. If it takes five years of professional programming to write good code, that means the average programmer will write good code for negative 2 years of his/her/its career. Explains a lot.

Re:You have a lot to learn (Score:1) by hanwen (hanwen@cs.uu.nl.nospam) on Friday February 25, @07:52PM EST (#257) (User Info) http://www.cs.uu.nl/~hanwen

I picked a random file, translator-group.hh. You managed to randomly pick one of the two most complicated files (the other being score-element.hh). Virtual inheritance [..] You have a destructor and copy constructor, but no assignment operator. That likely means serious problems if someone tries to assign to an instance of this class. And you know C++? A class that has a virtual base class is part of hierarchy and usually accessed through a pointer to the baseclass. Assigning instances would lead to object slicing, which is why it has a copy-constructor and clone() function. (So sue me, I didn't add a private operator=() ) Han-Wen Nienhuys -- LilyPond (http://www.lilypond.org)

You don't get it yourself. (Score:1) by hanwen (hanwen@cs.uu.nl.nospam) on Friday February 25, @03:59PM EST (#145) (User Info) http://www.cs.uu.nl/~hanwen

I stand corrected. For looping over functions with one argument, you need only one template. Then you want to loop over functions with two arguments. Another template. Then you want to loop over member functions. Another template. Catch my drift? And this is only folding repetitive code into small loops. There is lots more that is obtuse in C++ for no good reason. Why the hell are you constructing a new list every time you need to iterate over an existing list? I am iterating over lists to fold repetitive code into loops. The contents might have been passed as arguments to a function, example below. I am not iterating over an existing list in the first place. You're still missing the point: 1. C++ adds lots of overhead that is just preventable. This is the part that makes C++ generally painful 2. C++ lacks some features because it is still C with OO bolted on top. This makes C++ impossible for some projects. real-life code sample follows (sorry for the lousy formatting). Notice that the two member variables (names ending in underscore) are not stored in lists. void Score_engraver::set_columns (Paper_column *new_command_l,                                   Paper_column *new_musical_l) {     Paper_column * news[] = {new_command_l, new_musical_l};     Paper_column **current[] = {&command_column_l_, &musical_column_l_};     for (int i=00; i != 2; i++)         {             if (*current[i])         {             if ((*current[i])->linked_b())                 {                   pscore_p_->add_column((*current[i]));                               scoreline_l_->add_column((*current[i]));                 }             else                 {                     /*                 We're forgetting about this column. Dump it, and make SCM                 forget it.                 (UGH.) */                     scm_unprotect_object ((*current[i])->self_scm_);                     *current[i] =0;                 }         }             if (news[i])         *current[i] = news[i];         } } Han-Wen Nienhuys -- LilyPond (http://www.lilypond.org)

Re: You STILL don't get it (Score:0) by Anonymous Coward on Friday February 25, @05:01PM EST (#175)

What the hell is that??? Ok, this obviously goes beyond a debate about C++ - you don't know how to design a function in ANY language. Look: void score_engraver::set_column(const Paper_column& source, Paper_column& dest) {       if (dest.linked_b())             pscore_p_->add_column(&dest);       else             scm_unprotect_object(dest->self_scm_);       dest = source; } void score_engraver::set_columns(Paper_column& new_command_l, Paper_column& new_musical_l) {       set_column(new_command_l, command_column_l_);       set_column(new_musical_l, musical_column_l_); } Was that so hard? OF course, you'd probably want to change it to use pointers. I didn't use pointers because they're generally evil, and people use them way too often when there's absolutely no need to. Anyway, cutting and pasting is NOT a bad thing. I would duplicate the entire function before I would go and do something as crazy and pointless as sticking stuff in an array and iterating over it. That's just retarded.

Re: You STILL don't get it (Score:1) by hanwen (hanwen@cs.uu.nl.nospam) on Friday February 25, @06:14PM EST (#201) (User Info) http://www.cs.uu.nl/~hanwen

Thanks for giving me another way to reduce code, maybe I'll add a bit of it. However, I am not sure if passing member functions that set member variables which are passed as arguments count as "elegant" in my book. Han-Wen Nienhuys -- LilyPond (http://www.lilypond.org)

Re: You STILL don't get it (Score:1) by HarpMan (smolitor@erac.com) on Friday February 25, @07:03PM EST (#232) (User Info)

The guy responding to you was pretty harsh. But, he was essentially correct. The contorted examples you gave really did indicate that you don't understand (or prefer not to use) the newer elements in C++ like templates, function objects and the STL. However, I don't think that anyone is saying that C++ is the perfect language for everything. For dynamic tweakability, it's hard to beat lisp dialects (look at the success of Emacs) or Python, as you indicate. I might even go so far as to say that one should prefer simpler, dynamic languages except in areas where performance becomes and issuue. That's why it's often good to use two languages on a project -- a fast language for the 'engine', and a dynamic language that supports easy configuration for the rest. Stephen Molitor steve_molitor@yahoo.com

Re:As I said: You don't get it. (Score:2) by caliban (patrickq@hotmail.com) on Saturday February 26, @04:45AM EST (#332) (User Info)

If you need to pass some arbitrary argument to your function, it's perfectly trivial to write a single (one, only one, single, solitary, not plural, only one, the number between zero and two, as in ONE) function template that takes an extra argument and passes it to the callback for each item. . . . As I said about eight or nine times, you only have to write the function template once. ONCE. That's why you make it a template: So you only have to write it once. Can you count to one? Try counting to one. When you get to one, stop counting. That's how many times you will have to write the function template: ONE time. 0++ ? ROTFL

You should consider reading his post (Score:0) by Anonymous Coward on Friday February 25, @03:22PM EST (#129)

His point was that the downsides of C++ should be well-advertised, so that programs suited to high-level languages will be written in high-level languages, and programs appropriate for C++ will be written in C++. If a program requires the nifty features of a language like Scheme, no amount of encyclopaedic familiarity with C++ is going to change its lack of truly high-level features (such as a functional language would have).

I did read his post. (Score:0) by Anonymous Coward on Friday February 25, @04:00PM EST (#146)

His point was that the downsides of C++ should be well-advertised He mentioned that right at the end, after a large amount of gibberish which demonstrated that he was totally incompetent to discuss anything at all about C++. He doesn't know the language. Whatever his point may have been, it was supported by total bullshit. so that programs suited to high-level languages will be written in high-level languages, and programs appropriate for C++ will be written in C++. The only way to get there is to persuade programmers to learn all the languages they may need: Minimally, C/C++, Scheme, and awk or perl or something for weird little shit. No doubt there are a couple of others that would come in handy. This, however, is not Stroustrup's responsibility any more than it is yours and mine: If Stroustrup should be evangelizing against man-with-a-hammer syndrome, so should we. We're all in this profession together, right? My problem with this guy's post is that he's posting ANSI C code and saying "look! C++ sucks!" He could just as well post awk code and claim to have proven that Perl sucks. It's gibberish. If a program requires the nifty features of a language like Scheme, no amount of encyclopaedic familiarity with C++ is going to change its lack of truly high-level features (such as a functional language would have). Scheme's a damned nifty language, I agree. Nevertheless, if you refuse to learn C++, no amount of blind arrogance will convince me that your opinion of it is even remotely valid. This guy gave an example of something that can be done in two lines in Python, and claimed that it takes a lot more code in C++. As it happens, it takes ONE line in C++, one function call, but he had no way of knowing that because he never bothered learning C++ before he started complaining about it. Furthermore, his example also demonstrates a serious failing of very high-level languages like Python: the Python construct he uses is built into the language, and if it's not quite what you want, you can either hack the interpreter or try to come up with a workaround. In C++, that particular specific feature is part of the library, not the language: It can be done in C++, and if you don't like the standard library version you can write your own, equally efficient, but better suited to your purposes. In other words, C++ provides that feature while letting you extend it or replace it; Python provides it and gives you the finger if it's not quite right for your needs. Python is great for certain purposes to which C++ is not well suited, but the example he gave was in fact wrong, irrelevant, and generally pointless. C++ is a low-level language which can be trained to behave like a high-level language without losing the advantages that a LLL provides. It comes right out of the box with a wide variety of pre-rolled HLL features in the STL, and if you need more, you can roll your own. No, it's not a perfect language, and, no, it's not perfectly suited to every programming task on earth. But learn it before you presume to discuss it.

60,000 lines of code not enough to learn C++? (Score:2) by Eric Green (e_l_green@hotmail.com) on Friday February 25, @04:41PM EST (#171) (User Info) http://members.tripod.com/~e_l_green

So what you're saying is that even though he wrote this fairly large project single-handedly in C++, a) he does not know the language, and b) it takes more than one project to learn C++. Sheesh, that's enough to make me want to learn Java instead :-). -E -- There is no conspiracy. [Not speaking for my cats!]

Re:60,000 lines of code not enough to learn C++? (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @06:59PM EST (#230) (User Info) http://CubicMeterCrystal.com

10,000 monkeys with typewriters can write C++ code! so what?!?! Some people have been coding for years and write shit code. It shouldnt be a surprise. Because they never learn and continually refine their skills as they go. But there are also people who have only been coding for months that can write some very good C++. Its not about time frame, its about the developers commitment to self improvement, value and refinement of skills, and motivation. (lastly, mental capacity, but even this doesnt have much effect without the previous attirbutes) 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:60,000 lines of code not enough to learn C++? (Score:1) by catenos (catenos@gmx.net) on Friday February 25, @08:55PM EST (#276) (User Info)

No, your implication, that writing code means learning how to write it well. Surely, you will improve in your coding skill, but that's not the same as activlely searching for and learning how to do something right. Especially that he wrote it alone (if he really did?!?), as you say, would rather explain why code could be bad. If you have to work together with others, you will faster get new ideas how to solve problems more elegantly. Btw, I don't mean to know whether the original poster knows C++ well, I just wanted to put your comment into a different light.

HEY, moderators -- hang on a sec. (Score:0) by Anonymous Coward on Friday February 25, @04:07PM EST (#150)

This is the guy getting moderated up here -- I think he just knocked a big hole in my argument here, but I don't have time right now to read over his post in detail, it's getting late in the day and I have work to get done. If you were going to up-moderate me, please check that link before moderating, because I may have just made a total ass of myself and maybe you should be moderating him up instead. If you were going to zap me down a point, check the link anyway and maybe you'll feel even better about it :) I did not expect my post to be up-moderated, I'm still not sure why it was, and now I'm beginning to suspect the post may have been entirely ill-advised from the get-go. I could be wrong about that but you be the judge. Thank you.

Re:HEY, moderators -- hang on a sec. (Score:1) by hanwen (hanwen@cs.uu.nl.nospam) on Friday February 25, @04:22PM EST (#159) (User Info) http://www.cs.uu.nl/~hanwen

Hey, thanks for listening to me (assuming you're the same guy .. you never know with these AC comments.) Han-Wen Nienhuys -- LilyPond (http://www.lilypond.org)

Re:HEY, moderators -- hang on a sec. (Score:0) by Anonymous Coward on Friday February 25, @05:37PM EST (#185)

The specific argument you were making may have had a whole in it, but your overall point was correct. There are a lot of problems in this guy's code. He's not making very effective use of the C++ language, nor is his design very good. No program is going to be perfectly written, and the concept of good code is very subjective. However, I think this gentleman is a perfect example of what Bjarne was saying about C++ users not being well educated about the language. I'm not some kind of C++ guru, but I know enough to recognize that pretty much all of his complaints come from not fully understanding the language. Unfortunately MOST C++ code is not well-written. This guy's code would be considered good most places. It takes a fair bit of reading, and a good year or two of developing OO programs in C++ (I don't mean using it to write school assignments either, I mean real world projects, 8 hours every day) to really be able to use it optimally. I don't think this is a problem with the language though. I think it's more of a consequence of the fact C++ is relatively new. People don't have a much of an idea of what good code IS. The C++ world is saturated with a lot of really bad books, bad teachers, and bad code. As such, people do not learn a lot of good practices, and will likely learn a lot of bad ones and develop bad habits. It's also important to realize that being able to write a 50,000 line program does not make you a good programmer. It's a lot of practice, but if you're practicing the wrong techniques, then it's useless. The real value comes when you learn how to do things PROPERLY. Then you can look back at your old code, and critique it, find all your mistakes, and say to yourself "wow, was I really that dumb?" That's when you realize just how valuable your newfound knowledge is.

Re:HEY, moderators -- hang on a sec. (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @06:26PM EST (#210) (User Info) http://CubicMeterCrystal.com

It takes brains that think on many levels to write good C++ code. Those brains dont congeal in hard skulls very often. That is the problem. Most of the developers out there that DO write bad code could read until they are blue in the face and STILL not *get it*. I read X number of books on Y. I know what im doing! This is EXACTLY the type of mentality that is a SCOURGE! yes, a SCOURGE! i cannot bash this type or arogant, self righteous ignorance enough. WAKE UP!! It is YOUR skills at risk, YOUR code that is affected. It is entirely worth your while to drop the expert fascade and think about everything your doing as if it may be wrong. Guess what, everytime you find something that can be implemented or organized in a better / more efficient manner. You may not be flat wrong most fo the time, but there is ALWAYS room for improvement.   99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:HEY, moderators -- hang on a sec. (Score:0) by Anonymous Coward on Friday February 25, @07:16PM EST (#238)

What open source program out there would say is an example of excellent C++ and OOD/OOP? I'm still learning C++ and a good example would be a great help.

Mozilla, the HURD (Score:0) by Anonymous Coward on Saturday February 26, @12:51AM EST (#312)

Even though neither is done yet, I think both the HURD and Mozilla follow good object-oriented design (which can balloon the time it takes to finish a project). These both use the technique that Stroustrup calls "mapping the problem domain"; the LISP programmer Paul Graham calls essentially the same technique "bottom-up programming"; Jon Bentley, IIRC, calls it "writing a domain-specific language". If you're having trouble with object-oriented design, you might try some of these techniques in these other languages before punishing yourself with C++. LISP especially allows flexible programming techniques in a fine-grained way. But if you must learn this stuff now, and with C++, probably Cline and Lomow's _C++_FAQs_ would do the trick. And even then, you'll still have to try a couple of large projects (or try one large project several times) before really getting the feel. Basically, what you want to do is write components in the language that formalize, that map out, the whole group of problems that your user will ever run into. You codify this as an abstract class (or as multiple abstract classes). Then, when you run across a specific problem (in the case of the HURD, let's say a new filesystem comes along), you just make a new subclass that solves this problem. To do this right, you'll really have to understand the set of problems you're dealing with. You'll want to say to yourself, "OK, I'm writing [for example] a VR sex simulator. What is the problem domain? What could change here?" The type of VR suit could change, the type of monitor could change. So we'll need to make an abstract class as an interface for the hardware. That way we can write the software without having to worry about all the specifics of the hardware; when we have specific hardware issues, we can deal with them in subclasses of the abstract hardware class. The software world we're simulating will have certain constants about it -- for example, we'll want to copy real-world physics. But the setting we can abstract away, even though all settings have these commonalities of physics. What about the characters in the simulator? Again, they'll be similar in some respects, and different in others. This will guide you in how to make an abstract class. But talking about it is pointless. Read _C++_FAQs_, glance at the Mozilla code, and then try multiple times to write this sort of thing yourself.

Re:Mozilla, the HURD (Score:0) by Anonymous Coward on Saturday February 26, @08:33AM EST (#345)

The HURD does not work, neither the original scrapped version nor the current one, so I would not send a beginning programmer ower there for example code......and anyway I would not send a beginning programmer to ANY OS code at all....

Re:better than C is not good enough (Score:1) by guerby (guerby@acm.org) on Friday February 25, @02:50PM EST (#117) (User Info) http://www.gnu.org/

I wholeheartly agree with you, C++ is far from being the best solution when you realize there is something else than C and its pointers around. However, no question on the potential flaws of C++ made it through moderation, so of course you can conclude it's the ultimate language ;-).

Re:better than C is not good enough (Score:1, Insightful) by Anonymous Coward on Friday February 25, @04:01PM EST (#147)

I think the whole point of C++ is to provide extensibility of the project without breaking 'client code' (code which calls derived classes via a pointer to the base class). This is accomplished via inheritance and polymorphism. The client code is relatively stable while the class hiearchy can change over time, hence extensibility. If the design of the project takes into account 'correct inheritance' and polymorphism, I think the amount of client code written will be relatively small. When I speak about client code, I am talking about the code which defines the application's behavior at a higher abstract level. The class hiearchy defines the concrete functionality, which can be modified, revoked, or extending by deriving a new class and overriding the functionality in the derived class. If you don't think your project will evolve and you don't plan to reuse your code, then by all means don't use C++. C will get your project done in record time. But you'll be in your private hell , rewriting functions and bending over backwards rewriting your main() and other functions which contain 'higher functionality'. Success with C++, I think, relies on how abstract your thinking is as well as how good you are with your C++ technique (polymorphism, templates, const correctness, encapsulation, design patterns, using the canonical class design). When you are good with your technique, writing the code just becomes mechanical, all of the malleable functionality is contained in the class hiearchy. The trick is using your C++ technique defining your class hiearchy to be flexible enough to change and still maintain 'object' semantics. I looked at your source archive, looks like you use public member variables in your classes, as a result you have broken encapsulation. How do you extend your classes without breaking your client code? Rewriting your client code from scratch? *wink* I think you're living in your own private C++ hell. I'd suggest you study Design Patterns and read the C++ FAQs as well as the TC++PL and if you really plan to create large C++ programs you'll need to read "Large Scale C++ Programming" by Lakos. Lakos will talk about strange and wonderful things like writing code which compiles and links faster. This way large scale code that takes 1 hour to compile and link can be done in 40 minutes. Interestingly enough, Lakos throws alot of Bjarne's OOD out the window, but you definitely won't have to worry about that until you have enough discipline to make your class member variables private.

Re:better than C is not good enough (Score:1) by hanwen (hanwen@cs.uu.nl.nospam) on Friday February 25, @04:18PM EST (#155) (User Info) http://www.cs.uu.nl/~hanwen

I looked at your source archive, looks like you use public member variables in your classes, as a result you have broken encapsulation. How do you extend your classes without breaking your client code? Rewriting your client code from scratch? The client, that's me as well. I am perfectly aware which parts of the interface are considered public which are not. I am a consenting adult (wink). One thing that bothers me about C++ protection zealotism (encapsulation, if you will) is that it assumes that behavior is something that can be encapsulated within one class. In the program you are referring to, a large part of the behavior emerges because two objects have "shared" behavior. Putting private: everywhere constrains the code, because it forces particular code to be in a particular class. The result is that half of the code is in a class where it belongs, and the other half is not. Moving the variable to a different class merely switches the halves. (The last chapter of SICP has an interesting footnote about this as well). In any case, my default mode is prototyping, and making everything public. The moment that a reason for encapsulation emerges, I make the relevant variables private, and the compiler catches all encapsulation violations for me. These are usually trivially to upgrade to a new interface. I'd suggest you study TC++PL In fact, I've read it cover to cover. I learned C++ from it. Han-Wen Nienhuys -- LilyPond (http://www.lilypond.org)

Re:better than C is not good enough (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @06:13PM EST (#200) (User Info) http://CubicMeterCrystal.com

One thing that bothers me about C++ protection zealotism (encapsulation, if you will) is that it assumes that behavior is something that can be encapsulated within one class Wrong! this isnt about bahavior. Its about abstraction and class data member integrity. You are confusing the two. Putting private: everywhere constrains the code, because it forces particular code to be in a particular class Wrong! It constrains code by restricting access to private, implementation details. The only public parts of a class should be the interface methods which access the information and functionality represented by the given class. Again, your confusing issues. If you dont want constraints, use C and make everything global! Constraints are your friend, not your enemy. The result is that half of the code is in a class where it belongs, and the other half is not. Moving the variable to a different class merely switches the halves. Wrong! This is a design issue, not a language issue. Functionality shared between objects should be abstracted into a separate object, or the two objects collated into one (if appropriate, though not likely in this case). It sounds like what has happened in your case is that you didnt spend enough time upfront with design. Design is much much more important in large OO systems than with any other type of implementation. If you dont do your deisgn right up front, you get problems like you have mentioned. In any case, my default mode is prototyping, and making everything public. The moment that a reason for encapsulation emerges, I make the relevant variables private, and the compiler catches all encapsulation violations for me. These are usually trivially to upgrade to a new interface. This is NOT OOP! I repeat, NOT OOP! This is a red headed stepchild of OOP! In fact, I've read it cover to cover. I learned C++ from it. There is a difference between reading a book and studying it. 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:better than C is not good enough (Score:1) by hanwen (hanwen@cs.uu.nl.nospam) on Friday February 25, @06:37PM EST (#213) (User Info) http://www.cs.uu.nl/~hanwen

Wrong! this isnt about bahavior. Its about abstraction and class data member integrity. You are confusing the two. Of course I use encapsulation if invariants must be enforced. That is besides discussion. What I am talking about is when there is no such thing as "data member integrity". Wrong! This is a design issue, not a language issue. Functionality shared between objects should be abstracted into a separate object The part of the program that was the most incestuous with objects is undergoing this transformation right now, but the "objects" are going to be scheme functions, because what I want the program to do can't be expressed in C++ conveniently. This is NOT OOP! Maybe you should read, erm, study the following quote by Bjarne Stroustrup: OOP wasn't a panacea. [..] [OOP] just isn't the right style for every program and for every detail of a program. Some good abstractions are best represented outside class hierarchies. This is a red headed stepchild of OOP! And I happen to like redheads. Han-Wen Nienhuys -- LilyPond (http://www.lilypond.org)

Re:better than C is not good enough (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @06:47PM EST (#221) (User Info) http://CubicMeterCrystal.com

Allright, my patience is tested... What I am talking about is when there is no such thing as "data member integrity". This is in the land of BAD CODE. Period. The part of the program that was the most incestuous with objects is undergoing this transformation right now, but the "objects" are going to be scheme functions, because what I want the program to do can't be expressed in C++ conveniently. At least you admit it was bad design. Scheme may very well be a great choice for the implementation of that piece of code, that wasnt my point though. It is the FACT that public data members are not only BAD, they are VERY BAD, and violate the msot basic concepts of OOP or even good coding practice in general. Maybe you should read, erm, study the following quote by Bjarne Stroustrup: OOP wasn't a panacea. [..] [OOP] just isn't the right style for every program and for every detail of a program. Some good abstractions are best represented outside class hierarchies. Correct. So use SOMETHING ELSE, but dont try and use a bastardized class. That is WRONG. Im sorry if youve convinced yourself otherwise, by thinking, wow, for 3 hours I thought about this and I cant think of a better way. There must not be one so lets break some fundamental guidlines. I will repeat. This is a DESIGN ISSUE! Just because you dont understand C++ and the design required for that peice of the code doesnt mean you are right, and can violate all sorts of common practice without thought of correction or pending consequence. This kind of code is crap. Pure crap. Sorry, but I dont think any other means of explaining it will get the point across. 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:better than C is not good enough (Score:1) by nerpdawg (engelnicNO@SPAM.home.com) on Friday February 25, @04:31PM EST (#165) (User Info)

Do you really want people grow up with a language that has distinction between non-immediate objects on the heap and stack, no automatic garbage collection, pointers, no initialization, no higher-order anything? I would say they should learn them at some point during the neophyte stage of developerhood. There are computer engineers and computer science majors just graduating that don't know how memory allocation and memory management work, and they're unaware that their use of language features can have any affect on runtime. I work on a project that develops OS-like things, and we're seeing a barrage of new grads that are confused by having to do their own memory management or pay attention to what language features actually do. There were actually some fairly bright people interviewed recently that had to have pointers explained to them. Regardless of language, not knowing the realities of memory usage/management has serious potential to make you a lousy developer in other languages. Now, that said, I'm not a blanket advocate of non-OOP languages. I think there are many oop language features that ease development and make maintainance easier. I even use some of them in projects I do outside of work (I'm actively learning c++, and I've programmed in smalltalk for a while), it's just that a good chunk of the software development world does work where real-time issues and hardware constraints are an issue. Not knowing how to use a pointer pretty much rules a person out as an embedded developer, compiler-writer, operating system developer, as well as many other things. Hell, even for programming in a language that doesn't explicitly have pointers, and that has garbage collection, I'd still like the person to know how to work with memory. I'd think a java or smalltalk developer that had never used a language that didn't keep track of memory for you would make a pretty lousy developer in their respective language.

Re:better than C is not good enough (Score:1) by ppanon (ppanon@home.NOSPAM.com) on Saturday February 26, @02:08AM EST (#321) (User Info)

Do you really want people grow up with a language that has distinction between non-immediate objects on the heap and stack, no automatic garbage collection, pointers, no initialization, no higher-order anything? I would say they should learn them at some point during the neophyte stage of developerhood. There are computer engineers and computer science majors just graduating that don't know how memory allocation and memory management work, and they're unaware that their use of language features can have any affect on runtime. I work on a project that develops OS-like things, and we're seeing a barrage of new grads that are confused by having to do their own memory management or pay attention to what language features actually do. There were actually some fairly bright people interviewed recently that had to have pointers explained to them. I completely agree with you that understanding the underlying implementation for most languages can be critical in implementing algorithms efficiently. No less than Donald Knuth makes this clear when he insisted that a low level assembly language, MMIX, still be used when revising TAoCP Vols I-III. Not knowing how to use a pointer pretty much rules a person out as an embedded developer, compiler-writer, operating system developer, as well as many other things. Hell, even for programming in a language that doesn't explicitly have pointers, and that has garbage collection, I'd still like the person to know how to work with memory. It is far from clear that pointers and pointer arithmetic are the best way to teach memory management concepts. Just because many MM implementations have used pointers to date doesn't mean that it's the only, or even best, way to understand the underlying concepts. If you are doing code maintenance, then odds are good your work will involve looking at somebody else's pointer code. But just because I was able to figure out somebody else's 1960s-style /370 assembler in the mid-80s (pushing an address on the stack and doing a branch because it's faster than a RET - or was it the other way around?) doesn't mean I would expect somebody nowadays to want to use that style. As far as I can tell, you're getting an ability to understand the lower level abstractions and implementations confused with the ability to use them directly when programming. The first is desirable, whereas the second is often contrary to OOP. Of all the examples you gave of where pointer techniques are "required", about the only two where I think you can make a good case are maybe the memory management portion of an OS, and some types of real-time code. In most other cases, better designed higher-level abstractions will usually be a better fit; however, you will have to be able to understand what is going on at the lower level to be able to design those higher level abstractions properly.

Re:better than C is not good enough (Score:1) by doodaddy on Friday February 25, @05:48PM EST (#192) (User Info)

Good points. I think the important issue to remember (and which Bjarne often points out) is that one language won't work for all problem types! What may not be pointed out very often, however, is that almost all large systems will include many problem types! You mention how Python can save lines of code. In your example, this is true because Python is not doing strong type checking. C++, and other strongly typed languages are forcing you to be very explicit about types. So why not just use Python? I can't tell you how many times strong typing has helped me debug a sophisticated data structure. Also, sooner or later, you're going to run into speed problems in a music type-setting program. Some speed cost is inherent in the fact that your language isn't strongly typed (-: You want to '+' two items? Well, are they strings are ints? In one case, you concatenate and in another you integer add. For strongly typed languages, the compiler would have known at compile time and already included the correct operations. If you've gotten away without specifying a type up until this moment...

static type checking vs. dynamic type checking. (Score:1) by hanwen (hanwen@cs.uu.nl.nospam) on Friday February 25, @06:08PM EST (#198) (User Info) http://www.cs.uu.nl/~hanwen

Also, sooner or later, you're going to run into speed problems in a music type-setting program. Some speed cost is   inherent in the fact that your language isn't strongly typed It's very well documented that you get more speed increase from better algorithms than from small optimizations (such as eliminating type checks). In a more expressive language (like Python or Scheme), you have more ways to write code, so you get more chances to use better algorithms; this is in fact something that happened when we used the Scheme interpreter in LilyPond. And your point about the cost of type checking isn't clear-cut as it seems. For genericity in C++, you need templates . Templates have a tendency lead to larger object code (well, in my experience anyway.), which in turn have lousy cache behavior. Han-Wen Nienhuys -- LilyPond (http://www.lilypond.org)

Re:static type checking vs. dynamic type checking. (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @06:37PM EST (#214) (User Info) http://CubicMeterCrystal.com

It's very well documented that you get more speed increase from better algorithms than from small optimizations (such as eliminating type checks). Yes, and in algorithm design you learn about optomizing those tight little nested loops. Its the iterative processes where small impacts add up to huge overall effects. By your (flawed) logic all 3D renger engines should be written in Python or Scheme! Cmon man, think about it. Anything you can write in Python or Scheme you can write in C or C++. And it all likelihood it will be MORE efficient, probably much more so. Period. In a more expressive language (like Python or Scheme), you have more ways to write code, so you get more chances to use better algorithms; this is in fact something that happened when we used the Scheme interpreter in LilyPond. Thats because you dont understand C++. End of story. C++ is FAR more expressive and extendible than either of those languages. Not that the expressiveness of a language has anything to do with an algorithm. An algorithm DESIGN should be completely separate from its language dependant IMPLEMENTATION. And an algorithm written in C/C++ will always outperform Python / Scheme 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:static type checking vs. dynamic type checking. (Score:1) by hanwen (hanwen@cs.uu.nl.nospam) on Friday February 25, @06:44PM EST (#217) (User Info) http://www.cs.uu.nl/~hanwen

By your (flawed) logic all 3D renger engines should be written in Python or Scheme! You are wrong. The topic that we were discussing was a music typesetter specifically, and definitely not a 3D rendering engine. C++ is FAR more expressive and extendible than [Scheme] I rest my case. You have no clue. Han-Wen Nienhuys -- LilyPond (http://www.lilypond.org)

Re:static type checking vs. dynamic type checking. (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @06:54PM EST (#227) (User Info) http://CubicMeterCrystal.com

You are wrong. The topic that we were discussing was a music typesetter                           specifically, and definitely not a 3D rendering engine. No, you said algorithms are more efficient in a more expressive language such a scheme or python. You said nothing about music typesetting in that algorithm remark. And even if it is a music typesetter, I still maintain that C++ will provide a better and faster implementation. I rest my case. You have no clue. Sorry, scheme may be more suitable for certain types of expression, but C++ can be used to do anything scheme can, and can also do all the lower level things that scheme cant. Some things may be prohibitvely hard to do, such as on the fly code generation and execution, but they are still possible with C++. This is one area where scheme would obviously be more efficient, but it doesnt sound like those are the types of algorithms we are talking about. If what you have in mind specifically is more suited for a scripted or rule based approach, then USE scheme or Python. but DONT make blanket statements that C++ is bad and Scheme is good because of your misconcpetions about OOD/OOP and what good code is. 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Scheme vs. C++ (Score:1) by hanwen (hanwen@cs.uu.nl.nospam) on Friday February 25, @07:19PM EST (#241) (User Info) http://www.cs.uu.nl/~hanwen

Some things may be prohibitvely hard to do [..] but they are still possible with C++ So what are you trying to say? That they're turing complete? Not a very useful observation. [on the fly code generation and execution] This is one area where scheme would obviously be more efficient, but it doesnt sound like those are the types of algorithms we are talking about Actually, the case I had in mind involved scanning all pointer members of all objects deriving from a specific class. In C++ this is very painful, because you don't have reflection. We moved all variables (including C++ pointers) into an association list, and recursively scanning that list is very easy, because you do something like         Scheme         scan (Scheme s)         {             if (ispointer (s))                   {                       [do_something and prehaps return                                 UNDEFINED]                   }             else if (ispair (s))                   {                         Scheme a = scan (car (s));                 if (a == UNDEFINED)                                                 return scan (cdr (s));                 else                         return cons (a, scan (cdr (s)));                   }                 return s;         } (The crux is that you filter all pointers that end up as UNDEFINED, from lists in the variable association list. The C++ version had to take out the pointers of arrays in derived classes one by one which led to quadratic behavior.) I'll admit you can do this in C++, but I don't think you can do it without duplicating a substantial part of a Scheme data structures. Han-Wen Nienhuys -- LilyPond (http://www.lilypond.org)

Re:Scheme vs. C++ (Score:1) by HarpMan (smolitor@erac.com) on Friday February 25, @07:29PM EST (#246) (User Info)

"The crux is that you filter all pointers that end up as UNDEFINED, from lists in the variable association list. The C++ version had to take out the pointers of arrays in derived classes one by one which led to quadratic behavior.)" Um, are you aware of the fact that C++ has an association list type, std::map? Stephen Molitor steve_molitor@yahoo.com

Re:Scheme vs. C++ (Score:1) by hanwen (hanwen@cs.uu.nl.nospam) on Friday February 25, @07:44PM EST (#253) (User Info) http://www.cs.uu.nl/~hanwen

Um, are you aware of the fact that C++ has an association list type, std::map? I guess so, but I am pretty sure that you can't store both         Foo * and         Array[Foo*] (sorry, do I get larger and smaller than in HTML?) as a value in the list, without having to fool the typechecker in complicated ways. Han-Wen Nienhuys -- LilyPond (http://www.lilypond.org)

Re:Scheme vs. C++ (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @10:01PM EST (#287) (User Info) http://CubicMeterCrystal.com

typedef Foo* foobar; typedef vector fooYou; typedef map > fooMap; iterate through fooMap. Or locate a specific fooMap with long ID. if the FooYou list has only one entry, you have one Foobar == one Foo *. And if Foo * ever changes to an array of Foobar *, then your entire traversal and location logic is never touched. Instead of thinking about what ISNT supported, think about a more standard and generic way to do what it is you are trying to do. If you ever find yourself making the compiler do tricks, chances are your design sucks. Rethink the process. 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:Scheme vs. C++ (Score:0) by Anonymous Coward on Saturday February 26, @04:11AM EST (#329)

If you ever find yourself making the compiler do tricks, chances are your design sucks. Rethink the process. Which is why he's redoing it in Scheme, where such data manipulations are much more natural. Please, do us all a favor and get a clue. It's bad enough that you have to parade your ignorance about all languages other than C++, but next time try thinking *before* you type. It can really mean the difference between making a valid point and humiliating yourself in public.

Re:Scheme vs. C++ (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Saturday February 26, @03:13PM EST (#360) (User Info) http://CubicMeterCrystal.com

(nekked) I am an idiot! (/nekked) I know pointer arithmetic in C.. does that count? ;) 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:Scheme vs. C++ FULL CIRCLE (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @07:30PM EST (#248) (User Info) http://CubicMeterCrystal.com

So what are you trying to say? That they're turing complete? Not a very useful observation. You said CANT be done in C++ but CAN be done and done fast and easy with Scheme. That was the bullshit I was stomping on. Actually, the case I had in mind involved scanning all pointer members of all objects deriving from a specific class. In C++ this is very painful, because you don't have reflection. Sorry, I cannot think of anything even remotely relevant where this would be nescessary. And EVEN if it were, a member method overidden by each derived class should handle this type of functionality. Again, this is a design issue, and as stated multiple times before, your design is horrible, and its causing all sorts of problems down the line. 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:static type checking vs. dynamic type checking. (Score:0) by Anonymous Coward on Friday February 25, @07:38PM EST (#252)

"C++ is FAR more expressive and extendible than either of those languages." Ummm, how much work would it be to write a specialized object system for C++? Even better, how can I simply write a program that writes programs? I'll concede your original point--C++ is generally more efficient than Scheme or Common Lisp. OTOH, how is C++ more expressive or extensible than the Lisp family of languages.

Re:static type checking vs. dynamic type checking. (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @09:47PM EST (#285) (User Info) http://CubicMeterCrystal.com

cout "#!/usr/bin/perl" endl; cout "print \"Hello World!\";" endl; 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:static type checking vs. dynamic type checking. (Score:2) by auntfloyd (rcl211@is9*fluffybunny*.nyu.edu) on Friday February 25, @11:57PM EST (#304) (User Info) http://www.csoft.net/~rcl/

How about dynamically creating code, compiling it to native code on the fly, then calling it as a function? How about rewriting a running program from within itself? How 'bout doing all this portably? With just the standard language, no shell calls? How about an interactive C++ system? Show me a new class system for C++ which you wrote with no compiler modifications. How about macros? And no, I don't mean that lame text-replacement nonsense that passes for macros in C. I mean truly integreatied hygenic (sp) macros such as those in Lisp. Or even simple things. In Lisp, things like 'if' return a value. So things like (defun max (num1 num2)     (if (> num1 num2)           num1           num2)) Why can't I do this in C++? That's something I consider expressiveness. None of this unmodifiable 'statement' crap. If I want to rewrite the if macro, then by John McCarthy, I'll do just that. Do *that* in C++, and I might think about switching from Common Lisp. It's this sort of thing that makes me wonder if C++ programmers ever come out from their caves and wonder if there is a better way of programming than what they're doing now. ~~~~~~~~~ auntfloyd See the auntfloyd thread

Re:static type checking vs. dynamic type checking. (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Saturday February 26, @12:17AM EST (#307) (User Info) http://CubicMeterCrystal.com

I said before that dynamic code creation and execution is a feature which is better supported by rule based scripting languages such as Lisp, and scheme. There are times when this is usefull, and necessary, but these times are mainly limited to configuration and dynamic organization issues. All of the issues that the above author mentioned as nescessary were NOT. They were only nescessary because his design was not well planned, nor well executed. This left various major flaws which could only be patched by this sort of *duct tape* flexibility. The whole approach which you attack things from is the exact opposite angle that a C++ or OOP coder would approach it from. The point is WITH A GOOD DESIGN YOU DONT NEED OR USE THOSE FEATURES. Lisp and Scheme have a very important place in development, but most people tend to agree that its for configuration and similar issues. NOT system development, NOT application development. There is a reason for this. Until you appreciate the fact that design is paramount in C++ and that the entire development method differs significantly from proceedural or rule based languages, you will be eternally frustrated with its limitations. This is NOT a language flaw. It is user error. End of story. 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:static type checking vs. dynamic type checking. (Score:2) by auntfloyd (rcl211@is9*fluffybunny*.nyu.edu) on Saturday February 26, @01:13AM EST (#316) (User Info) http://www.csoft.net/~rcl/

rule based scripting languages such as Lisp, and scheme. Lisp and Scheme have a very important place in development, but most people tend to agree that its for configuration and similar issues. NOT system development, NOT application development. Well, it was a good troll up until now. Now I can't take you seriously at all. I actually thought you were a serious C++ user. You certainly sound like one. ~~~~~~~~~ auntfloyd See the auntfloyd thread

Re:static type checking vs. dynamic type checking. (Score:0) by Anonymous Coward on Saturday February 26, @02:25AM EST (#323)

"these times are mainly limited to configuration and dynamic organization issues" Ummm, you forgot replacement of existing *running* code (or is this what you mean by dynamic organization) and domain specific languages "WITH A GOOD DESIGN YOU DONT NEED OR USE THOSE FEATURES." Oh really, didja ever think that using these features from the beginning might help you work your way towards a good design (the tracer bullet concept)? "Lisp and Scheme have a very important place in development, but most people tend to agree that its for configuration and similar issues. NOT system development, NOT application development." I don't think most people agree about anything. . .much less scheme and Lisp's place in the world (FWIW they "live" in quite different spots). If this were usenet, it would be time for a *plonk*.

Re:static type checking vs. dynamic type checking. (Score:0) by Anonymous Coward on Saturday February 26, @03:22AM EST (#327)

Or even simple things. In Lisp, things like 'if' return a value. So things like (defun max (num1 num2) (if (> num1 num2) num1 num2)) Why can't I do this in C++? template <class C> C max(C a, C b) {    return (a > b)?a:b; } Next question?

Re:static type checking vs. dynamic type checking. (Score:2) by auntfloyd (rcl211@is9*fluffybunny*.nyu.edu) on Saturday February 26, @04:05AM EST (#328) (User Info) http://www.csoft.net/~rcl/

Next question? Try doing everything else I mentioned. Or try passing a switch statement into a function call: (format t "the-var is ~a"     (cond ((atom the-var) "an atom")           ((null the-var) "null")           ((numberp the-var) "a number"))) C++ doesn't have the expressiveness of Lisp. Or the flexibility, which is why people don't like the way C++ restrains them. BS talks about how C++ can be used in many different programming paradigms, and he certainly lives up to his name. Try using something other than imperative OOP in C++. In Lisp, you can easily extend the syntax to support any style of programming: imperative, OOP, functional, logical, any more you care to think of. Why do you suppose it's been around for 40 years? ~~~~~~~~~ auntfloyd See the auntfloyd thread

Re:static type checking vs. dynamic type checking. (Score:0) by Anonymous Coward on Saturday February 26, @05:52PM EST (#365)

(format t "the-var is ~a"     (cond ((atom the-var) "an atom")        ((null the-var) "null")        ((numberp the-var) "a number"))) Please provide one good example of where that would be useful in a real program. In any real case I can think of, you should not be storing such disparate types in a way such that you don't know when you access them what general class they are.

Re:static type checking vs. dynamic type checking. (Score:1) by doodaddy on Friday February 25, @09:40PM EST (#283) (User Info)

Well, that is probably true. Especially if you pick very bad algorithms and compare them to very good ones. But as long as your picking and choosing, it may be valuable to type check as well. Of course. I assume you mean you look at algorithms at a higher level? ("more chances to use better algorithms" is a double-edged statement :-) There are also more chances to write worse code!) Hopefully Python does better than SQL as for as high-level! I don't know anybody who programs SQL that doesn't optimize the table searches in their mind first, THEN contort the algorithm until it is in a form that SQL (for a specific database) can work with efficiently. Anyway, SQL is a forced example, but there is a line between "controlling the machine" and "a language that controls the machine in a way that is always right, trust us" and the latter has been a miserable approach in all of my experiences. I'll have to check out Python. Good luck on your program!

Re:better than C is not good enough (Score:1) by osu-neko (osuneko(whirlpool)iname(spot)com) on Friday February 25, @07:21PM EST (#242) (User Info)

It should be noted that these aren't problems specific to C++, but are really problems for strongly-typed languages. Once you've learned a weakly-typed language (like Lisp), programming in C++ or any strongly-typed language can be quite painful. The extra work you need to go through so it will accept doing things that find simple, easy expression in weakly-typed languages is agonizing. Strong-typing gets you wonderful compiler performance. It should be used for anything where performance is essential. This does not negate the fact that it is hideously evil and should be avoided whenever possible, unless you like clunky, inelegant code... -- I'm not a monotheist; the world was obviously designed by a committee.

Re:better than C is not good enough (Score:0) by Anonymous Coward on Friday February 25, @08:42PM EST (#273)

While I generally agree with your sentiment, you're incorrectly stating that Lisp (FTM scheme) is weakly typed. Lisp is actually strongly-typed, but typing occurs at run-time.

Use the force (Score:2) by JamesKPolk (multivac @ fcmail.com) on Saturday February 26, @04:36AM EST (#331) (User Info)

Er, templates. Templates, like the force, are powerful, mysterious, and 3 people will give you 3 different descriptions and opinions of them. Let alone what 3 different compilers will give... typedef (*foo)(); QList<foo> bar; bar += myfoo1; bar += myfoo2; for(unsigned i = 0; i < bar.count(), i++)         bar[i](); I've never actually used a Qt list of function pointers before, but as far as I know, code like this should work.

Stopping the flames. (Score:2, Insightful) by hanwen (hanwen@cs.uu.nl.nospam) on Saturday February 26, @05:43AM EST (#335) (User Info) http://www.cs.uu.nl/~hanwen

[Culled from a mail to PureFiction. Hope this explains more clearly what I was trying to say originally, and not lead to flamefests] I made a mistake by setting LilyPond code as an example, which has lots of historic baggage. And no, don't start about good design; the problem I set out to solve was much more complex than I could imagine. Trying to design stuff is relatively easy when the problem is well-known, and the requirements for the design are obvious. In this case, neither was. You just have to try writing something, and see how it comes out. Then comes the problem with C++: going along with the general popularity of C++, you write the prototype in C++; I did. As you go along and improve the program, you abstract things into new classes, and extend it while throwing away code. However at some point you reach rock bottom with C++: you can't abstract away the fact the C++ is compiled, and you can not generate code or treat classes as objects. It's probably been my error to start the program in C++ in the first place. That is the real design issue. And this kind of design issue is not treated anywhere in the C++ books. The language is not complete (in an abstract sense), which means that it limits you in an essential way in how you can abstract the code you write. It is my impression that the C++ committee is also faced with limits on the language, and continually extends C++. What I can't fathom that nobody concludes         "Hey, backwards compatibility with C *and* full OOP support is too complex. Lets stop with C++ and start something new" but they say         "great, lets bolt another thing on top of the standard." This was the real reason behind asking my question to Bjarne. Until someone questions the design principles behind C++, it will never stop growing more complex. Besides all this it just a pain to write tight code in the language. I tried to demonstrate this by showing a small snippet of C++. This also was a mistake, because I got an enormous amount of flak for not following other people's petty rulebooks. And lots of people here seem to think that mindlessly following rules constitutes "good programming" or "good design". Those are the two points that I want to make. Unfortunately, my rhethorical skills are less developed than my programming skills. Maybe I should post on /. more often :-) Han-Wen Nienhuys -- LilyPond (http://www.lilypond.org)

Re:Stopping the flames. (Score:1) by GlowStars on Saturday February 26, @12:24PM EST (#351) (User Info) http://home.foni.net/~rossi

What I found rather amusing is that all C++ supporters on this flamefest were very quick to attack you on grounds of your Code snippets saying you should better learn (a lot) more of C++, without realising that this is the ultimate knockout argument against C++ as a general purpose programming language. One is probably able to do everything in C++ what can be done in Scheme, Python, ObjC, Java,C or whatever... But to do it in a natural, easy to grasp way your really have to be familiar with C++ to an amount that only few of us will ever achieve. Looking at 1200+ pages of the "C++ Primer" makes me shiver... Man, exactly how much do I NOT know of this monster of a programming language? But I'm still using - and struggling with - it. Cheers

Re:Stopping the flames. (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Saturday February 26, @02:09PM EST (#357) (User Info) http://CubicMeterCrystal.com

What I found rather amusing is that all C++ supporters on this flamefest were very quick to attack you on grounds of your Code snippets saying you should better learn (a lot) more of C++, without realising that this is the ultimate knockout argument against C++ as a general purpose programming language C++ isnt a general purpose programming language IMHO. C or PERL would be better for smaller more stand alone parts of computation. But nothing can touch the power, flexibility, and scalability of well written C++ system. Period. And it is the continual persuit of such systems and their attaintment which makes C++ so popular. The main point in criticizing this guys code was to highlight the fact that he needs to study OOD/OOP and the C++ language support for these features BEFORE he continues to bash the language itself for its percieved drawbacks. C++ is not for everyone. It IS an incredibly complicated language. But that is a good thing. It gives you the power to write fast, scalable, flexible systems when used properly. 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:Stopping the flames. (Score:1) by GlowStars on Saturday February 26, @05:55PM EST (#366) (User Info) http://home.foni.net/~rossi

C++ isnt a general purpose programming language IMHO. C or PERL would be better for smaller more stand alone parts of computation. But sadly a lot of students even have to learn C++ as first programming language, something I think is just plainly wrong. Of course teaching them perl would be much worse... But nothing can touch the power, flexibility, and scalability of well written C++ system. Period. And it is the continual persuit of such systems and their attaintment which makes C++ so popular. Well, that's IYHO of course. Myself I have yet to see something remotely as elegant and powerful as Openstep implemented in C++. C++ is not for everyone. It IS an incredibly complicated language. But that is a good thing. It gives you the power to write fast, scalable, flexible systems when used properly. But if it's such an incredibly complicated language why even bother with it? (provoking statement, I know). Wouldn't we not all be a lot more productive if modern programming languages were a lot easier to learn, grasp and use?

Re:Stopping the flames. (Score:0) by Anonymous Coward on Tuesday February 29, @01:00AM EST (#394)

Yes, you are absolutely correct.

Re:Stopping the flames. (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Saturday February 26, @02:20PM EST (#358) (User Info) http://CubicMeterCrystal.com

I made a mistake by setting LilyPond code as an example, which has lots of historic baggage. And no, don't start about good design; the problem I set out to solve was much more complex than I could imagine. Trying to design stuff is relatively easy when the problem is well-known, and the requirements for the design are obvious. Yes, that is usually the case. But good design isolates the unknown, variable and yet undiscovered parts from the concrete, well understood elements. This is where part of your problem lies. The inability to abstract and separate. In this case, neither was. You just have to try writing something, and see how it comes out. Then comes the problem with C++: going along with the general popularity of C++, you write the prototype in C++; I did. As you go along and improve the program, you abstract things into new classes, and extend it while throwing away code. However at some point you reach rock bottom with C++: you can't abstract away the fact the C++ is compiled, and you can not generate code or treat classes as objects. No, thats more of a C style development process. Ideally, you would design as much as you could from the known quantities, create the classes and relationships flexible enough to account for the unknowns and then your program can grow with the problem and new situations that arise. The fact that C++ is compiled SHOULDNT be an issue. Again, your blaming design issues back on the language. It's probably been my error to start the program in C++ in the first place. That is the real design issue. And this kind of design issue is not treated anywhere in the C++ books. The language is not complete (in an abstract sense), which means that it limits you in an essential way in how you can abstract the code you write. I would say it was an error to undertake this project in C++ with out a thourough understanding of OOD. It is my impression that the C++ committee is also faced with limits on the language, and continually extends C++. What I can't fathom that nobody concludes                 "Hey, backwards compatibility with C *and* full OOP support is too complex. Lets stop with C++ and start something new" but they say                 "great, lets bolt another thing on top of the standard." This was the real reason behind asking my question to Bjarne. Until someone questions the design principles behind C++, it will never stop growing more complex. Thats a whole other issue. I disagree here as well, but wont go into detail. Besides all this it just a pain to write tight code in the language. I tried to demonstrate this by showing a small snippet of C++. This also was a mistake, because I got an enormous amount of flak for not following other people's petty rulebooks. And lots of people here seem to think that mindlessly following rules constitutes "good programming" or "good design". That is such an ignorant statement. Think about it. Those petty rules which you violated where common practice for standard C++ development. The fact that you disregard them so easily is testament to your lack of knowledge with C++ and OOD. 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:Stopping the flames. (Score:0) by Anonymous Coward on Tuesday February 29, @01:02AM EST (#395)

The comments regarding encapsulation are on the money, but many of the other comments are pointless C++-isms.

Re:Stopping the flames. (Score:0) by Anonymous Coward on Monday February 28, @12:16AM EST (#384)

Trying to design stuff is relatively easy when the problem is well-known, and the requirements for the design are obvious. In this case, neither was. You just have to try writing something, and see how it comes out. A language like Scheme is a better tool when you're looking for a solution to a problem you haven't encountered before. You were really trying to discover a solution as opposed to developing an application. Your mistake was in choosing the wrong tool in the first place and then criticizing it. I've made the same mistake, too.

Fragile Base Class (Score:1) by epeus (fromslashdot@mmcorp.com) on Friday February 25, @01:27PM EST (#79) (User Info)

I notice that Bjarne mentions this in passing, but doesn't elaborate. It is this issue that prevents a solid ABI based on C++ that sues calss inheritance.

Angle Brackets Missing (Score:0) by Anonymous Coward on Friday February 25, @01:35PM EST (#85)

< (&lt;) and > (&gt;) have fallen out of the templates in this interview. Fix that at once! Thank you!

Great interview (Score:0) by Anonymous Coward on Friday February 25, @01:42PM EST (#87)

This was a great interview - thanks to all involved, especially Stroustrop. You made my day!

C++ > C + 2 (Score:2, Interesting) by exa (erayo@NOSPAM.cs.bilkent.edu.tr) on Friday February 25, @01:43PM EST (#89) (User Info) http://cs.bilkent.edu.tr/~erayo

I haven't been writing any C programs (except mandatory ones) for the last 3.5 years, and I don't think that C surpasses C++ for any real purpose. For programs of any size and of any choice I've found C++ to be the most expressive, flexible and efficient tool at my hand. For my stuff, "the worse is better" philosophy just doesn't work. Sorry Linus. From compiler writing to graphics, from combinatorial optimization to multithreaded protocol implementations, C++ proved to be the right tool for me. It did, because it is not a couple of ad hoc extensions over the C language. It is a new language, and a way better one. As far as I know, no other language comes close to the "multi-paradigm" features C++ offers, and with a most graceful treatment for efficiency. My advise is simple. Learn C++ in the true sense. First work through the language features with the latest editions of the wonderful books such as D&E or C++ Primer, and then proceed to the standard library to see *how it should be done* and to grasp *how to use the std lib*. The new ISO standard defines a language of power for any field. Don't forget that people who claim to know the language are quite a lot compared to the people who have comprehended it. --exa--

Learning C++ (Score:1) by duplex on Friday February 25, @04:47PM EST (#173) (User Info)

I agree with you entirely. In fact I'd like to expand your point a little here. Far too many people get frustrated with C++ because of the poor grasp of the language. However, it is not their fault entirely. Good C++ coding can take considerably longer to learn than good C because of the sheer size of the language. But there is a more fundamental reason for C++ vs C flamewars. This has to do with the fact that programming requires a very unusual mixture of qualities: a high degree of creativity and a lot of attention to detail. Most programmers have these two features planted in their brains in a reasonable quantity but they never have a perfect 50% balance. On one end of the scale we have the abstractionists who think in terms of the big picture design and 'see' projects in terms of components that interact with each othere. They are easy to spot in meetings because they are always the ones that tend to draw lots of UML and convoluted design graphs and they don't talk to people who haven't read the Gang of Four. On the other end of the scale we have 'bit fiddlers' (sorry i find this expression rather amuzing). These guys tend to worry about the low level implementation details and often think in terms of actual lines of code and often ignor the design issues. They are very good however, at spotting design flaws that make the implementation hard. Now, the problems lies not in the fact that we have these two groups of coder (see which category you fall into) but because these groups don't interact with each other very well. The abstractionists find it irritating that the implementationists don't see the 'big picture'. On the other hand the Bit Fiddlers get frustrated because abstractionists tend to overlook implementation issues. However, it takes both groups for a healthy software engineering project to thrive in my opinion. What I find is that abstractionists tend to like and 'get' C++ more because of the natural gift of abstracting their ideas. The implementationists prefer C because they live in a constant fear of what happens 'under the hood'. That's why they lean towards C. Having said that you do find abstractionists coding graphics pipelines and implementationists writing C++ frameworks. Unfortunately the results are often mediocre in such cases. So to summarise this already prohibitively long post I'd say find out what category you fall into and choose the language for you. You'll feel more comfortable and your code will thank you for it :-).

Its all gravy (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @05:33PM EST (#184) (User Info) http://CubicMeterCrystal.com

And then one day, after programming for a long number of years (it may be 2, but thats a long 600+ days!) you realize that it is all gravy. Yes, coding is just a big pile of your mothers fresh cooked tasty gravy.. mmmmm mmmm yeah.. You see, in the begging was the logic gate. And it gave birth to the integrated circuit. And you programmed those by connecting little wires. And then they sprang forth and multiplied until they were VLSI's which old beardy d00ds and young hacker punks coded with reams of elegant and obscure assmebly calls. And the assembly was a horny bastard, and gave rise to many bastard children like COBOL, Pascal, Lisp, C, Ada, Fortran, C++.. some of them less bastardy than the others.. And upon these good features were taken and incorportated, deriviations thrived. And you wake up one day and realize that its all a different shade of the same little bits flipping in your logic gates in silicon wafer. Because, after all, you were just building pieces.. linking them together. Aggregation, Abstraction, Encapsulation, Polymorphism. It was all occuring long before we even knew what is was and in various degrees of completeness. So you see, the true coder will see the advantages of a OO outlook on development. See its value in addition to the regular, algorithmic logic of proceedural code. And design patterns, objectless design, and all the other future meta abstraction possibilities will have their place as well. They are tools in the coders pocket, ready to use when applicable and well suited to a given task. We have only begun to build our gleaming cities of logic, and the need for flexible and plentiful abstraction techniques will be a need long into the future. All our pieces today providing for the framework of tomorrows systems. Flexibility, Extensibility, Reusability are the goals of the far sighted code poet. Fill your little hacker mind with all the goodness that is rule based, proceedural, OO, and abstract possibility. Code! 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

LISP a child of ASM? Since when? (Score:1) by HalloFlippy on Saturday February 26, @11:35AM EST (#349) (User Info)

hmmm... not sure if i'd call lisp a child of assembly programming. mathematicians were writing and executing lisp programs on paper when the *only* way you could write actual computer programs was using a hole punch and an opcode table (nothing so high-level as asm going on there). lisp isn't even based on the VonNeumann style processor (like C, Pascal, etc. are). To put in my $.02 on the flamewars... I'm one of those system-level thinkers someone mentioned earlier. I draw blocks and arrows for a living. Ie, OO styles work best for me, for the kind of programs (event-driven simulators, program understanding tools) I need to write. If I were to write a device driver, or OS kernel, I'd probably use C. I certainly wouldn't use it for a large, complex program, though. The biggest reason is that the program structure is too hard to document; maintenance happens, folks, just not with C. Use the right tool for the right job. And when I want to program for fun, I write in Scheme. :) ------------- How Flippy eats a Resee's: "First I define the Resee's cup to be logic level 1. Then I invert it."

Re:Learning C++ (Score:2) by JamesKPolk (multivac @ fcmail.com) on Saturday February 26, @04:29AM EST (#330) (User Info)

(looking over at the piece of paper, with a bunch of blobs, arrows, and such) So THAT'S why I feel so alone, sometimes, in liking C++. I just think differently from the C boosters, that's all. (I don't have the self-importance to say I think better :-)

Re:C++ > C + 2 (Score:0) by Anonymous Coward on Friday February 25, @05:57PM EST (#195)

Wrong. C++ C + 2

Re:C++ > C + 2 (Score:1) by jareds (jareds@mit.edu) on Friday February 25, @06:00PM EST (#196) (User Info)

C++ C + 2 I bet you meant to say, C++ < C + 2 Right?

One of the biggest problem with C++... (Score:2, Insightful) by rngadam (rngadam@yahoo.hatespam.com) on Friday February 25, @01:46PM EST (#91) (User Info)

One of the biggest problem with C++ is the lack of a featureful (freely available!) standard library to cover the range of things that Java covers (including the GUI). Obviously, that sounds like "everything and the kitchen sink" but at least you don't have to search days and night to find poorly designed/implemented libraries... And it can always be made "standard but optional". That is one of the reason why Qt is so popular: C++ is a great language when it has the appropriate libraries. But there is still some lacks as evidenced by the hack that Troll Tech has built. This is why the next big thing in OO won't be C++ but a free, efficient Java native compiler.

Java GUI Woes (Score:0) by Anonymous Coward on Friday February 25, @04:11PM EST (#153)

I'm glad that Java makes GUI easy, but it does it wrong. It's not cross platform. To see what I mean, for all the pluggable look-and-feel of Swing, try getting an Enlightenment theme to affect the appearance of a Swing app. Not cross platform is how I would say it.

Re:One of the biggest problem with C++... (Score:1) by PD (pdrap@startrekmail.com) on Friday February 25, @04:18PM EST (#156) (User Info) http://freetrek.linuxgames.com

What are you doing writing a GUI in C++? You are a BAD MAN! Heh! Just kidding. I would like to suggest that C++ is not the best language to write a GUI in. In fact, if you've got a large software project, it's not likely that a single language can possibly be flexible enough to easily cover all the pieces well. Maybe it is better to write pieces that C++ works well for in C++, but make it interoperable with a better language for building GUI's. I'm not suggesting that Tcl is a great language for GUI's, but it's fairly easy to embed a Tcl interpreter into a C++ program and use Tcl for some quick and dirty GUI work. So maybe the lack of really good support for a standard GUI library is a good thing. You have choices and alternatives. You are not forced to implement using the MSFoundation Classes just because that's what everyone else is using.

Cool!! (Score:1) by jallen02 on Friday February 25, @01:47PM EST (#92) (User Info) http://gdev.net/~jallen

Ive already taken a few deliberate moderation hits today to be goofy but this is awesome :-) I love when /. gets people like Bjarne to do interviews. Makes me feel all warm and fuzzy inside. This is content generation at its best! :-)

A mix is needed for a secessfull project. (Score:1) by infodragon (rreichFIGHT_SPAM@earthling.net) on Friday February 25, @01:53PM EST (#97) (User Info)

I truely belive that a mix of programming languages and methodologies is needed. Deciding on the mix is dependant on the project/problem at hand. Often the choice of the mix will determine the outcome of a project more than the actual implementation. For instance you take a huge project (200,000+ lines of code, not white spaces or comments). You have 20 programmers working on this project. Are all of them going to have the same skill set? Some are going to have a better grasp of OOP and some better at structured programming. This is where a good manager comes into play. He should be able to recognise who has what skills and devide the team accordingly. During this process the manager needs to find the people with strong aptitude towads the metholodigies which are going to interact and put them in charge of the interface of thoes metholodigies. After the team has been devided then the proper tools for a correct solution needs to be selected. The programmers selected to be in charge of the interfaces should be the ones to select the tools/languages based on the expertise in each of the teams. With a good mix of the above situation any software project is destined to be a success. I have personally been involved with a project of the one described and the results were phenominal! We used assembler, c and c++ with carefully designed interfaces. Each team had somebody who was extremely adept in what his team was working on and what his team was going to be interfacing with. The team was made up of the people who's aptitude mostly fit with the particular team. There were varying degrees of aptitude in which the expirenced tackeled the more complex problems and the novice tackeled the simpler problems or assisted the more expirenced. Sadly I've not found this situation outside the college environment. The above mentioned project was with an unmanned aerial-vehicle competition. Most of the students were there for the fun of it. The project was to designe an aerial-vehicle to map a simulateed a toxic wast field. Finding and diferentiating(SP) between barrels with either a raidoactive or biohazerdous symbol on them. There were quite a few disperate subsystems which exsisted. Mainly communications from the vehicle to the ground station. The vision system and the acompying software. The navigation system... In one year we built a system that took 3rd place in an internationl competition held at Eppcot Center Orlando Florida. Of course this type of environment needs decient people who know where their programming aptitude stands and not take offence to working on a simpler problem. For more than 4 generations the IT Professionals were the guardians of qualty and stability in software. Before the dark times. Before Microsoft...

The importance of Multiple Inheritance (Score:2) by Kaz Kylheku on Friday February 25, @02:09PM EST (#103) (User Info) http://users.footprints.net/~kaz/

I just want to say that I use MI much more often than single inheritance. I most often use inheritance to say that ``this object provides this protocol/interface/behavior'', and often have objects that provide more than one. I've also done this kind of multiple inheritance in C. I believe it's the most useful form of inheritance, and also the least kludgy and most genuine and elegant form of OO. Beyond being able to express interfaces, and dynamically bind interfaces to objects is the essence of object orientation. The ability to create a ``new kind of'' class with extra members, or overriden base members is just a handy kludge that sometimes saves work. Without MI, I would find the usefulness of C++ to be vastly diminshed to the point where I might as well be programming in C.

Lack of ABI -> C++ != java (Score:2, Interesting) by mnf999 (marc.fleury@nospam.telkel.com) on Friday February 25, @02:44PM EST (#114) (User Info) http://www.ejboss.org

Something strikes me when talking to the two communities. C++ guys will talk about features of the "language" and will wax poetic on STL. Java guys will consider STL as "just another library" and in java's case java.util.Collection.* but will talk about the API's, software design, extreme programming, and the high level libraries. In my case EJBoss is based on many 3rd party libraries (BullSoft, IBM, SUN, W3C, Apache, Dreambean, Telkel). That REUSE is possible given that java comes with bytecode format and a DEFACTO ABI.. This to me is the main difference between the two class of people. One is "stuck" at the language layer, and the only interesting discussions will be on compilers ( i am not saying they are not deep just that they are stuck in a "low level" language world). The other one is REUSING libraries and discussing software functionality. The design of large sofware frameworks is based on this. OOP Reuse is REAL in java and seems non-existent in C++ due to the lack of ABI. Please turn off the light in the C++ camp, as this to me is the future of programming i.e. online component based development. marc

Re:Lack of ABI -> C++ != java (Score:2) by Kaz Kylheku on Friday February 25, @03:44PM EST (#141) (User Info) http://users.footprints.net/~kaz/

Something strikes me when talking to the two communities. C++ guys will talk about features of the "language" and will wax poetic on STL. Java guys will consider STL as "just another library" and in java's case java.util.Collection.*                           That's because the C++ language has an international standard, a component of which is the C++ library which includes the STL. So, effectively, the library is part of the language. Java isn't a standardized language; it's still at the stage where programmer are used to thinking of it in terms of specific tools and libraries.

Re:Lack of ABI -> C++ != java (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @05:14PM EST (#178) (User Info) http://CubicMeterCrystal.com

n my case EJBoss is based on many 3rd party libraries (BullSoft, IBM, SUN, W3C, Apache, Dreambean, Telkel). That REUSE is possible given that java comes with bytecode format and a DEFACTO ABI.. What are you trying to say? That C++ applications cant use thrid party libraries? Oh wait, your only saying that you dont have to relink. Well, that little convienance comes at a price. Namely big fat binaries with lots of added overhead. The reason STL is so nice is because it IS a language standard, and is wonderfully extensible and usable. OOP Resuse is VERY alive in C++. Your an ignorant fool if you are suggesting otherwise. And its the very generic features of C++ (templates, multiple inheritance) that provide this ability to reuse code. Your only point has to do with cross platform portability which is a very minor issue is most code reuse situations. In C++ cross platform portability may be some added work, but its worth it given the features of the language. Your preaching Java from the wrong angle and with false pretence. 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Thanks (for nothing) Moderators! (Score:2) by Chris Siegler (siegler@citilink.com) on Friday February 25, @02:58PM EST (#120) (User Info)

helped cull this mass down to 10 extremely high-quality questions The key word there is helped. Why not remove the obvious flames, if they are still scored at 5, and send the rest to Bjarne? I'm disappointed that my question got Score:5, managing to overcome being posted late (#260 or so), only to get scrapped because it wasn't thought worthy by the /. crew.

Re:Thanks (for nothing) Moderators! (Score:0) by Anonymous Coward on Friday February 25, @03:38PM EST (#139)

Stop whining, you shitling. Just because you didn't make the cut doesn't mean you have to bitch and moan about it.

Re:Thanks (for nothing) Moderators! (Score:0) by The Future Sound of on Friday February 25, @04:33PM EST (#166) (User Info)

Yeah!

Re:Thanks (for nothing) Moderators! (Score:1) by osu-neko (osuneko(whirlpool)iname(spot)com) on Friday February 25, @07:34PM EST (#250) (User Info)

We don't want to overload the guest. If they guest wants to, he or she can answer more questions that the 10 sent to them. It's been done before. Bjarne obviously didn't want to. (Actually, from his comments, I get the impression he kind of did want to but really doesn't have the time.) Anyways, that's the guest's choice, no point blaming the /. crew... -- I'm not a monotheist; the world was obviously designed by a committee.

Wow! (Score:1) by GoodDoug on Friday February 25, @03:04PM EST (#124) (User Info) http://www.cse.ucsc.edu/~whitmore/

This was a great article. Probably the most information I've seen in one article on Slashdot. Thanks to Bjarne for answering the questions with such eloquence and humility. And thanks to the moderators for picking some really great questions. Though, I am surprised that there were no questions asking about the future of Java? Were there not any good ones? Or was there an intent to keep the questions focused on C++?

C++ carries the C compability burden (Score:2, Insightful) by vherva on Friday February 25, @03:31PM EST (#133) (User Info)

While I can't disagree with Stroustrup on that C++ might never have estabilished itself without the C compability, I getting more and more convinced that a good and clean language just can't have such historical burden to carry. Also, to be a clean language, C++ has too much awkwardness in its "advanced" features as well. I completely agree with the comment that the poor standard of C++ programmers is not due to poor education but to the complexity of the language. Programming in C++, too much effort goes into pondering the C++ syntax issues and compiler implementation problems. Don't get me wrong: C++ surely gets the job done, but I think it could be better and cleaner - mostly by removing some C compability and rethinking some other issues. Of course, this break the downward compability, and I'm pretty sure it'll never be done. One recommendation: try reading Stroustrup's D&E and Ian Joyner's Critique of C++ in parallel. -- v --

Re:C++ carries the C compability burden (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @04:31PM EST (#163) (User Info) http://CubicMeterCrystal.com

I just read Ian Joyners document. It can be summed up in one point. C++ allows you to do bad things (if you dont know what your doing), and various other gripes about cosmetic details. Whether this is bad or good is entirely subjective. There are cases where the 'dangerous' features mentioned are actually quite handy, and aid the deisgn of a given implementation. All of the pitfalls that Ian mentions are avoided by good programmers. The author is just biased towards a more rigid OO implementation such as Eifel or Java. 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

WARNING: EXAMPLE HTML-FUXORED < > (Score:1) by reney on Friday February 25, @03:36PM EST (#138) (User Info)

void draw_all(list<Shape*>& lst) { for_each(lst.begin(),lst.end(),mem_fun(&Shape::draw)); } -- "NT: taskmanager is not responding"

Standard Template Library and garbage collection (Score:2, Informative) by PD (pdrap@startrekmail.com) on Friday February 25, @03:49PM EST (#142) (User Info) http://freetrek.linuxgames.com

First of all, I'd like to say that garbage collection is an extremely useful thing to have in a programming language. If you use C++ you can get Boehm's garbage collector which is described here. I use this collector and it works well for me. Now, having said that, I find that the Standard Template Library is the other extremely useful thing to have. G++ has a really great implementation (so sorry to you folks stuck on Microsoft VC++) that WILL make your life easier. strings, vectors, and hashes! Learn those and a few of the generic algorithms and you can attack most of your problems. The remarkable thing is that you can do gobs of stuff with STL without using pointers and mallocs at all! Seriously folks, if you're into C then you should check out C++ using the two features I mentioned. You will be amazed at what you can do. You most likely won't need to malloc your own memory. And if you do, you can rely on the garbage collector to clean it up for you. OK, I'm done. I just love C++ and since I started using the collector and the STL I love it even more.

Re:Standard Template Library and garbage collectio (Score:0) by Anonymous Coward on Friday February 25, @06:24PM EST (#208)

Two things: 1) Boehm's garbage collector can also be used from C. 2) The stl is pretty cool, but generic programming is not new. Functional languages, starting with Lisp, have had the concept for a long time. C++ merely allows you to use these techniques in a widely accepted language.

A Key Point (Score:2, Insightful) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @03:50PM EST (#143) (User Info) http://CubicMeterCrystal.com

Abstraction is your god. The advantage of well written C++ or well written code in general is the abstracted interface of functionality it provides. This gives the developer the ability to view and modify a system in an intuitive, abstracted manner. Back in the day of systems programming with C, this was done to a very small degree with libraries and such, but times change. Today's systems are growing larger and larger, and will continue to do so indefinately. When systems get large, the most valuable feature set to build within them is abstraction and scalability (closely related actually). For anyone who thinks C will always live, you may be right. It will always have its place for certain tasks. However, C++ will also have a very prominant position is future development as the need for powerful abstraction and flexibility is required in a language. (to some degree this includes Java and such, but this is a C++ thread) Abstraction! 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:A Key Point (Score:0) by Anonymous Coward on Friday February 25, @06:51PM EST (#224)

"Abstraction is your god." I used to fervently believe this was true as well, but Richard Gabriel (Patterns of Software) makes a good case that abstraction is not always worthy of worship. Charlie Moore takes a different tack and eschews abstraction.

Re:A Key Point (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @07:09PM EST (#237) (User Info) http://CubicMeterCrystal.com

Ahaha.. I eschew Charlie Moore! Abstraction is not only nescessary, it is VITAL. And always will be. It is your tool of comprehension in the face of massive and nested / recursive complexity and chaos! Anyone who says otherwise is a blind fool who is calling abstraction by another name. 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:A Key Point (Score:0) by Anonymous Coward on Friday February 25, @07:55PM EST (#259)

Spoken like a true ideologue. . .in any case, I'd suggest Gabriel's book for another perspective on abstraction. FWIW, I was kind of sceptical as well, but then I read Williams' "Style: Towards Clarity and Grace." He puts abstraction (WRT English writing) in a different light as well. "Anyone who says otherwise is a blind fool who is calling abstraction by another name." Always sure the other guy is a fool. . .

Re:A Key Point (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @09:28PM EST (#279) (User Info) http://CubicMeterCrystal.com

ehehe.. of course! IM NEVER WRONG!!! NEVER!!! 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Näe.. (Score:1) by Caine on Friday February 25, @03:54PM EST (#144) (User Info) http://klondike.dhs.org

Well I think C++ could have been better with bundled standard libraries.

lack of runtime safety: underrecognized problem (Score:3, Insightful) by jetson123 (br_9801 at hotmail dot com) on Friday February 25, @04:11PM EST (#152) (User Info)

It's sad that Stroustrup didn't get a chance to talk about safety and fault isolation. I believe that lack of those features is a fundamental problem in the C family of languages and causing a lot of the most serious problems with computers today. What are some of them? Many (most?) security holes in clients and servers are due to buffer overrun problems: the Morris worm, bugs in Netscape and IE, bugs in IE, bugs in most Internet protocol daemons (sendmail, bind, etc.). These are entirely avoidable with almost no runtime cost. Component based software (browser plug-ins, COM/ActiveX components, Perl/Tcl/Python plug-ins, etc.) crash their hosting applications, often without even a clear indication of which component caused the system to fail. Many programs contain pointer errors and corrupt memory without crashing, resulting in incorrect results or incorrect behavior that often goes undetected for years. Even when the behavior is detected, it often can't be traced to the component that is causing it. This is a particular problem when software is reused, because the reused components are developed with unknown quality control measures and safety design methodologies. Most people seem to have come to accept the fact that their word processor, browser, and operating system crash with obscure register dumps with some regularity. But to a large degree, many of those problems are the heritage of some old design decisions in the C programming language, inherited by C++ and Objective-C. In fact, I think many of the serious problems we have with computers can be traced to lack of support for fault isolation and runtime safety in the languages we use, either directly (programs crash/have security holes) or indirectly (time that could go towards improving software needs to be spent on unnecessary testing/debugging). It isn't very difficult to come up with a programming language that is like C (or C++ or ObjC) but also provides support for runtime safety and fault isolation. You don't need to sacrifice any efficiency or systems programming features. But C++ has, so far, dropped the ball on this. Some of its abstraction facilities (e.g., the "string" class) alleviate some of the problems if used properly, but there are no guarantees you can make about any piece of C++ code, and even if you are careful, you can't avoid unsafe constructs in code that ought to be safe. That's why Java is catching on. Java may be lacking templates, systems programming support, multiple inheritance, and lots of other features. Java is also slow and heavy by comparison to C/C++. But Java does provide fault isolation and runtime safety, and in the end, that is what matters most to application programmers that need to get out reasonably reliable software on a tight schedule.

Re:lack of runtime safety: underrecognized problem (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @04:36PM EST (#167) (User Info) http://CubicMeterCrystal.com

Its a trade off. And good programmers dont write bad code. You can write a half million line code system in C++ and not have any memory leaks or pointer errors. It is possible, and in good programming teams, with reviews and standards, this is a minor issue. These errors are programmers faults, not language faults. They arise because of the POWER of the language. Sure you can use a less powerfull Java implementation, and it may be well suited for the development task at hand. But there is always a trade off. It will be slower, fatter, and have less features available to the coders. Its a design decision in the end, and personally I think more time should be spent making better coders, than writing more abstracted, fatter, less powerfull tools. 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:lack of runtime safety: underrecognized problem (Score:1) by Axe (Axe@HATESPAM@Mindless.com) on Friday February 25, @05:15PM EST (#179) (User Info)

It is possible, and in good programming teams, Yeah, if can hire one. In any large group of people (including our projects team) 80% are morons, and giving thema bazooka to shoot themself in a foot is not a good idea. Problem with runtime safety in C++ - you can not isolate that one moron who have dangling pointers all over him. In a safer language - you give guy an interface and specifications, then run automatic testing on his product, and if it works, it works, you do not worry it will crash... And good programmers dont write bad code Wrong. Shit happens. Errors happen. Unsafe code you inherited from somebody else happens. ----------------------------,

Re:lack of runtime safety: underrecognized problem (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @05:46PM EST (#191) (User Info) http://CubicMeterCrystal.com

My point was with the proper precautions in place, like code reviews, talented developers with experience, thorough testing and profiling, you CAN eliminate bad code from ever joining your source pool. And everything built on top of that will have a stable foundation. I do agree that a large number of developers are NOT good coders, and that needs to change. The smart companies hire $50-$100 an hour consultants with extensive experience and form teams with these individuals. You could do the same with selective hiring and thorough evaluations, but nowadays comapnies are so needy for talent that they will accept mediocre developers and ignore the negative impact they may have on the entire development lifecycle. A talented team and implementing the above precautions will give you a very robust, very stable software system. 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:lack of runtime safety: underrecognized problem (Score:1) by Art Tatum (jhclouse at hotmail dot com) on Friday February 25, @10:08PM EST (#288) (User Info) http://www.gnustep.org

I acknowledge that it would be nice if companies could hire whole teams of superb programmers, but this (as you seem to realize) just isn't going to happen. I have to say that even with good programmers, most problems arise from human error. This should tell us to write languages and develop tools that conform to human weaknesses rather than make humans jump through hoops for the compiler's sake. I think C++ sacrifices simplicity for performance to a degree that is no longer necessary--especially considering the modern optimizing compilers and cheap hardware we have now. Help! Help! I'm being repressed!

Re:lack of runtime safety: underrecognized problem (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @10:32PM EST (#297) (User Info) http://CubicMeterCrystal.com

And I think we need to make better coders. There is no reason a technically adept person and the right environment cant produce very stable, very well designed, and very efficient code. No reason at all. Anything is is a cop out IMHO. 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:lack of runtime safety: underrecognized problem (Score:1) by Art Tatum (jhclouse at hotmail dot com) on Saturday February 26, @06:45PM EST (#368) (User Info) http://www.gnustep.org

I don't disagree with you; my real issue is what I perceive to be a readability/comprehension problem with C++. I think the syntax and visual arrangement of a language has a huge impact on quality by making it easier (or more difficult) to understand what's going on. Plus, I believe in K.I.S.S. Help! Help! I'm being repressed!

Re:lack of runtime safety: underrecognized problem (Score:1) by Axe (Axe@HATESPAM@Mindless.com) on Friday February 25, @10:11PM EST (#290) (User Info)

Nope. A talented team nowdays may well reuse a whole lot of somebodies else code. Is not it the very idea of OO code design. You pop that COM piece in - it crashes you wonderful tested $100/hour code. And BTW some junkies code I had on my hands to fix was by some super expensive consultants. Let's face it, having everything okey-dokey in a big piece of software nowdays is, what your handle says - Pure Fiction. Having it implemented in a languages that isolate potentially bad parts of the code and enforces proper memory access and management solves a TON of potential problems. ----------------------------,

Re:lack of runtime safety: underrecognized problem (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @10:29PM EST (#294) (User Info) http://CubicMeterCrystal.com

Ok, you mentioned COM/DCOM?. Microsoft SUCKS ASS, all their components suck ass, and anyone using their shit best not expect anything that DOESNT suck ass. If this wasnt a microsoft component, then a review would have caught that error. All of our thrid party libraries and components are thoroughly tested to catch these types of situations. Furthermore, a review process would have caught that slack consultants code. Period. Go back to your Visual Basic. 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:lack of runtime safety: underrecognized problem (Score:1) by Axe (Axe@HATESPAM@Mindless.com) on Friday February 25, @10:31PM EST (#296) (User Info)

It seems to me you are from the other planet. You have no idea whatsoever what you are talking about and is being done in the real world - that's the final diagnosis. And BTW, personally I develop on Linux with CORBA. NOt that it matters for you. ----------------------------,

Re:lack of runtime safety: underrecognized problem (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @10:39PM EST (#299) (User Info) http://CubicMeterCrystal.com

I am most definately an alien species. Ok, nice goey CORBA ORB's on linux. What, you code GNOME and now your a professional expert? If you were to argue cost / time constraints I would conceede the point. That would be the only remotely allowable exception for using untested, third party products and being bumfuzzled when you implement in production, and holy shit batman, our object server dropped core. Whats done in the real world... hmm... nope. Anyway, like I said, reviews, testing and skilled coders TOGETHER will provide for very stable, well designed systems. Not just one piece (He was a $100 an hour consultant!) or (It was the IDL Compilers fault!!) .. but all together. P.S. Do you work with CORBA in a production, real world environment? 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:lack of runtime safety: underrecognized problem (Score:1) by Axe (Axe@HATESPAM@Mindless.com) on Friday February 25, @10:55PM EST (#300) (User Info)

Sorry, but you are a moron. Bye. P.S. Yes I work in a real world enviroment. Scintific data analysis and DAQ code. As well as, in particular, sattelite flight software. ----------------------------,

Re:lack of runtime safety: underrecognized problem (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @11:14PM EST (#301) (User Info) http://CubicMeterCrystal.com

And you refuse to accept responsiblity for the development process. At least if you continue to assert the fact that all the problems you mentioned COULD NOT HAVE BEEN PREVENTED with reviews, testing, and standard process. I think your an offended VB Scripter that wishes he was coding linux candy... ;) 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:lack of runtime safety: underrecognized problem (Score:1) by Axe (Axe@HATESPAM@Mindless.com) on Saturday February 26, @10:40PM EST (#373) (User Info)

I think your an offended VB Scripter that wishes he was coding linux candy... ;) You can easily find my work if you want. Could you point me to yours? ----------------------------,

Re:lack of runtime safety: underrecognized problem (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Saturday February 26, @11:05PM EST (#374) (User Info) http://CubicMeterCrystal.com

I wish I was coding linux candy full time. But I am currently on a project implementing HA distributed CORBA frameworks for internal software deployment. We have the framework on HP and SUN, with Java for the GUI interface. This code is written with the above precautions, and we dont have production problems aside from the rare misconfiguration issues which are quickly diagnosed and fixed. Once or twice a month a component will hang, but the HA software and internals catch this as well leaving about 5 minutes of downtime before failover. So, your assertion that reliable, flexible cannot be written is false. But it isnt easy either. Allright, your not a VB coder.. I take it back.. 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:lack of runtime safety: underrecognized problem (Score:2) by jetson123 (br_9801 at hotmail dot com) on Saturday February 26, @06:30AM EST (#340) (User Info)

The same problems occur with Netscape plug-ins, dynamically loadable Linux kernel modules, native code Tcl extensions, native code Perl extensions, native code Python extensions, and a lot of other software. And if you think you can catch those problems reliably with a careful test of the binary code, you are kidding yourself. Very common kinds of bugs in those components (off-by-one errors, buffer overflows, changes to the floating point modes, etc.) can cause very subtle problems in other parts of the system. Without language/runtime suport, you won't find them, support that C/C++ doesn't have. And even if you could catch those errors, what would you do? Throw out the system-supplied standard libraries? the GUI toolkit you are using? BTW, I have written a lot of C/C++ code, and continue doing so. But that's for research and experimentation. For multi-programmer code that goes out the door, Java, Modula, Eiffel, Python, and other, safer languages are clearly vastly superior.

so you are PERFECT and the only one on the project (Score:1) by FutileRedemption on Saturday February 26, @05:52AM EST (#336) (User Info)

obviously. sorry, but your opinion simply is silly. Your java programming competition will be very happy.

Re:lack of runtime safety: underrecognized problem (Score:2) by jetson123 (br_9801 at hotmail dot com) on Saturday February 26, @06:16AM EST (#338) (User Info)

Well, I claim, the lack of runtime safety in C and its descendants is a peculiarity and historical accident of those languages. I claim that there is no power you gain from it over alternative designs. The problem with C/C++ is not that they give you power, but that they don't give you the tools you need to ensure safety in those parts of a program where you need them. As for "with better coders, it doesn't have to be a problem", that may work for very well run organizations developing all their own code. And even for them, the required testing cost them plenty in time-to-market and testing resources. For the rest of us, who try to reuse commercial components and libraries, we simply don't have control over the testing that goes into the components we have to use. For starters, if you develop on Windows or Linux, you are already relying on millions of lines of source code that were developed with enthusiasm, but hardly the kind of quality control that ensures "no pointer errors in half a million lines of code". Quite to the contrary, both of those systems are known to contain plenty of pointer errors. And those errors can cause silent, serious errors, for example in a financial application.

Re:lack of runtime safety: underrecognized problem (Score:0) by Anonymous Coward on Friday February 25, @09:41PM EST (#284)

He addresses this in "The Design and Evolution of C++" and points out that some compilers offer these features (after reading this interview I had to stop at Borders and buy it; good book).

safe implementations of C++ exist??? (Score:2) by jetson123 (br_9801 at hotmail dot com) on Saturday February 26, @06:23AM EST (#339) (User Info)

There are indeed some safe runtimes for C and C++. However, they are not suitable for delivering applications. The kind of overhead they impose is considerably greater than runtime safety costs you in Java or other safe languages--you are better of using Java than using one of those runtimes. At the heart of the problem is that C/C++ don't have a standard way for programmers to specify information that is important for efficient runtime checks. In particular, in C/C++, the "pointer/reference" construct is used for arrays, references to local variables, call-by-reference, raw memory manipulation, format conversions, and some other purposes. But because you can't tell the compiler which of those you are intending to do, they compiler can't check for you efficiently--it has to check all the possibilities. This lack is a peculiarity of the C/C++ family of languages. It has nothing to do with power or lack thereof. You could add the necessary constructs to C/C++ without removing any of the power. C/C++ are simply deficient in a number of important language constructs. Java may lack template constructs, but C/C++ lack crucial typing constructs.

Lack of ABI is C++'s biggest failure (Score:0) by Anonymous Coward on Friday February 25, @04:31PM EST (#164)

Admit it Bjarne!

STL info (Score:1) by _Roadkill (rhopkins-at-crosswinds-dot-net) on Friday February 25, @05:37PM EST (#186) (User Info) http://www.crosswinds.net/~rhopkins/

Where can I find more information on STL? It's sad to live in a world where knowing how to program your VCR actually lowers your social status...

your local bookstore (Score:0) by Anonymous Coward on Friday February 25, @06:48PM EST (#222)

cheapskate :)

Re:STL info (Score:1) by link2NULL (link2null@hotmail.com) on Saturday February 26, @01:17AM EST (#317) (User Info) http://shrike.depaul.edu/~nmckinne/

Musser and Saini STL Tutorial and Reference Guide was used in one of my courses, but a reference guide is probably not the best way to learn STL (or anything else). The page for it at Amazon is here, so maybe read the reviews from that page and see what you think.

C++ is a manager's language... (Score:1) by karzan on Friday February 25, @05:39PM EST (#188) (User Info)

Ok, let's say we live in a perfect world, where C++ is actually portable and compiled in a reasonable way (I am currently in the midst of a large project where the C parts port without any effort between Unices and the C++ parts require an extreme amount of tweaking, but...) Let's say C++ is an evolved standard, and it can be depended upon. What is the point? Here's how I see the differences between C++: A) a lot of useless abstraction and B) a lot of things you CAN do in C, you CAN'T do in C++. What is the point of all this? Near as I can tell, it was designed for managers. Managers looked at C, which is an elegant, excellently defined language, and had a few problems with it: It only requires about 10 pages to document the entire language. Clearly something this simple is primitive and should not be used in 'our department'. It gives programmers a ton of free rein and artistic range. You can combine the various simple pieces of the C syntax to make really complex, beautiful pieces of code that are elegant, easy to read, and function great. This is NOT good. Inconvenient little things like variable length argument lists and untyped functions MUST go! It's too much like the way the computer really works. Why, why should we have to think about complicated things like 'memory' and 'order of execution' when we can think in terms of cute little objects warbling around in our head? Not enough sexual metaphors. I mean, C has nothing in it about reproduction, whereas C++ has the obvious advantage in that it's FULL of reproductive terminology. My conclusion: The number one reason anyone picked C++ in the first place was because they went to a store, and side by side they had 'C' and they had 'C++'. Which one is obviously better? Which one is the more advanced? Which one is the more MODERN AND PROGRESSIVE? Obviously the one with the ++ on it. MORE IS BETTER. Managers want a language that restricts programmers from doing interesting things, and has more buzzwords and hype surrounding it. Programmers who go to all the trouble of learning all the insane abstraction and crap that surrounds C++ want to feel like they've invested their time wisely and are a valuable contribution to a workforce. Thus, C++ is clearly superior to C; C is just too simple, too elegant, and too direct. I am tired of this crap. I love and respect the C language; it has a well-defined structure that works like a human language, in that it can have its own idioms, cool grammatic twists, etc that are all correct but all very interpretive. It is SO simple. I simply don't see the point in any language that takes more than 10 pages to document. C++ is a manager's language; it is a hype artist's language; it is the language of people who aren't satisfied with using something simple and have to go clutter it up to satisfy their ego. I realise C is falling in the face of C++. I find this incredibly sad. Is there any reason for this? No. Please, will someone explain to me where my poor variable-size argument lists went? Please explain to me why I have to prototype everything (and on and on) ... Please explain to me why I need 'objects' and 'templates' if I want to write a program that, say, converts JPEG to TIFF. I mean, hell, if you're writing some huge crappy Windows app, maybe you need it. But if you're being sensible and writing a set of small, clean programs that interact well with each other, why do you need all this object shit? COMPUTERS ARE NOT OBJECT-ORIENTED; NEITHER SHOULD PROGRAMMING LANGUAGES BE. When I do something in C, I know pretty precisely how the computer is going to behave; when I do something in C++, I haven't a clue. I can't pass a fucking function pointer outside of an object and expect other objects to be able to execute that function. WHY NOT?? I mean, the fucking memory is there, it's at the right address, I should be able to execute any fucking address in my memory space. But in the name of progress, everyone wants of course to adopt a language that actually lets them do LESS. Typical. This is not flamebait. I am just incredibly tired of this hyped up, crap language. Don't you people have any respect for C and what it can do? Would you rather be writing in COBOL? Pretty soon, we will be programming not with this 'old' concept of object-orientation, but with the new paradigm of 'warm pink fuzzies'. 'Warm pink fuzzies are very useful, you see, they are the next big thing... Unfortunately, we have had to maintain compatibility with this primitive language called C++, but....'

Re:C++ is a manager's language... (Score:1) by PureFiction (coderman@mindspring.com.nospamplease) on Friday February 25, @05:56PM EST (#194) (User Info) http://CubicMeterCrystal.com

You dont understand OOD or OOP with C++. Period. Its blatantly obvious. If you really want to know where your vargs went the way of the dinosaur go pick up a book on OOD. Then think about large software systems. Think about distributed software development. Think about abstracted flexibility and scalability. Sure, for converting JPEG to TIFF you wouldnt even need an object most likely. That would be a member method of Image which could read any image format and export in any format and all it would take is a ImageObject.write(gifFIle); oh, you want a JPEG? ImageObject.write(jpegFile); So, do yourself a favor and actually take the time to understand what OOD/OOP is about. 99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."

Re:C++ is a manager's language... (Score:1) by porky_pig_jr on Friday February 25, @06:23PM EST (#207) (User Info)

Amen, brother ...

Re:C++ is a manager's language... (Score:2) by Broccolist on Friday February 25, @07:25PM EST (#244) (User Info)

First of all, since C++ is a 99% superset of C (that is, almost all C code including variable length function arguments is also valid C++), arguments like "C++ lets you do less" are not valid. Anything you can do in C, I can do in C++ in exactly the same way. As for untyped functions (I'm not familiar with that term, but I presume you mean functions with no prototypes), just spend a few extra seconds to write a prototype for every new function, it will save time in the long run; and I don't see how it "weakens" the language. The complexity of C++ is a valid argument and I agree that the simplicity of C is one of its major strengths. However, I think by blasting "abstraction" is general, you are missing something that is fundamental to *all* programming, not just OO. For example, the concept of "function" is an abstraction. After all, "goto" is much more like the computer *really works* than insane abstractions like loops and organised blocks of code. Why should programmers waste time learning useless bloated things like that? So, assembly language is clearly superior to C; asm is much more simple and direct. COMPUTERS ARE NOT STRUCTURED; NEITHER SHOULD PROGRAMMING LANGUAGES BE. You can see how silly the preceding argument is :). Well, after learning OO, the discourse from structured-paradigm programmers sounds strikingly similar. After a while, thinking of things in terms of objects becomes just as intuitive as thinking in terms of functions, and you don't want to go back. If you explore OOP, I think you will find that it is beautiful. Most C++ programmers have lots of respect for C; after all, it is half of our language. Perhaps before being disrespectful to C++, you should learn more about it. Broccolist

Re:C++ is a manager's language... (Score:1) by kazzuya (dpasca@ix.botsaisucks-netcom.com) on Friday February 25, @07:25PM EST (#245) (User Info) http://diarydiarydiary.com/kazzuya

I think many programmers are just actracted by the complexity of the language. They take it as a challenge to understand that crap and waste most of the time trying to use it. Just like Internet age computer hobbists that fill up their Windows system with crap till it folds on itself and then enjoy reformatting and reinstalling everything from scratch. Too much time to waste !! Funny how everyone is raving about Linux these days. Linux which is based on notions and a language born 30 years ago ! UNIX means C and C means UNIX.. I will not be assimilated !

Re:C++ is a manager's language... (Score:1) by osu-neko (osuneko(whirlpool)iname(spot)com) on Friday February 25, @07:58PM EST (#262) (User Info)

Please explain to me why I need 'objects' and 'templates' if I want to write a program that, say, converts JPEG to TIFF. I mean, hell, if you're writing some huge crappy Windows app, maybe you need it. But if you're being sensible and writing a set of small, clean programs that interact well with each other, why do you need all this object shit? You don't. Just like you don't need a compiler to write computer programs -- entering raw hex into a file works just fine if you're good enough at hand assembling your own code and understand the executable file format. But just because you don't need something doesn't mean it's not useful to have. COMPUTERS ARE NOT OBJECT-ORIENTED; NEITHER SHOULD PROGRAMMING LANGUAGES BE. Extending this argument to its logical conclusion, programming languages should not have structs, since computers only deal with information a register at a time. Why create this completely unnecessary higher level abstraction when it doesn't allow you to do anything you couldn't do before? Also, things like for and while loops ought to be replaced by labels and conditional gotos. Perhaps because it makes life easier in many cases? But in the name of progress, everyone wants of course to adopt a language that actually lets them do LESS You mean like C? What's with these "functions" in C? C has this silly concept of a block of code that can ONLY be entered at this ONE point, so you can do LESS with it than if it allowed entry at any point like you can in assembly. What's with that? Why is C so limiting? Why can't I include in a function call a label within the function to start execution at? Perhaps because it's dangerous and unnecessary? The point being, C does all the same evil things you complain about C++ doing. It introduces unnecessary abstractions. It limits you, preventing you from doing things you "ought" to be able to do (if you think that because the CPU will let you do it, you "ought" to be able to do it). This is the price you pay for not coding in assembly language. Live with it, or don't, but it's silly to complain that the problem with such and such a language is that (to interpret your words down to their base meaning) it's not assembly language. -- I'm not a monotheist; the world was obviously designed by a committee.

exactly... (Score:0) by Anonymous Coward on Saturday February 26, @12:17PM EST (#350)

As an 8-bit controller assembly hacker, I'm completely bewildered by the utter lack of test-and-branch operations in all the C-family of languages (perl, python, java etc.). What's up with this anyway? How can you possibly write useful code without jumps? I've heard all the elitist claims about "real programmers don't use GOTO" but I guaran-damn-tee that your precious compiler's output is full of conditional and absolute branches. So why not give that control to the programmer too? C/C++? Gimme BASIC any day!

Re:exactly... (Score:0) by Anonymous Coward on Wednesday March 08, @12:32AM EST (#404)

High-performance CPUs also have register windows and branch delay slots and loads of crud we're better off not knowing about because they aren't portable, the compiler will make fewer mistakes on that kind of mind-numbing grunt work (do you track your finances doing arithmetic on paper?), and above all because the maintainer (who was often also the author) will be in a hell of pressure and confusion because the code doesn't make any sense.

Re:C++ is a manager's language... (Score:0) by Anonymous Coward on Monday February 28, @12:45AM EST (#385)

COMPUTERS ARE NOT OBJECT-ORIENTED; NEITHER SHOULD PROGRAMMING LANGUAGES BE. Do you know anything about CPU design? Once you get a level or two above logic gates, computers CERTAINLY ARE object-oriented. A register is an object. It has private data, which can be manipulated or queried with a set of well-defined operations. Ask a computer engineer to show you his design homework sometime. However, even if we agree for the sake of argument that computers are not OO, that would not mean that C++ is useless. This is because algorithms and data structures ARE object-oriented; therefore you must have some compromise between the abstract concepts you are representing and the hardware you use. C++ gives you more freedom than C to choose at which level you will make this compromise.

Re:C++ is a manager's language... (Score:0) by Anonymous Coward on Wednesday March 01, @12:25PM EST (#398)

"When I do something in C, I know pretty precisely how the computer is going to behave; when I do something in C++, I haven't a clue. I can't pass a fucking function pointer outside of an object and expect other objects to be able to execute that function . . . " You don't know how to do it because you don't really know C++. It's that simple. If you wanna know C++ you have to dump your prejudice towards anything you don't understand and actually learn it.

Re:C++ is a manager's language... (Score:1) by vand on Tuesday March 07, @07:15PM EST (#401) (User Info)

In a rant, karzan wrote "I simply don't see the point in any language that takes more than 10 pages to document." Sorry to disillusion you, but the C standard is 550 pages. Simplicity is the usual reason given to prefer C over Fortran 95 or Ada 95. The Fortran 95 standard is 406 pages (including the index). The Ada standard's pages aren't consecutively numbered, but it looks to be about 500 pages. These pages are smaller, however, than the 8.5 x 11 inch pages of the C and Fortran standards. So, by the objective but perhaps misleading metric of the number of pages in their standards, C is the most complicated among C 9x, Ada 95 or Fortran 95.

Re:C++ is a manager's language... (Score:0) by Anonymous Coward on Wednesday March 08, @12:26AM EST (#403)

And people like to point out that the Revised^4 Report on Scheme (a minimalist but powerful Lisp dialect) is shorter than the index of Steele's Common Lisp, the Language, 2nd ed.. On the gripping hand, the size of the standard libraries is pretty directly proportional to the chance you'll be able to write code that conforms to the language for a given purpose. C and C++ give you byte I/O, some locales, and math (and an enormous range of constructs having "undefined behavior"); everyone uses the preprocessor to supply a version of their code for each of the platforms they happen to know about, because writing portable code that does anything exotic is just about impossible.

C++ seen by the g77 folks... (Score:1) by gael (gqueri@mail.dotcom.fr) on Friday February 25, @05:45PM EST (#190) (User Info) http://www.multimania.com/gqueri/

seen in the g77 (GNU Fortran 77) documentation: # info -f g77 M LEX if the file contains lots of strange-looking characters, it might be APL source code; if it contains lots of parentheses, it might be Lisp source code; if it contains lots of bugs, it might be C++ source code.

It has to be said (Score:2) by tilly on Friday February 25, @06:37PM EST (#215) (User Info)

One of the most ironic things about C++ is that it has made people aware that ++C is better. Why? Because if C has a constructor, then a C++ compiler has to create a copy, and to do that it has to call the constructor on the copy made by the C++ call in case there are side-effects. Which can be expensive But ++C does not create a copy. :-) Cheers, Ben My usual seat in the cluetrain is at IWETHEY

Re:It has to be said (Score:1) by MattV (mvogt@juptech.com) on Sunday February 27, @09:01PM EST (#380) (User Info)

Should I infer from this that there is a ++C language, which does not call the C language copy constructor - yielding an improved version of C without the (almost) complete backward compatibility? Send me the URL! :)

C++ and game development (Score:0) by Anonymous Coward on Friday February 25, @07:00PM EST (#231)

Beginning with the Feb 16 entry, Brian Hook (formerly of id software fame) has some interesting discussions in his "Ask Hook" column concerning C++ in game development. http://www.voodooextreme.com/ask/ask grand.html

C++ and scientific computing (Score:1) by J. Chrysostom on Saturday February 26, @12:32AM EST (#308) (User Info)

As a soon-to-be graduate student in scientific computing, I sit and wonder sometimes why the support for mathematical and scientific computation in C++ is so limited. FORTRAN, the ugly and unmanageable beast that it is, is the only haven for computational mathematics. The good ol' F77 LAPACK is a haven for all of those who need to do matrix math. Granted, there is a f2c'd version of LAPACK for C, but it involves playing all sorts of obnoxious memory games, as F77 doesn't support dynamic memory allocation. I don't like allocating tremendous arrays to pass to FORTRAN routines for work space. C++ has nothing that comes close to an analog for LAPACK, and the standard support for less specialized computational mathematics is limited as well. The STL has no implementation for a Matrix, and its Vector implementation leaves a lot to be desired , from a mathematician's point of view. C++ can't be all things to all people, but I would love to see a serious mathematical library developed for C++. Cross linking with FORTRAN is a pain in the rear.

TNT (Score:1) by Scott McGuire on Saturday February 26, @02:34AM EST (#324) (User Info)

Does this help?

Re:TNT (Score:1) by J. Chrysostom on Saturday February 26, @03:28PM EST (#361) (User Info)

I've actually used the Template Numerical Toolkit before, and though it does have some advantages, there are still a number of drawbacks to it. The algorithms were implemented soly by Roldan Pozo, and haven't gone through the sort of review for efficiency and correctness that LAPACK has. Add to that the fact that several major matrix decompositions (like singular value decomposition) haven't been done yet.

Re:C++ and scientific computing (Score:1) by JbytheLake (patents@amazon.com) on Saturday February 26, @01:51PM EST (#356) (User Info)

Although we are getting a little off-topic here, I think that you're not 100% correct in your assertion that C++ can't handle computational mathematics. Although not a expert in this area, I know a few who are. They use C++ extensively for scientific computation at AFIT, (Air Force Institute of Technology), and could probably help you out if you wish. Hell, they even use PYTHON, to some extent, with hellish embellishments and self written library's. If you're interested, e-mail Jbythelake@yahoo.com, and I'll give you my "real" e-mail address, and link you to them. I disagree with you on one point, though, for the years invested in learning C++, OOP, and proper design and use of the intended features, I'd probably stick to FORTRAN. Although I've only used it to a limited extent in engineering applications, and by no means extensive "brain-wracking" computations, it sure seems a lot more simple to use. Does a jock itch?

Re:C++ and scientific computing (Score:1) by Axe (Axe@HATESPAM@Mindless.com) on Saturday February 26, @03:48PM EST (#363) (User Info)

Well, let's just wait for good implementations of valarray and slice... Is not it what you want? As for a mathematical libraries for C++ - here is one commercial one or other one. There are a lot of efforts in high-energy physics community to create some - take a look at CLHEP (well I know it is rudimentary..) or this one. But most of this efforts are pre-standard C++, not using the best features it has to offer (like STL). What do you want - gcc still has no implementation of even - say nothing , and that's the compiler academic comunity (around here at least) uses most. I would expect in the next few years good stable math libraries will appear. ----------------------------,

Re:C++ and scientific computing (Score:1) by Axe (Axe@HATESPAM@Mindless.com) on Saturday February 26, @03:55PM EST (#364) (User Info)

Slashdot ate my reference to "limits" and "valarray" (where I said gcc (or libstdc++) does even have an implementation of..) ----------------------------,

Re:C++ and scientific computing (Score:1) by vand on Tuesday March 07, @07:42PM EST (#402) (User Info)

J. Chrysostom wrote "The good ol' F77 LAPACK is a haven ... there is a f2c'd version of LAPACK for C, but it involves playing all sorts of obnoxious memory games, as F77 doesn't support dynamic memory allocation. I don't like allocating tremendous arrays to pass to FORTRAN routines for work space...." Are you aware that Carter is no longer president? There have been two Fortran standards since the 1977 standard. Have a look at Fortran 95. Michel Olagnon has compiled a nice set of links at http://www.rz.uni-karlsruhe.de/~Fortran90/olagnon-faq.html. To address Chrysostom's complaint more directly, dynamic storage allocation was provided in the 1990 Fortran standard. Indeed, there are separate forms to provide Java allocatable semantics when that is adequate (preferable from the optimization point of view), and something more like C pointer semantics (but without pointer arithmetic) when you need a sharper knife (with which to cut your own throat, that is).

Java still not mainstream (Score:0) by Anonymous Coward on Saturday February 26, @02:21AM EST (#322)

Where are the great Java applications which where promised years ago? For me Java still did not prove that it is mainstream. And it won't unless I see large scale open source software done with Java. Currently C is still the main choice with C++ coming way behind it on second place (If we leave out interpreted languages). I will certainly push C++ further since I just love the language. I don't care about learning a new language but the complexity of C++ in fact attracted me and will probaly make me stick to it. Sounds strange but it is true. I like Java since its very similar to C++ but not the events around it and the way it is handeled. Java is like C++ a tool and not a solution to everything. Suns claims were and are ridiculous. It is still not an approved standard and the implementations differ as much as they do in the C/C++ world.

Complexity?? (Score:1) by JbytheLake (patents@amazon.com) on Saturday February 26, @10:20AM EST (#346) (User Info)

The first language I learned was BASIC. 2nd was Cobol, 3rd Fortran, and then C++. Although I'll never be awarded a Nobel prize for my programming skills, I guess I'm a fair C++ programmer. BTW, I skipped "traditional" C altogether. Funny thing is/was that, I didn't realize that C++ was too complex to be useful, taught properly, implemted correctly, etc..etc.. until somebody told me. Too late now. C++ and (OOP for anything larger than a couple of hundred lines of code) are basically all I know. Thanks for enlightening me on the deficiency of C++. Maybe I could go back and learn C and revert to strictly procedural paradigms. Does a jock itch?

Why Linux isn't C++ oriented (Score:2) by Herbmaster on Sunday February 27, @12:29AM EST (#375) (User Info)

Innovation should focus on improvements and what works should be left as unchanged as possible. That way, people keep their existing tools and techniques and can develop from a base that is functionally complete. Also it saves the effort to re-invent the wheel and to teach "new" stuff that is equivalent to old stuff. Thus, C++ is as close to C as possible - but no closer. Or, in other words, "I strive for the mediocre." This is the Windows Way. Sure, Windows sucks (or maybe it doesn't). But in any case, it's a "base that is functionally complete" to use B.S.'s words. But Windows 2000 will be just like old windows, but it will suck less (or so they purport). The Linux Way is to find the best standard and then make the best implementation of it possible. This too is far from perfect innovation, but at the moment it seems to be working better for a lot of people. Stroustrop's attitude is what fails to challenge what needs to be. The questions should be "Is it acceptable that this is as slow as it is?" and "Does this really need to be as complicated as it is?" and "Why is it so difficult to get functionality x here?" C++ merely asks the question "What can we do with this and make it suck a little less?"

AGREED (Score:0, Informative) by Anonymous Coward on Friday February 25, @12:13PM EST (#5)

if u dont like gatez then that prob means ur a GAY COMMIE!!!! COMMIES/LINUX ZEELUTZ ARE RUINING THE COUNTRY OF AMERICA!!!!! TRoLL

Re:AGREED (Score:1) by