Lambda the Ultimate

C++, with the STL, has quite a lot to offer, too.

Other languages suffer. For example, Ada - a language born for resue - dosn't come with a rich enough standard library.

• They seem to ignore the complexity of the language when wondering why libraries aren't more popular (imho that complexity - which forces "programming conventions" - stops libraries from working well together unless you lock in to one supplier)

• In general, there seems to be a need for guidance on conventions (look at all the effective C++ books etc). Does it really need to be such an "open" language? Especially as it seems (the impression I get from the talk) to be slipping from a general language to one for systems programming.

• No-one mentioned GC until the very last question, and then the response only extended to this. Don't they understand that no-one in their right mind wants to manage memory after using a high level language? Not even when it's hidden as much as possible by conventions and smart pointers.

• People seemed very impressed by ACE (a big emphasis on distributed computing).

• Stroustrup seemed quite content to hit a compiler error "once or twice a week" ("doesn't warp the design").

• This book was mentioned; looks interesting (modulo usual rider about things supported in other languages looking new and important just because they are complex in C++).

I think the Ada approach (sotrage pools) is an interesting compromise. I am not sure how useful it really is, but it is worth checking out.

ACE is indeed impressive. Some of the papers on the site are well worth reading. The ACE mailing lists are mirrored on the comp.soft-sys.ace newsgroup. I got some assignment ideas from the ACE patterns.

More later...

I am more intrigued by different ways of abstracting memory access. The STL does this (I gave links to Stepanov inteviews where he discusses this). Another approach, obviously, is smart points. Ada storage pools are a nice idea. More extreme, perhaps, are things like tied variables in Perl.

I am very much interested in ways that allow you to change this aspect of your programs, without changing code. Examples of use are making variables persistent, and using special kinds of memory (e.g., shared memory, or things like OS/390 data spaces).

#include <stdio.h>

struct A { int a; A(int _a): a(_a) {} };
struct B: public A { int b; B(int _a) : A(_a), b(1) {} };

void problem(A& ap, A a) { ap = a; }

int main(void) {
   B b (5); A a (0);
   //b = a;
   problem(b,a);
   printf("\nResult: %d %d\n", b.a, b.b);
   return 0; }

Assignment "b=a;" if written explicitly is rightfully forbidden. However, executing problem(b,a); has the same effect as the above assignment. The compiler issues no warning. Java has the same problem. However, executing problem(b,a); in Java will cause a run-time exception. In C++, no exception will be generated. The code will finish "normally". There are other holes in C++ type system, related, for example, to multiple inheritance.

Eiffel when first introduced has an unsound type system as well (related to covariance of methods). The unsoundness has hurt the language. C++ has managed to get away with far bigger holes. Maybe because it's a language of a C family, which tries to be as accepting as an assembler. C++ also follows the NJ school of thought on error handling: if it is too hard, leave it to the user (and to the authors of numerous "effective" books and style guides).

It will be nice if a new version of C++ had fewer holes.

I do recall that not too long ago there was a movement in Europe to establish a standard for a simpler C++. Bjarne was quite vocal in his dislike of that prospect and threw his weight behind stopping it in it's track. I don't think simplification or a push towards elegance is in the cards for C++.

From a programming language development perspective, STL is definitely the best part of C++. Still, I don't think of it as so much a sophisticated application library, as much as it is a building block to produce applications.

Not sure the memory mangement angle is what interests me

Me neither. I'd compare it to drinking water - I'm happy with whatever comes out of the tap, providing it doesn't kill me. I know that some people prefer it with little bubbles, or in ice-blue transparent plastic bottles from the supermarket, and that's fine by me, but all I want is something safe and without too bad a taste. When you find yourself in a country where you can't drink the tap water it's a drag and you wonder why, in this day and age, they can't get their act together.

Same with C++ and GC.

Of course there are niche applications where the type of GC matters, and it's no doubt fascinating to think up different ways to provide it. But the Kuroshin article that Chris pointed to today describes C++ as "one of the most popular application development languages currently in use" - that application development not device drivers, kernels, or time/space critical systems (and even then - Lisp Machines were Lisp all the way down and they seemed to work).

