Books on C++ as a Multiparadigm Language

(C++ without OO overdose ;-)

Object oriented programming was invented in 1969 by Dr. Kristen Nygaard of Norway. He was trying to create a simulation model of the movement of ships passing through Norwegian fjord (a long narrow arm of the sea bordered by steep cliffs). Simulation programs usually does not separate data from the procedures and the object-oriented approach is rather natural for simulation. Natural objects can be represented by a variable (simulated time), a structure or a procedure(a ship). At the beginning there were special languages that simplified implementation of simulation programs using built-in mechanisms and special language constructs. Actually Dr. Kristen Nygaard was the co-author of one first specialized language for this domain called Simula, that was pretty popular (BTW Donald Knuth was the author of another early simulation language).

But Dr. Nygaard was the first to realize that some simulation-oriented constructs and programming tricks are useful as a general purpose programming mechanisms. That's why he decided to create a general purpose language Simula67 based on his experience with Simula. Essentially Simula 67 introduced the concept of classes into Algol, extending the concept of records (that consist exclusively of data fields) with procedures that are included in the class (member functions). This approach which allows integration of multiple procedures working with a given set of private data (namespace) similar to multientry procedures in PL/1 with slightly different syntactic sugar later was called OO programming.

Although many consider Smalltalk to be the first OO language I would say that the really the first OO-oriented language was Simula67. That means that the OO technology is 30 years old and actually is older than Unix. C++ design was greatly influenced by Simula 67.

All-in-all Simula 67 was a pretty interesting Algol extension that in addition to classes introduced into the language a very important and innovative concept of coroutines. Later this brilliant concept found its way to Modula, Icon and Python (generators) It's interesting to note that a little bit later the concept of coroutines was introduced into Unix as pipes -- probably one of the most important Unix innovations in the area of OS design. C++ inherited only one of two principal innovations introduced by Simula 67 (classes). This second innovation that stems from simulation languages in general and Simula67 specifically is absent in C++.

I can say that I do not like C++. In its design it lost simplicity and closeness to machine architecture of C and did not gain the level of scripting programming languages. I would use scripting language plus C any time instead of C++. It is difficult to program and debug language. For most problems those added complexities do not pay. So I am not surprised to see that so many major open source projects stick to C.

There are some valid reasons to use C++ over C. First of all most compilers now can compile both C and C++ so you can use both languages with the same compiler. Although many consider C++ as object oriented language (with all related to OO cult noisy and scientifically incorrect hype), the language itself does not enforce OO-style and that's a good thing. Moreover it contains some innovations that are not strictly OO-oriented. Two major among such innovations were the concepts of templates and namespaces. Namespaces permit more manageable structuring of name space and is a very important language construct of its own, related, but independent from OO.

Some OO constructs can be used non-traditionally in a pure procedural fashion. You can imitate read-only variables by using inline methods that access private variables in a class. Friends provide a decent imitation of group access to a particular subset of the name space. C++ also has lots of small improvements over C that any C programmer will be able to appreciate: strings, exceptions, more flexible O/I, being able to declare new variables anywhere, inline functions, generic programming. Funny most of them were present in PL/1 which C designers used as a prototype (PL/1 was used as a system programming language in Multics). On high end one should consider learning STL that contains a library of important algorithms.

One important advice to those who want to learn C++: you need to chose compiler wisely. Do not stick to gcc. Gcc is a good compiler, but not for novices. The quality of diagnostics leaves much to be desired. Also while analyzing the gcc source can be very educational, in the end you probably never have a compelling need to look into compiler's source code. You have at least three other choices:

• The learning version of VC6 can be bought with several books. The amount of books for VC6 exceed all other compilers. This is the mainstream compiler and sometimes it makes perfect sense to follow mainstream. Reasonable quality of diagnostic, reasonable debugger support. Good documentation. You need to apply patches from Microsoft WEB site after installing the compiler.
• High quality Borland C++ Compiler 5.5 is now free. It provides a decent diagnostic and good debugger. But this compiler has less books devoted to it then VC6.
• Intel C++ compiler is available with a non-commercial license, meaning that anyone can download and use the full compiler for non-profit work. This is the best optimizing compiler you can get. The installation of Intel compiler is far faster and easier than the installation of Visual Studio .NET. The Intel compiler scores are approximately 2.5 times better then gcc 3.2.1 for the Monte-Carlo simulation, which is a considerably larger margin than for any of the other parts of the SciMark 2.0 benchmark. For other parts it is outperforming by only small margins of 10% or less. See Benchmarking Intel C++ against GNU gcc on Linux.

Never study C++ as if it is limited to OO. OOP isn't a panacea (from the point of view of programming productivity combination of a scripting language and C, for example TCL+C or Python+C can win) and is oversold as a method of programming. Historically OO popularity was to the large extent consequence of the growth of the popularity of GUI applications, not so much by its own merits. Also catchy name is half of success in programming.

Like for a hummer everything in the world is a nail, for OO evangelists everything in the world is an object ;-). This is not true. Yes, there are cases when such a uniform vision represents a breakthrough in particular narrow area (for example Unix idea that all devices are files was a wonderful breakthrough), but you need to understand the limits of applicability to benefit from such a vision. See for example OOP Criticism (The emperor has no clothes!).

In his recent interview on Slashdot Bjarne Stroustrup wrote about OO blah-blah-blah:

"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."

At the same time object orientation was and is used as a most favorite method to kill interest in programming, as a method of abuse college students by instructors who no longer care for students ;-). Like any cult OO religion with its semi-ignorant zealots is a really bad thing. And it's really unfortunate if such a zealot is your college instructor, especially if he/she for some stupid reasons teaches OO in the first programming language course :-(. After all the main idea is to learn programming, not YASLF (Yet Another Stupid Language Fad). The best thing than can happen to you in this case is when the course actually contains C subset of the language in the first chapters like college courses based on A First Book of C++ From Here to There (a very good book). Or when the teacher (and the textbook that he/she selected) tries to teach a C++ as a better C like in C++ Primer Plus.

