Matthew:

> ... despite being a member of the Ed Panel
> of The C++ Source, and having mentioned such to, and
> requested pointers from, my fellow panel members (several
> of whom are on the C++ standards committees), I am still
> largely in the dark as to how to go about putting forward
> proposals. I know that I need to make some mention on
> std.lang.c++ and to follow the instructions at
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n18
> 10.html, but beyond that it's still pretty opaque to this
> little pixie. Will my submission be immediately
> disseminated to panel members?

I believe that any committee member would do that if you sent them an email asking them to. Unless the proposal looked solid (see the document you quote), they might suggest that you do some more work and talk with other people before forwarding it to the committee.

The most typical problem I see with proposals sent to me is that they fail to consider alternatives. Often, you have to consider several quite different ways of achieving similar results. An example would be garbage collection: Someone might propose a conservative scheme, a precise scheme, a smart-pointer based approach, or an approach based on language restrictions. No proposal will get very far unless there is a discussion of the general alternatives in addition to a mass of details about the preferred scheme. Just deeming significantly different schemes "braindead" won't do much good. They may be so, but the committee will want to know exactly how they are :-) remember, there will be people on the committee with a dramatically different background from you and a dramatically different mix of application areas as their main concern.


> Will it be dropped in the
> bit-bucket because I cannot attend a standardization
> committee meeting myself? (A previous post on this thread
> intimated that the members are pretty much full up on
> extant proposals, and are therefore unlikely to be able to
> sponsor any new ones ...)

That's a real problem. You know what happens to successful C++ programmers? They get overloaded.


> Do I need to join the committee
> (assuming they'd have me .. LOL)? Do I have to stump up
> $800?

You don't *need* to join the committee, but if you don't you somehow have to convince someone else to spend significant time working with you on a proposal and to spend the time presenting and discussing it at the face-to-face meetings.

And yes, if you want to join the committee, you have to pay unless you can demonstrate some quite unusual reason not to. The ISO is not very forgiving about money and some of the national bodies are worse. More or less informally joining up with some people who are local (in some sense) to you may be a good first step. Various nations have discussion groups (e.g. France, Germany, and the UK).

-- Bjarne Stroustrup; http://www.research.att.com/~bs

> And yes, if you want to join the committee, you have to
> pay unless you can demonstrate some quite unusual reason
> not to. The ISO is not very forgiving about money and some
> of the national bodies are worse. More or less informally
> joining up with some people who are local (in some sense)
> to you may be a good first step. Various nations have
> discussion groups (e.g. France, Germany, and the UK).

Just to comment on this: Not all national bodies require member fees. For example the UK one has free membership. I assume BSI (UK's national body) pays ISO to participate, but membership of the BSI C++ Panel (BSI's delegate to WG21) is free. (Normally, you have to be UK citizen to join, but I got an offer to join the panel, as Norway is not active in the committee, and they knew me through my participation in ACCU. The same is the case for a couple of others, like Thorsten Ottoson, who lived in Australia for a while).

For those who may wonder about the organisation of ISO: As I understand, the members of ISO are countries, and ISO is made up of the so-called "national bodies" in these countries - each country has an organization associated with ISO - in UK, it's BSI, etc. Delegates of these national bodies constitute WG21 at standards meetings.

However, again, as I understand, you don't need to be a member of a national body to participate at WG21 meetings, as according to ISO rules, anyone can attend (space permitting). The exception is the last day, when voting is done, where only members can vote. I couldn't stay for the voting at Lillehammer, but I think it's just the Head of Delegation who votes on behalf of their country, anyway, so individual membership may not matter that much in this case. However, being a member of a national body gives you access to the commitee's mailing lists, but as such, they may be considered (where you pay membership fees) pricey lists... :)

I hope Mr. Stroustrup will correct any errors in this.

> Do I need to join the committee
> (assuming they'd have me .. LOL)?

LOL, :) for one thing, there's no entry-test to join a national body, and furthermore, from what I've seen of your writing, you're well qualified to participate, had there been one.