I'm convinced there are a lot of people out there who'd appreciate some kind of vanilla GC (free, standard, easy to use) that saved them from having to worry about leaks. If it can be provided by a library, fine. If it needs some small language extensions - why not make them?

Microsoft have done just this (of course). Using C++ on .NET you can surrender memory management to the system (at least, that's my impression from that confernece I went to; in exchange there were some things you couldn't do, which seemed fair enough). OTOH, since no-one seems to mention this maybe it's evidence that I'm wrong, and people really do like to debug memory leaks...

I suspect a lot of this is connected with the strange obsession programmers seem to have with "efficiency" (unrelated example from work last week: "(Java) inner classes are more efficient"(!?!)). But that's another rant. OK, no more on this from me! :-)

# Assignment "b=a;" if written explicitly is rightfully forbidden. However, executing problem(b,a); has the same effect as the above assignment. The compiler issues no warning.
i don't see where the pb is. This is record subtyping...

Your "problem" is equivalent to:

void problem(A &ap, A a) { ap.a = a.a; }

since the default operator= just copies the struct fields.

# Java has the same problem. However, executing problem(b,a); in Java will cause
i tried reproducing with java, but i can't see how to reproduce:

public class main {
    public class A { int a; };
    public class B extends A { int b; };


    public static void subtype_assign(A ap, A a) { ap = a; }


    public static void main(String args[]) {
        A a = new A(); a.a = 1;
        B b = new B(); b.a = 2; b.b = 3;


        subtype_assign(b, a);
        System.out.println("Result: " + b.a + " " + b.b);
    }
}

after "ap = a", "ap" doesn't point to the object passed as argument... i'm not good enough in java to find out what is the java way

It's far more dangerous that that. Let's consider a simple variation of the previous example:

#include <stdio.h>
struct A {
    int a;
    A(int _a): a(_a) {}
};
struct B: public A {
    int b;
    B(int _a, int _b) : A(_a), b(_b) {}
};

void problem(A * ap, A a) { ap[1] = a; }

int main(void) {
    A a (12345);
    B ba [] = { B(5,9) };
    printf("\nBefore the 'assignment': %d %d\n", ba[0].a, ba[0].b);
    problem(ba,a);
    printf("\nAfter the 'assignment': %d %d\n", ba[0].a, ba[0].b);
    return 0;
}

The output:

Before the 'assignment': 5 9
After the 'assignment': 5 12345

Note that ba[0].a remained the same but ba[0].b (which is particular to class B and is not present in class A) all of the sudden changed! Again, the compiler issued not a single warning, and the program finished "normally."

http://marshall-cline.home.att.net/cpp-faq-lite/proper-inheritance.html#[21.4] gives a similar example, which however, will end in a Segmentation fault.

http://c2.com/cgi/wiki?ArraysBreakTypeSafety shows a Java version. In Java the invalid assignment triggers a run-time exception.

anyway i now get the pb, and the solution which is: use Vector!

the java case is worse of course :-(

# One last example which we use in our OO/C++ training courses: "A Bag-of-Apple is not a kind-of Bag-of-Fruit." If a Bag-of-Apple could be passed as a Bag-of-Fruit, someone could put a Banana into the Bag, even though it is supposed to only contain Apples!
this is true iff the object are not const:

int subtype_get(const vector<A> &ap, int i) { return ap[i].a; }


vector<B> bs;
subtype_get(bs, 1);

should work, uh?

Precisely! Mutations and polymorphism is an insidiously dangerous combination. I heard a story that ML once treated reference cells (which can be mutated) somewhat nonchalantly. Then somebody showed a subversive example. It prompted research and deliberation, which resulted in a set of constraints that restore soundness of the type system. The constraints can be checked at compile-time.

http://caml.inria.fr/FAQ/FAQ_EXPERT-eng.html#polymorphisme

Thus it _is_ possible to avoid setting traps for a programmer. If the designers of a language are serious about creating a safe language, they can indeed accomplish a great deal.