BTW OO religious mentality (or programming fashion, if you wish, because in programming languages fashion rules, remember all this noise about Java in 1997-1999; in reatly Java turned into a new Cobol. that's say all about the quality of the language) is now extended to another area, patterns. Some of the ideas that are presented as an ultimate achievement of this movement are valid (and actually pretty old), but they are mostly drown in the OO blah-blah-blah. For those who are over-fascinated with the this fad I strongly recommend to read Patterns of Software - Tales from the Software Community" by Richard Gabriel, one of the founding fathers of the "patterns movement". His opinion? Patterns don't gain you much, unless you're one of the snake-oil salesmen profiting by selling the idea. Here is another relevant quote from Bjarne Stroustrup (see also his famous newsgroup posting):

Rule: "Don't Try To Force People"

Programmers are smart people. They are engaged in challenging tasks and need all the help they can get from a programming language as well as from other supporting tools and techniques. Trying to seriously constrain programmers to do "only what is right" is inherently wrongheaded and will fail. Programmers will find a way around rules and restrictions they find unacceptable. The language should support a range of reasonable design and programming styles rather than try to force people into adopting a single notion.

This does not imply that all ways of programming are equally good or that C++ should try to support every kind of programming style. [...] However, moralizing over how to use the features is kept to a minimum, language mechanisms are as far as possible kept policy free, and no feature is added to or subtracted from C++ exclusively to prevent a coherent style of programming.

I am well aware that not everyone appreciates choice and variety. However, people who prefer a more restrictive environment can impose one through style rules in C++ or choose a language designed to provide the programmer with a smaller set of alternatives.

-- "The Design and Evolution of C++", page 113

There is a difference between writing 50-line programs, 3,000 line, and 30,000 lines programs... designed, developed, documented, tested, and integrated... and all along, As program grow larger writer is confronted with more software engineering problems than programming problems. For example, the problem of namespaces inevitably arises in large programming projects and here C++ has a definite an edge over C. Templates also can help in large projects.

Let me try to sum my view on C++ in the following way -- programming is cranking out a solution to a problem in the most efficient way. But premature paradigm adoption (for example, OO) like a premature optimization is the source of major problems. The programming methodology should be tuned to the problem in hand not vise-versa.

See OOP Criticism for more details.

OOP became popular primarily because of GUI interfaces. In fact, many non-programmers think that "Object" in OOP means a screen object such as a button, icon, or listbox. They often talk about drag-and-drop "objects". GUI's sold products. Anything associated with GUI's was sure to get market and sales brochure attention, regardless of whether this association was accurate or not. I have even seen salary surveys from respected survey companies that have a programming classification called "GUI/OOP Programming".

Screen objects can correspond closely with OOP objects, making them allegedly easier to manipulate in a program. We do not disagree that OOP works fairly well for GUI's, but it is now being sold as the solve-all and be-all of programming.

Some argue that OOP is still important even if not dealing directly with GUI's. In our opinion, much of the hype about OOP is faddish. OOP in itself does NOT allow programs to do things that they could not do before. OOP is more of a program organizational philosophy rather than a set of new external solutions or operations.

In his old Usenix paper Objecting To Objects Stephen C. Johnson wrote

Object-oriented programming (OOP) is an ancient (25-year-old) technology, now being pushed as the answer to all the world's programming ills. While not denying that there are advantages to OOP, I argue that it is being oversold. In particular, OOP gives little support to GUI and network support, some of the biggest software problems we face today. It is difficult to constrain relationships between objects (something SmallTalk did better than C++). Fundamentally, object reuse has much more to do with the underlying models being supported than with the object-ness of the programming language. Object-oriented languages tend to burn CPU cycles, both at compile and execution time, out of proportion to the benefits they provide. In summary, the goods things about OOP are often the information hiding and consistent underlying models which derive from clean thoughts, not linguistic cliches.

Actually if we talk about efficiency the rule is that 80% of time are spend in 20% of code and if you really care about efficiency those 20% of code should be written in a simpler more efficient language -- for C++ than means C , for C it means assembler. That's why the bible of system programmers The Art of Computer Programming by Donalds Knuth is still as important as it was 30 years ago.

As problem complexity increases, C++ become more and more viable solution although I would prefer with the combination of TCL and C, or Python and C++ to plain-vanilla C++ in many practical situations. Software engineering is about developing the solution to a complex problem in a manner that others can understand and maintain; that is not only well documented but preferably self-documented.

C+= in many ways is difficult for maintenance language, far more difficult then scripting language. And not only because it is verbose, but also because modern computers make heap allocation of variables mainstream. In many cases C++ as a higher level language (especially with STL) is good enough and is a viable choice (the quality of C++ compilers is pretty decent these days). But again the main word here is choice; if I can produce a solution in TCL+C or Python and C++ that takes at least 50% less lines of code in comparison with plain vanilla C++ I will stick with it unless there are other important considerations that can move me to C++.

At the same time C++ is less restrictive, support multiparadigm programming and can be 10 times (or more) efficient than Java :-). Like OO, Java is definitely oversold and does not provide flexibility and efficiency of the server side in comparison with C++ (at least with today's implementations of Java). It is a new Cobol (actually while Cobol was really designed with view on business application, Java was designed for imbedded systems programming). And it is as fascinating as Cobol. End of story. If you have nice hardware and not so many visitors that's OK. If this is not the case, C++ wins. And to add insult to injury C++ debuggers are generally far better then Java debuggers :-)

Dr. Nikolai Bezroukov

NEWS CONTENTS