I took the weekend off, so this is an answer to a question several pages ago (well, a couple of pages ago).

/* I haven't looked at Cay's books for a long time so I don't have an opinion. That allows me to ask an open-ended question: What makes a good C++ textbook? For which target audience? Why?
*/

I really got lucky with Cay's book, in that I went to the closest community college and bought whatever they were using. When I had a little knowledge under my belt, and saw what else was out there, I realized that I had dodged a serious bullet.

I like Cay because he doesn't teach C first. IIRC (as I sold my book, and every so often I regret it), there was discussion about arrays, but the examples start using std::vector in Chapter 2 or 3. You learn how to use libraries, and you learn OOP principles several chapters before learning how to write classes. Then there were small asides about Therac, a misplaced break in AT&T's code, and why using a Social Security Number as a unique ID is a bad idea.

I fit in the target audience of somebody who used BASIC and LOGO in elementary school, picked up a Perl CGI book and said "I wonder what C's like." To be honest, I was a little upset that the community college didn't have a C textbook. Of course today I can read C code, but I don't feel all that comfortable willingly keeping to structs and functions.

/* IMO one of the biggest problems with C++ is that it is so often mistaught ...
*/

I have to agree. However, I have to say that overloading in the syntax is another large problem. I understand why '&' means "address-of," "reference" and "bitwise-and," or why "const" can appear in several different spots on a line to mean "make the pointer const," "make the target of the pointer const," "this method doesn't change the object's state," etc. There are several compiler vendors, and getting them to go along with changes must be murder. That, and picking good keywords that aren't already used as variables has got to be hard.

And going to the other extreme (of adding a couple of new keywords for every new cocpets -- as Perl has done) certainly isn't attractive either. However, I would like a textbook to bring this point up. It took me a few times through "The C++ Programming Language" before I really had a solid grasp of why some of the syntax looked almost familiar, and why I kept falling into the same syntactic traps.

/* Typically, the problem is not that there is no solution. Most often the problem is that there are many.
*/

This reminds me of Larry Wall's "State of the Onion" statement:

/* So I'm just wondering if we're getting ourselves into a similar situation with open source software. More software is not always better software. Google notwithstanding, I think it's actually getting harder and harder over time to find that nugget you're looking for. This process of re-inventing the wheel makes better wheels, but we're running the risk of getting buried under a lot of half-built wheels.

And there are two take-home lessons from that. The first is that, as an open source author, you should be quick to try to make someone else's half-built wheel better, and slow to try to make your own (http://www.perl.com/pub/a/2005/09/22/onion.html?page=10).
*/

/* For knowing which objects are collectable, the solution is quite easy: an custom operator new places the allocated block in a linked list. Correspondingly, an custom operator delete removes the block from that list by erasing the block's iterator (stored before the block) from the linked list (i.e. removal takes constant time). The linked list is allocated as thread local storage, so as that there is no synchronization involved.
*/

I was thinking about something like this over the weekend. But then I started wondering if it qualified as an STL allocator, specifically that requirement that the allocator not keep certain per-object information so that swap can be optimized.

> /* For knowing which objects are collectable, the solution
> is quite easy: an custom operator new places
> the allocated block in a linked list. Correspondingly, an
> custom operator delete removes the block from
> that list by erasing the block's iterator (stored before
> the block) from the linked list (i.e. removal takes
> constant time). The linked list is allocated as thread
> local storage, so as that there is no synchronization
> involved.
> */
>
> I was thinking about something like this over the weekend.
> But then I started wondering if it qualified as an STL
> L allocator, specifically that requirement that the
> allocator not keep certain per-object information so that
> swap can be optimized.

This appears to be a case where the one-object limitation would not be a burden: You don't often want several garbage collectors. The problem would be that you might not want all of your collected objects in a container and (worse) if you ever created a real pointer to such an object the scheme would fail. I think ideas in this direction are probably better considered under the heading of smart pointers or special allocation pools.