• 20151108 : 2013 Keynote: Dan Quinlan: C++ Use in High Performance Computing Within DOE: Past and Future ( Jun 09, 2013 , YouTube )
• 20151108 : The Anti-Java Professor and the Jobless Programmers ( Nick Geoghegan )
• 20151108 : Abstraction ( nickgeoghegan.net )
• 20100822 : Beginners Guide to Linkers ( Beginner's Guide to Linkers, Aug 22, 2010 )
• 20081209 : Slashdot What Programming Language For Linux Development ( Slashdot What Programming Language For Linux Development, Dec 9, 2008 )
• 20080204 : Sunifdef 3.1.3 (Stable) by Mike Kinghan ( Sunifdef 3.1.3 (Stable), Feb 4, 2008 )
• 20071203 : Do Frameworks and APIs Limit Developers Imagination by Frank Sommers and Bill Venners ( August 20, 2007 , www.artima.com )
• 20071119 : Project details for Simplified Wrapper and Interface Generator ( freshmeat.net )
• 20071015 : On the Tension Between Object-Oriented and Generic Programming in C++ by Thomas Becker ( On the Tension Between Object-Oriented and Generic Programming in C++, Oct 15, 2007 )
• 20070910 : Visual C++ Team Blog The Future of the C++ Language ( Visual C++ Team Blog The Future of the C++ Language, Sep 10, 2007 )
• 20061215 : Computerworld - The mythical open source miracle by Neil McAllister ( Computerworld - The mythical open source miracle, Dec 15, 2006 )
• 20061126 : Dru's Blog " Error Handling - Error Codes, Exceptions and Beyond ( Dru's Blog " Error Handling - Error Codes, Exceptions and Beyond, Nov 26, 2006 )
• 20061029 : freshmeat.net Project details for doxygen ( freshmeat.net Project details for doxygen, Oct 29, 2006 )
• 20060214 : OOP Criticism by B. Jacobs. OOP criticism and OOP problems. The emperor has no clothes! Reality Check 101. Snake OOil. Updated: 5/14/2005 ( OOP Criticism, Feb 14, 2006 )

Old News ;-)

To preserve bandwidth for humans as opposed to robots News now are moved in a separate subdirectory. As with any move some of them were lost... Sorry for any inconvenience.

[Nov 08, 2015] 2013 Keynote: Dan Quinlan: C++ Use in High Performance Computing Within DOE: Past and Future

.YouTube.com: At 31 min there is an interesting slide that gives some information about the scale of system in DOE. Current system has 18,700 News system will have 50K to 500K nodes, 32 core per node (power consumption is ~15 MW equal to a small city power consumption). The cost is around $200M

Jun 09, 2013 | YouTube

watch-v=zZGYfM1iM7c

[Nov 08, 2015] The Anti-Java Professor and the Jobless Programmers

Nick Geoghegan

James Maguire's article raises some interesting questions as to why teaching Java to first year CS / IT students is a bad idea. The article mentions both Ada and Pascal – neither of which really "took off" outside of the States, with the former being used mainly by contractors of the US Dept. of Defense.

This is my own, personal, extension to the article – which I agree with – and why first year students should be taught C in first year. I'm biased though, I learned C as my first language and extensively use C or C++ in projects.

Java is a very high level language that has interesting features that make it easier for programmers. The two main points, that I like about Java, are libraries (although libraries exist for C / C++ ) and memory management.

Libraries

Libraries are fantastic. They offer an API and abstract a metric fuck tonne of work that a programmer doesn't care about. I don't care how the library works inside, just that I have a way of putting in input and getting expected output (see my post on abstraction). I've extensively used libraries, even this week, for audio codec decoding. Libraries mean not reinventing the wheel and reusing code (something students are discouraged from doing, as it's plagiarism, yet in the real world you are rewarded). Again, starting with C means that you appreciate the libraries more.

Memory Management

Managing your programs memory manually is a pain in the hole. We all know this after spending countless hours finding memory leaks in our programs. Java's inbuilt memory management tool is great – it saves me from having to do it. However, if I had have learned Java first, I would assume (for a short amount of time) that all languages managed memory for you or that all languages were shite compared to Java because they don't manage memory for you. Going from a "lesser" language like C to Java makes you appreciate the memory manager

What's so great about C?

In the context of a first language to teach students, C is perfect. C is

• Relatively simple
• Procedural
• Lacks OOP features, which confuse freshers
• Low level
• Fast
• Imperative
• Weakly typed
• Easy to get bugs

Java is a complex language that will spoil a first year student. However, as noted, CS / IT courses need to keep student retention rates high. As an example, my first year class was about 60 people, final year was 8. There are ways to keep students, possibly with other, easier, languages in the second semester of first year – so that students don't hate the subject when choosing the next years subject post exams.

Conversely, I could say that you should teach Java in first year and expand on more difficult languages like C or assembler (which should be taught side by side, in my mind) later down the line – keeping retention high in the initial years, and drilling down with each successive semester to more systems level programming.

There's a time and place for Java, which I believe is third year or final year. This will keep Java fresh in the students mind while they are going job hunting after leaving the bosom of academia. This will give them a good head start, as most companies are Java houses in Ireland.

[Nov 08, 2015] Abstraction

nickgeoghegan.net

Filed in Programming No Comments

A few things can confuse programming students, or new people to programming. One of these is abstraction.

Wikipedia says:

In computer science, abstraction is the process by which data and programs are defined with a representation similar to its meaning (semantics), while hiding away the implementation details. Abstraction tries to reduce and factor out details so that the programmer can focus on a few concepts at a time. A system can have several abstraction layers whereby different meanings and amounts of detail are exposed to the programmer. For example, low-level abstraction layers expose details of the hardware where the program is run, while high-level layers deal with the business logic of the program.

That might be a bit too wordy for some people, and not at all clear. Here's my analogy of abstraction.

Abstraction is like a car

A car has a few features that makes it unique.

• A steering wheel
• Accelerator
• Brake
• Clutch
• Transmission (Automatic or Manual)

If someone can drive a Manual transmission car, they can drive any Manual transmission car. Automatic drivers, sadly, cannot drive a Manual transmission drivers without "relearing" the car. That is an aside, we'll assume that all cars are Manual transmission cars – as is the case in Ireland for most cars.