For me at least, such a scheme would not serve where I actually want GC, because that's typically in situations where I feel that undiciplined use of resources is inevitable so that I need an all-emcompassing scheme to cope with the resulting mess.

-- Bjarne Stroustrup; http://www.research.att.com/~bs

Sorry for following up on myself, but could I have a quick poll? Please make at most three suggestions for C++0x. For each, give a max two lines of explanation of what is wanted and max two lines of explanation why it is wanted. For example:

concepts
what: a type system for types for use with template argument
why: to get better error messages and better overloading of templates

Try to really make it your first choices. Imagine you could get at most those three and no other. Don't be afraid to repeat other people's wishes. Please be specific; that is, don't make suggestions that are generalized to be whole categories of extensions, such as "better support for generic programming". Please give suggestions in order of preference.

-- Bjarne Stroustrup; http://www.research.att.com/~bs

May I suggest you post this poll announcement as a separate entry, maybe into your artima weblog? Buried like it is in a seven day discussion log, it might not get as much attention as possible.

> The problem would be that you might
> not want all of your collected objects in a container and

But all garbage collectors maintain a collection of allocated blocks, as just as all memory allocators maintain such a collection. Without such a collection, how would you know where your objects are?

> (worse) if you ever created a real pointer to such an
> object the scheme would fail.

I don't think so (if I have understood correctly).

First of all, the per-thread container of objects is not destroyed until a) the thread that owns it finishes and b) until the container is empty.

Secondly, having a real pointer to such an object is not a problem, as long as there is another pointer to the object known to the collector. And my proposal was about having a special pointer class that pushes itself in a pointer stack that is thread-specific. You can't do better for GC than that unless you go in a lower level.

>
> For me at least, such a scheme would not serve where I
> actually want GC, because that's typically in situations
> where I feel that undiciplined use of resources is
> inevitable so that I need an all-emcompassing scheme to
> cope with the resulting mess.

I agree, and that situation arises sooner or later in a C++ program, for the average programmer, especially if there are lots of changes and no clear design. What I know from talking to people is that they want to avoid thinking; some people that studied CS got out of it due to the complexity of programming...some others prefer other programming languages than C++, due to C++ being too complex for their tastes.

> Sorry for following up on myself, but could I have a quick
> poll? Please make at most three suggestions for C++0x. For
> each, give a max two lines of explanation of what is
> wanted and max two lines of explanation why it is wanted.
> For example:
>
> concepts
> what: a type system for types for use with template
> late argument
> why: to get better error messages and better
> tter overloading of templates
>

For now I will post only one: garbage collection

what: we all know what it is about, don't we?

why: it will simplifies programming by relieving the programmer from memory tracking issues, allowing him/her to concetrate on the problem at hand

> Sorry for following up on myself, but could I have a quick
> poll? Please make at most three suggestions for C++0x. For
> each, give a max two lines of explanation of what is
> wanted and max two lines of explanation why it is wanted.

1. Module/component system
what: language support for building components and modules
why: to enable making C++ components in a portable way

2. Lambda expressions
what: (informally) unnamed functions
why: reduce the amount of code and possibility for errors by applying STL algorithms instead of loops

3. Move semantics
what: ability to "move" objects rather than copy them
why: improved performance especially when dealing with containers.

> > Sorry for following up on myself, but could I have a
> quick
> > poll? Please make at most three suggestions for C++0x.
> For
> > each, give a max two lines of explanation of what is
> > wanted and max two lines of explanation why it is
> wanted.
>
> For now I will post only one: garbage collection
>
> what: we all know what it is about, don't we?
>
> why: it will simplifies programming by relieving the
> programmer from memory tracking issues, allowing him/her
> to concetrate on the problem at hand

Such as optimising the program, due to the effect of the garbage collector? :)

Sorry, I couldn't resist. :) As mentioned in another posting, garbage collection doesn't _remove_ the problem of resource management, only _changes_ it, with different "gotchas", and it only handles memory, which doesn't necessarily make resource management easier, and could make it harder.