Since I can drive my car, which is a Mitsubishi Pajero, that means that I can drive your car – a Honda Civic, Toyota Yaris, Volkswagen Passat.

All I need to know, in order to drive a car – any car – is how to use the breaks, accelerator, steering wheel, clutch and transmission. Since I already know this in my car, I can abstract away your car and it's controls.

I do not need to know the inner workings of your car in order to drive it, just the controls. I don't need to know how exactly the breaks work in your car, only that they work. I don't need to know, that your car has a turbo charger, only that when I push the accelerator, the car moves. I also don't need to know the exact revs that I should gear up or gear down (although that would be better on the engine!)

Virtually all controls are the same. Standardization means that the clutch, break and accelerator are all in the same place, regardless of the car. This means that I do not need to relearn how a car works. To me, a car is just a car, and is interchangeable with any other car.

Abstraction means not caring

As a programmer, or someone using a third party API (for example), abstraction means not caring how the inner workings of some function works – Linked list data structure, variable names inside the function, the sorting algorithm used, etc – just that I have a standard (preferable unchanging) interface to do whatever I need to do.

Abstraction can be taught of as a black box. For input, you get output. That shouldn't be the case, but often is. We need abstraction so that, as a programmer, we can concentrate on other aspects of the program – this is the corner-stone for large scale, multi developer, software projects.

[Aug 22, 2010] Beginner's Guide to Linkers

This article is intended to help C & C++ programmers understand the essentials of what the linker does. I've explained this to a number of colleagues over the years, so I decided it was time to write it down so that it's more widely available (and so that I don't have to explain it again). [Updated March 2009 to include more information on the pecularities of linking on Windows, plus some clarification on the one definition rule.]

[Dec 9, 2008] Slashdot What Programming Language For Linux Development

by dkf (304284) <[email protected]> on Saturday December 06, @07:08PM (#26016101) Homepage

C/C++ are the languages you'd want to go for. They can do *everything*, have great support, are fast etc.

Let's be honest here. C and C++ are very fast indeed if you use them well (very little can touch them; most other languages are actually implemented in terms of them) but they're also very easy to use really badly. They're genuine professional power tools: they'll do what you ask them to really quickly, even if that is just to spin on the spot chopping peoples' legs off. Care required!

If you use a higher-level language (I prefer Tcl, but you might prefer Python, Perl, Ruby, Lua, Rexx, awk, bash, etc. - the list is huge) then you probably won't go as fast. But unless you're very good at C/C++ you'll go acceptably fast at a much earlier calendar date. It's just easier for most people to be productive in higher-level languages. Well, unless you're doing something where you have to be incredibly close to the metal like a device driver, but even then it's best to keep the amount of low-level code small and to try to get to use high-level things as soon as you can.

One technique that is used quite a bit, especially by really experienced developers, is to split the program up into components that are then glued together. You can then write the components in a low-level language if necessary, but use the far superior gluing capabilities of a high-level language effectively. I know many people are very productive doing this.

[Feb 4, 2008] Sunifdef 3.1.3 (Stable) by Mike Kinghan

About: Sunifdef is a command line tool for eliminating superfluous preprocessor clutter from C and C++ source files. It is a more powerful successor to the FreeBSD 'unifdef' tool. Sunifdef is most useful to developers of constantly evolving products with large code bases, where preprocessor conditionals are used to configure the feature sets, APIs or implementations of different releases. In these environments, the code base steadily accumulates #ifdef-pollution as transient configuration options become obsolete. Sunifdef can largely automate the recurrent task of purging redundant #if logic from the code.

Changes: Six bugs are fixed in this release. Five of these fixes tackle longstanding defects of sunifdef's parsing and evaluation of integer constants, a niche that has received little scrutiny since the tool branched from unifdef. This version provides robust parsing of hex, decimal, and octal numerals and arithmetic on them. However, sunifdef still evaluates all integer constants as ints and performs signed integer arithmetic upon them. This falls short of emulating the C preprocessor's arithmetic in limit cases, which is an unfixed defect.

[Dec 3, 2007] Do Frameworks and APIs Limit Developers' Imagination by Frank Sommers and Bill Venners

August 20, 2007 | www.artima.com

Summary

Readily available frameworks and APIs can make developers very productive. However, they can also limit developers' imagination, explains Overstock.com principal software engineer Chris Maki in this brief audio interview with Artima.

One of Java's key strengths today is its multitude of APIs and frameworks, addressing a wide range of problem domains. Such APIs and frameworks provide ready-made answers to many programming problems. Indeed, programming in Java today is to a great extent an exercise in learning to identify and use APIs and frameworks suited to a problem area.

Using readily available APIs and frameworks can keep a developer at a fairly high level of abstraction: Part of a Java developer's productivity comes from not having to reinvent the wheel with every project-instead, a developer can apply high-level frameworks to a set of similar projects and problems, expecting generally high-quality results.

While productivity is very important in a developer's work, so is originality and innovation. In a conversation at JavaOne earlier this year, Chris Maki, a principal software engineer at Overstock.com and leader of the Utah Java Users Group, told us that the frameworks and APIs that make us so productive also impose upon us their design decisions and their solutions to problems, sometimes leaving little room for innovation and originality:

When I first started as a software engineer... we used to think that anything you could think of, that anything you could conceive of, was possible with software, and that the sky was the limit. And we tried to do that. Today, it seems like we look at the Java APIs and the different packages, and say, "Well, this is all we can do. This is what the APIs tell us."

Back in those days, we were doing more typical client-server type applications. We would have a database, and most of the logic was in what we would call a fat client today. In the graphical or presentation layer, we would [use] animations... One of the applications I was working on was a pipeline application, which doesn't sound very sexy or interesting, yet as data moved through the pipeline, we used animations to show pictures of the different places the product would go, have [part of the UI] fade in and fade out... to visualize this movement of data...

If I was going to do that in Java [today], it would seem to me like a daunting task, given the complexities of some of the Swing APIs. I know that they made a lot of improvements, but when I sit down to do an app today, I don't think [that] whatever I can think of I'm going to do. I typically think the APIs and the design patterns tell me I've got to do this [or that]. While we made a lot of improvements by having cross-platform code, and write once, deploy anywhere kind of things, we've also limited our thinking.

Chris Maki, principal software engineer at Overstock.com, talks about how frameworks and APIs can limit developers' imaginations. (3 minutes 10 seconds)

To what extent do you think there is a role for the in-the-trenches enterprise developer to devise innovative and out-of-the-box solutions? In your projects, how do you mitigate the need for productivity that comes from following the prescriptions of a high-level framework, and the desire to come up with original and sometimes surprising, solutions?

[Nov 19, 2007] Project details for Simplified Wrapper and Interface Generator

freshmeat.net

SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages. SWIG is primarily used with common scripting languages such as Perl, PHP, Python, Tcl/Tk, and Ruby, however the list of supported languages also includes non-scripting languages such as C#, Common Lisp (CLISP, Allegro CL, UFFI), Java, Modula-3, OCAML, and R. Also several interpreted and compiled Scheme implementations (Guile, MzScheme, Chicken) are supported. SWIG is most commonly used to create high-level interpreted or compiled programming environments, user interfaces, and as a tool for testing and prototyping C/C++ software. SWIG can also export its parse tree in the form of XML and Lisp s-expressions.

Release focus: Minor feature enhancements

Changes:
shared_ptr support was added for Java and C#. STL support for Ruby was enhanced. Windows support for R was added. A long-standing memory leak in the PHP module was fixed. Numerous fixes and minor enhancements were made for Allegrocl, C#, cffi, Chicken, Guile, Java, Lua, Ocaml, Perl, PHP, Python, Ruby, and Tcl. Warning support was improved.

[Oct 15, 2007] On the Tension Between Object-Oriented and Generic Programming in C++ by Thomas Becker

The author discusses how the use of generic programming in C++ can lead to conflicts with object-oriented design principles. He demonstrates how a technique known as type erasure can often be used to resolve these conflicts. An in-depth example is presented: any_iterator, a type-safe, heterogeneous C++ iterator.

In his glossary of terms[1], Bjarne Stroustrup has described the C++ programming language that he created as "a general-purpose programming language [...] that supports procedural programming, data abstraction, object-oriented programming, and generic programming." The fact that C++ supports these different programming paradigms makes it unique-and uniquely powerful-among today's programming languages. On the other hand, it should not come as a surprise that the close coexistence of such vastly different paradigms can cause considerable friction, especially in large software systems.

In this article, I will focus on the tension that can occur when object-oriented programming (classes, objects, and runtime polymorphism come to mind) meets generic programming (algorithms, templates, and compile time polymorphism come to mind).

The article consists of two parts. In the first part, I will demonstrate how the coexistence of OO and generic programming can cause serious friction in real-life software engineering. I will then explain how a technique known as type erasure can be used to alleviate these problems.

The second part explains how type erasure can be implemented in C++. Specifically, I will elaborate on an example used in the first part, namely, C++ iterator type erasure. I will discuss the design and implementation of a class template[2] any_iterator that provides type erasure for C++ iterators.

The Trouble with Object-Oriented and Generic Programming

A Little Trivia Quiz

Let us start with a little trivia quiz. Who said the following things about object-oriented programming?

• "I find OOP technically unsound."
• "I find OOP philosophically unsound."
• "I find OOP methodologically wrong."
• "I have yet to see an interesting piece of code that comes from these OO people."
• "I think that object orientedness is almost as much of a hoax as artificial intelligence."

All the quotes above are from an interview with Alexander Stepanov[3], the inventor of the STL and elder statesman of generic programming. As a practicing software engineer who works on large commercial software projects, I know better than to hold such a negative view of OO programming. But when someone like Alexander Stepanov says such a thing, then I don't think it should be taken lightly.

My experience as a software engineer in the trenches has taught me that there is much more tension, if not contradiction or incompatibility, between OO programming and generic programming than many people care to admit. It is easy to dismiss Alexander Stepanov's rejection of OO programming as extreme and unrealistic. It is much harder to make the OO and generic programming paradigms coexist and cooperate in real-life software engineering.

In the next three sections, I will illustrate the problem with an example from the real world, and I will suggest a less radical remedy than to disavow OO programming as a tool in software design altogether.

[Sep 10, 2007] Visual C++ Team Blog The Future of the C++ Language

Hello, world! Today, I (Stephan T. Lavavej, library dev) would like to present one question and one Orcas bugfix.

First, the question: What is the future of C++? Or, phrased crudely, does C++ have a future? Will it grow and evolve, with programmers using it in new application domains and finding ways to use it more effectively? Or will it stagnate, with programmers using it in fewer and fewer application domains until nothing new is being invented with it and it enters "maintenance mode" forever? After C++'s explosive growth over nearly the last three decades, what is going to come next?

This question has a finite horizon. No language can possibly be eternal, right? (Although C is certainly making a good run for it.) I don't expect C++ to be vibrant in 2107, or even 2057. 50 years is an almost incomprehensible span of time in the computer industry; the transistor itself is turning 60 years old this year. So when I ask, "what is the future of C++?", I'm really asking about the next 10, 20, and 30 years.

Here's how I see it. First, consider C++'s past. As it happens, Bjarne Stroustrup recently released an excellent paper covering C++'s recent history, "Evolving a language in and for the real world: C++ 1991-2006", at http://research.att.com/~bs/hopl-almost-final.pdf . There's also a wonderful 1995 interview with Alexander Stepanov at http://stepanovpapers.com/drdobbs-interview.html which explains C++'s machine model.

C++'s machine model has a relentless focus on performance, for several reasons. Being derived from C, which was "fat free", is one reason - in the realm of performance, C++ has never had to lose weight. It's just had to avoid gaining weight. Additions to C++ have always been structured in such a way as to be implementable in a maximally efficient manner, and to avoid imposing costs on programmers who don't ask for them. (As the Technical Report on C++ Performance, now publicly available at http://standards.iso.org/ittf/PubliclyAvailableStandards/c043351_ISO_IEC_TR_18015_2006(E).zip , explains, exception handling can be implemented with the "table" approach, which imposes minimal run-time overhead on code that doesn't actually throw. VC uses the "code" approach on x86 because of historical reasons, although it uses the "table" approach on x64 and IA-64.) Historically, C++ ran on very small and slow machines that couldn't bear any unnecessary costs. And now, C++ is used to tackle huge problems where performance is critical, so unnecessary costs are still unthinkable!

Aside from the elevator controllers and supercomputers, does performance still matter for ordinary desktops and servers? Oh yes. Processors have finally hit a brick wall, as our Herb Sutter explained in 2005 at http://gotw.ca/publications/concurrency-ddj.htm . The hardware people, who do magical things with silicon, have encountered engineering limitations that have prevented consumer processors from steadily rising in frequency as they have since the beginning of time. Although our processors aren't getting any slower, they're also not getting massively faster anymore (at least, barring some incredible breakthrough). And anyways, there isn't plenty of room at the bottom anymore. Our circuits are incredibly close to the atomic level, and atoms aren't getting any smaller. The engineering limit to frequency has simply arrived before the physical limit to circuitry. Caches will continue to get larger for the foreseeable future, which is nice, but having a cache that's twice as large isn't as nice as running everything at twice the frequency.

As programmers, we are faced with a future that looks radically different from what we're used to: the processors we have today are about as fast as we will ever have. The computer industry undergoes constant change, of course, but we rather liked the kind of change that made our programs run twice as fast every couple of years with no extra work on our part.

Undaunted, the hardware engineers have begun putting multiple cores in each processor, which is actually increasing overall performance quite nicely. (I'd sure like to have a quad-core machine at work!) But not everything is as embarrassingly parallel as compiling. Single-core performance still matters. And the problems that we, as programmers, are asked to solve are getting bigger every year, as they always have.

Therefore, I say that C++ is uniquely positioned to weather this performance storm. Other languages will continue to find uses in application domains that aren't performance-critical, or that are embarrassingly parallel. But whenever the speed at which an individual core crunches stuff matters, C++ will be there. (For example, 3D games. When Halo Infinity is released in 2027 - and yes, I totally just made that up - I fully expect it to be written in C++.)

Among C++0x's biggest core language changes will be variadic templates, concepts, and rvalue references. The first two will make writing templates a lot more fun. That's great, because templates are a powerful way to produce highly efficient code. And the third will address one of the flabbiest areas in C++03 - its tendency to make copies of values. (Things that have value semantics are great - unnecessary copies aren't.) By eliminating unnecessary copies through "move semantics", rvalue references will make value-heavy code, like any code that uses the STL, significantly faster. The future is bright!

[Dec 15, 2006] Computerworld - The mythical open source miracle by Neil McAllister

Actually Spolsky does not understand the role of scripting languages. But hi is right of target with his critique of OO. Object oriented programming is no silver bullet.

Dec 14, 2006 (InfoWorld) Joel Spolsky is one of our most celebrated pundits on the practice of software development, and he's full of terrific insight. In a recent blog post, he decries the fallacy of "Lego programming" -- the all-too-common assumption that sophisticated new tools will make writing applications as easy as snapping together children's toys. It simply isn't so, he says -- despite the fact that people have been claiming it for decades -- because the most important work in software development happens before a single line of code is written.

By way of support, Spolsky reminds us of a quote from the most celebrated pundit of an earlier generation of developers. In his 1987 essay "No Silver Bullet," Frederick P. Brooks wrote, "The essence of a software entity is a construct of interlocking concepts ... I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation ... If this is true, building software will always be hard. There is inherently no silver bullet."

As Spolsky points out, in the 20 years since Brooks wrote "No Silver Bullet," countless products have reached the market heralded as the silver bullet for effortless software development. Similarly, in the 30 years since Brooks published " The Mythical Man-Month" -- in which, among other things, he debunks the fallacy that if one programmer can do a job in ten months, ten programmers can do the same job in one month -- product managers have continued to buy into various methodologies and tricks that claim to make running software projects as easy as stacking Lego bricks.

Don't you believe it. If, as Brooks wrote, the hard part of software development is the initial design, then no amount of radical workflows or agile development methods will get a struggling project out the door, any more than the latest GUI rapid-development toolkit will.

And neither will open source. Too often, commercial software companies decide to turn over their orphaned software to "the community" -- if such a thing exists -- in the naive belief that open source will be a miracle cure to get a flagging project back on track. This is just another fallacy, as history demonstrates.

In 1998, Netscape released the source code to its Mozilla browser to the public to much fanfare, but only lukewarm response from developers. As it turned out, the Mozilla source was much too complex and of too poor quality for developers outside Netscape to understand it. As Jamie Zawinski recounts, the resulting decision to rewrite the browser's rendering engine from scratch derailed the project anywhere from six to ten months.

This is a classic example of the fallacy of the mythical man-month. The problem with the Mozilla code was poor design, not lack of an able workforce. Throwing more bodies at the project didn't necessarily help; it may have even hindered it. And while implementing a community development process may have allowed Netscape to sidestep its own internal management problems, it was certainly no silver bullet for success.

The key to developing good software the first time around is doing the hard work at the beginning: good design, and rigorous testing of that design. Fail that, and you've got no choice but to take the hard road. As Brooks observed all those years ago, successful software will never be easy. No amount of open source process will change that, and to think otherwise is just more Lego-programming nonsense.

[Nov 26, 2006] Dru's Blog " Error Handling - Error Codes, Exceptions and Beyond

About 10 months ago, I was writing a library. As I was writing it, I started to look at the whole issue of notifying the caller of errors. In typical fashion, I tried to optimize the error handling problem rather than just do the right thing, and just use error codes. I did a ton of research. Here is a current list of links and articles on the subject.

Getting Started

To get you started here are some good starting points. They both received a lot of attention on the internet.

A colorful post by Damien Katz.

A nice opinion piece that is pro-error codes by the famous Joel of Joel on Software.

Read my original post with excellent comments by Daniel Lyons, Paul Clegg, and Neville of the North.

Nutshell

The default and standard way of handling errors since the begining is to just use error codes with some convention of noticing them. For example, you could document the error condition with an api and then set a global variable for the actual code. It is up to the programmer calling the function to notice the error and do the right thing.

This is the technique used by operating systems and most libraries. Historically, these systems have never been consistent or compatable with other conventions. The most evolved system for this would probably be the Microsoft COM system. All functions return an HRESULT, which is essentially an error code.

The next system was the 'exception-handling' system. In this system errors cannot be ingored. Exception handlers are declared, optionally, at a given scope. If an exception is thrown (ie an error has occurred), handlers are searched up the stack until a matching handler is found.

IMHO, the exception system isn't used properly in 90% of the cases. There is a fine balance between a soft error and something exceptional. The syntax also tends to get in the way for even the simplest of errors. I agree that there should be errors that are not ignored, but there has to be a better way.

So, old skoolers are 'we use error codes, and we like them, dammit - aka, super disciplined programming, usually for real-time, embedded and smaller systems.

The new schoolers are, 'you have to be kidding about error-codes, use exceptions' - aks, yeah, we use exceptions, that is what the language gives us… and btw, no, we don't mind typing on our keyboards a lot

Somehow, there has to be a better way. Maybe it will be system or application, specific.

Moving On - Old / New Ideas

If you don't mind it being a C++ article, here is an amazing one from Andrei Alexandrescu and Petru Marginean. (Andrei is widely known for his great work on Policy Based design with C++, which is excellent) The artcle is well written and practical. In fact, the idea was so good, the language 'D' made it part of the language.

Here is an example:

void User::AddFriend(User& newFriend)
{
    friends_.push_back(&newFriend);
    try
    {
        pDB_->AddFriend(GetName(), newFriend.GetName());
    }
    catch (...)
    {
        friends_.pop_back();
        throw;
    }
}

10 lines, and this is for the super-simple example.

void User::AddFriend(User& newFriend)
{
    friends_.push_back(&newFriend);
    ScopeGuard guard = MakeObjGuard(friends_, &UserCont::pop_back);
    pDB_->AddFriend(GetName(), newFriend.GetName());
    guard.Dismiss();
}

In D it would look even cleaner:

void User::AddFriend(User& newFriend)
{
    friends_.push_back(&newFriend);
    scope(failure) friends_.pop_back();
    pDB_->AddFriend(GetName(), newFriend.GetName());
}

IMHO, I think exception handling will move more towards systems like this. Higher level, simpler and cleaner.

Other interesting systems are the ones developed for Common Lisp, Erlang, and Smalltalk. I'm sure Haskell has something to say about this as well.

The Common Lisp and Smalltalk ones are similar. Instead of forcing a mechanism like most exception handlers. These systems give the exception 'catcher' the choice of retry'ing or doing something different at the point of the exception. Very powerful.

Speaking of smalltalk, here is an excellent article called Subsystem Exception Handling in Smalltalk. I highly recommend it.

My Recomendation

If you are building a library, use error codes. Error codes are much easier to turn into exceptions by the language wrapper that will eventually be built on top.

When programming, don't get trapped into think about the little picture. A lot of these errors are just pawns in the grand scheme of assuring that you have all of your resources in place before you begin your task at hand. If you present your code in that manner, it will be much easier to understand for all parties.

More Links

Error Codes vs. Exceptions by Damien Katz.

opinion piece that is pro-error codes by the famous Joel of Joel on Software.

Read my original post with excellent comments by Daniel Lyons, Paul Clegg, and Neville of the North.

Microsoft COM

D Language - Exception Safe Programming

Subsystem Exception Handling in Smalltalk - nice section on history as well

http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html

A nice long thread on comp.lang.c++.moderated

*Slightly Wacky, But Neat *

http://www.halfbakery.com/idea/C20exception20handling_20macros http://www.nicemice.net/cexcept/ http://home.rochester.rr.com/bigbyofrocny/GEF/ http://www.on-time.com/ddj0011.htm

[Oct 29, 2006] freshmeat.net Project details for doxygen

doxygen 1.5.1 by Dimitri van Heesch - Sun, Oct 29th 2006 11:00 PDT About: Doxygen is a cross-platform, JavaDoc-like documentation system for C++, C, Objective-C, C#, Java, IDL, Python, and PHP. Doxygen can be used to generate an on-line class browser (in HTML) and/or an off-line reference manual (in LaTeX or RTF) from a set of source files. Doxygen can also be configured to extract the code-structure from undocumented source files. This includes dependency graphs, class diagrams and hyperlinked source code. This type of information can be very useful to quickly find your way in large source distributions. Changes: This release fixes a number of bugs that could cause it to crash under certain conditions or produce invalid output.

[Feb 14, 2006] OOP Criticism Object Oriented Programming Oversold by B. Jacobs. OOP criticism and OOP problems. The emperor has no clothes! Reality Check 101. Snake OOil. Updated: 5/14/2005

I am not saying OOP is useless, per se; many are just frustrated with the fact that OOP has slowed or even reversed programming progress in other areas. I have debated OO fans that appear ignorant to some nifty techniques available in old-fashioned procedural programming. Often times someone will compare C to C++ and conclude that the differences are paradigm differences.

... ... ...

OOP is the greatest boon for those who like to write bloated code. I am not saying that all OOP code is bloated. But, something or someone is encouraging the practice of taking the most amount of code to do the fewest things. Further, OOP has added new ways to write bloated code that procedural has a hard time competing with. Hypothetical example for adding two numbers:

... ... ...

OOP sometimes takes credit for ideas that are not necessarily part of OOP. For example, some criticize the variable scoping rules of procedural languages, saying that OOP improved it. However, some procedural languages like Pascal already allowed multiple levels of variable and procedure scoping before OOP became a mainstream fad.

Having variable parameter types and quantities has been part of many interpreted procedural languages a good time before OOP became a mainstream fad. For example, in XBase you can use the Type() function to query a parameter type. (It lacked formality, but it was there.)

Summary

It is hard to summarize such a complex, involved topic; but here goes an attempt anyhow. Most problems with OOP can be summed up in a handful of general principles.

1. The real world does not change in a hierarchical way for the most part. You can force a hierarchical classification onto many things, but you cannot force change requests to cleanly fit your hierarchy. Just because a structure is conceptually simple does not necessarily mean it is also change-friendly.

2. There are multiple orthogonal aspect grouping candidates and the ones favored by OOP are probably not the best in many or most cases. OO literature is famous for only showing changes that benefit the aspects favored by OO. In the real world, changes come in many aspects, not just those favored or emphasized by OO. Encapsulating by just a single dimension is often a can of worms.

3. OOP's granularity of grouping and separation is often larger than actual changes and variations. OOP's alleged solutions to this, such as micro-methods and micro-classes, create code management headaches and other problems.

4. OOP designs tend to reinvent the database in application code. In particular, OO generally reinvents navigational databases, which were generally rejected in the 1970's and replaced by relational techniques. It is my opinion that relational theory is generally superior to navigational theory. It can provide more structure, cleaner queries, and automated optimization. Plus, the usage of databases allows multiple tools and languages to share and use data without writing explicit access methods for each new request.

5. There is no decent, objective, and open evidence that OOP is better. It may just all be subjective or domain-specific. Software engineering is sorely lacking good metrics.

6. There is a large lack of consistency in OO business design methodologies. Procedural/relational approaches tend to be more consistent in my experience. (Group code by task, and use database to model noun structures and relations.)

7. Many of the past sins that OOP is trying to fix are people and management issues (incentives, training, etc.), and not the fault of the paradigms involved. Until true A.I. comes along, no paradigm will force good code. If anything, OOP simply offers more ways to screw up.

OOP Myths Debunked:

• Myth: OOP is a proven general-purpose technique
• Myth: OOP models the real world better
• Myth: OOP makes programming more visual
• Myth: OOP makes programming easier and faster
• Myth: OOP eliminates the "complexity" of "case" or "switch" statements
• Myth: OOP reduces the number of places that require changing
• Myth: OOP increases reuse (recycling of code)
• Myth: Most things fit nicely into hierarchical taxonomies
• Myth: Sub-typing is a stable way to model differences
• Myth: Self-handling nouns are more useful than self-handling verbs
• Myth: Most operations have one natural "primary noun"
• Myth: OOP does automatic garbage-collection better
• Myth: Procedural cannot do components well
• Myth: OO databases can better store large, multimedia data
• Myth: OODBMS are overall faster than RDBMS
• Myth: OOP better hides persistence mechanisms
• Myth: C and Pascal are the best procedural can get
• Myth: SQL is the best relational language
• Myth: OOP would have prevented more Y2K problems
• Myth: OOP "does patterns" better
• Myth: Only OOP can "protect data"
• Myth: Implementation changes significantly more often than interfaces
• Myth: Procedural/Relational ties field types and sizes to the code more
• Myth: Procedural cannot extend compiled portions very well
• Myth: No procedural language can re-compile at the routine level
• Myth: Procedural/Relational programs cannot "factor" as well
• Myth: OOP models human thought better (Which human?)
• Myth: OOP is more "modular"
• Myth: OOP divides up work better
• Myth: OOP "hides complexity" better
• Myth: OOP better models spoken language
• Myth: OOP is "better abstraction"
• Myth: OOP reduces "coupling"
• Myth: OOP does multi-tasking better
• Myth: OOP scales better
• Myth: OOP is more "event driven"
• Myth: Most programmers prefer OOP
• Myth: OOP manages behavior better

[Feb 14, 2006] Free Microsoft compilers

• Get a Free Copy of Visual Studio 2005 Express Editions
  Download a copy of Visual Studio 2005 Express Editions today – easy to use tools for the hobbyist, novice and student developer.
• Visual C++ Toolkit 2003 The Microsoft Visual C++ Toolkit 2003 includes the core tools developers need to compile and link C++-based applications for Windows and the .NET Common Language Runtime – compiler, linker, libraries, and sample code.

Recommended Links

Softpanorama Recommended

Top articles

Sites

Generally search engines are the only way to keep up in this area. So links below are just a small sample that I have found useful.

• **** The C++ section of the open directory project.
• **** CodeGuru - Visual C++
  • Visual Studio Macros - Table of Contents
• **** DDJ C++ section
• **** Thinking in C++ second edition. Nice free e-book. More reference then tutorial
• **** Brad Appleton's C++ Links
• **** Cetus Links 13403 Links on Objects and Components
• **** Sites of interest to C++ users by Robert Davies
• Free C - C++ Compilers and Interpreters (thefreecountry.com)
• Favorite Source Code Links --C/C++ Journal. Very good
• C++ Links by Michael Ciaccio
• C++ Resources
• C & C++ Resources
• C/C++ links
• Programming style
• Association of C & C++ Users WWW
• The Unofficial C++ Homepage
• Yahoo Links - Computers & Internet, Lang, C++
• Nerd World - PROGRAMMING
• VSL - Master Site
• Classification Society of North America
• Cliff's Teaching Info and Technical Resources