However, as this is a suggestion for an _optional_ feature (and your posting wasn't intended to restart that discussion, I guess), then using it is at least voluntary.

Moreover, I've heard that, for some scenarios, GC may be faster than reference counting (some call the latter a kind of GC, anyway, but with GC, here, I mean a "traditional" one, such as no support for destructors), such as in a multithreaded system, due to locking issues (the reference count may need to be locked for each copy made, or at least the use of atomic instructions).

-> threads/interprocess communication

what: tools for multi-processing multi-threading: thread/process launch, mutex, condition variables, read-write locks, pipes, message queues, shared memory, memory mapped files. STL containers in shared memory/memory mapped files.

why: One of the biggest gaps in C++. We can't launch an application/thread in C++ in a standard way and communicate with other processes/threads. Basic building blocks for every real-world system. Benefits: Responsiveness, huge performance improvements, easier programming and scalability.

-> network

what: tools for network programming. Support for synchronous and asynchronous network programming.

why: One of the biggest gaps in C++. We can't communicate with other computers in a standard way. Network is present in every aspect of our lifes and is a high performance application suitable for C++.

-> move semantics/rvalue reference

what: possibility to assign the resources of one object to another, instead of copying the resources.

why: Huge performance benefits, specially in STL containers and algorithms. Perfect forwarding. Avoiding many manual memory allocations with no perfomance loss. Containers of noncopyable objects.

I actually have some more requests, so please allow me to post again.

1) garbage collection.
what: we all know what it is about, don't we?.
why: it will simplifies programming by relieving the programmer from memory tracking issues, allowing him/her to concetrate on the problem at hand.

2) pass-by-name semantics.
what: to be able to invoke functions by passing parameters by name.
why: it simplifies writing constructors for classes with lots of options; it simplifies calling functions with lots of parameters.

3) tuples as first class values.
what: to be able to handle composite literals, i.e. expression lists surrounded by curly brackets, as first class entities.
why: it will solve the problem of sequence constructors, as well as provide a way to declare composite values in a structured manner, similar to S-expressions.

Let me expand on my third request a little.

It is impossible, for now, to do the following in C++:

vector < Object* > objects = {new Object1, new Object2, new Object3};

If the expression within the curly brackets was a first-class entity, then we could write the vector constructor like this:

template < class T > class vector {
public:
    template < tuple T1 > vector( const T1 &values ) {
        for(int i = 0; i < lengthof(T1); i++) {
            push_back(values[i]);
        }
    }
}

The operator [] could be used for indexing of a tuple's members. Arrays are homogeneous tuples after all.

Tuples as first class entities will also allow us to do declarative programming. For example, a GUI dialog could be declared as a series of nested tuples. If coupled with pass-by-name, it could make our life much easier for many things. Example:

Dialog dialog1 = Dialog(text = "my dialog", {
    Row({Label(text="name:"), TextBox()}),
    Row({Label(text="password:"), TextBox(password = true)}),
    Row({Button(text = "ok", click = signal(dialog1, Dialog::ok)), Button(text = "cancel", click = signal(dialog1, Dialog::cancel))})
});

Or an HTML page:

HTML page1 = {
    BeginH1(),
    Text("Hello world"),
    EndH1(),
    Row({List({"A", "B", "C"}), Table({1, 2, 3})}),
};

The above code, when executed, would actually process the tuple 'page1' and produce a string buffer with the appropriate HTML.

Tuples themselves could be templates, parameterized over the type of their content. A 'tuple' declaration without template parameters is a generic tuple; a 'tuple' declaration with parameters could only accept a literal that reflects the structure of the tuple. Examples:

//any tuple
tuple

//variable length tuple of integers
tuple < int, ... < int > >

//tuple of an integer and a string
tuple < int, const char * >

Tuple types will be like template constraints: a type system for tuples. It will allow compiler validation of declarative forms.