C++ is downright stagnant. I still have the same problems now that I had 10 years ago. STL was great, but it was a long time coming.

If I was on the committee, I'd pick something and work on it. I feel that nothing's been done other than STL since the birth of C++. Why is that? It may not be true, but I know I'm not alone in this sentiment. Pick something, anything. There are now different implementations of STL because it's in the standard. Why have other areas been left in the dark? Even a recommended interface, even if flawed, can be improved upon, but would greatly help in reducing the insane number of #ifdef's required just to use the language.

I'm not dissing the committee. I just think if they pushed forward as ntrif has said, then things would get moving (one would hope). BTW, the public can only keep suggesting what they want. And keep repeating them. That's what we're here for. The committee has to decide. No need to feel the obligation to respond if certain issues have already come up. I'm sure most everything has already been thought up at some point anyways. Sure, hearing the same thing over and over gets frustrating, but that's the way it has to be.

I'm just getting worried because at the point where the computing field is right now, we're in desperate need of better tools and no one seems to know in what direction to go. This isn't just C++, but all languages. I think this could be a great opportunity for C++ if taken advantage.

In other words, she argues that if you want it, you can do it as a library solution

But the library solution has several drawbacks:

1) it introduces a memory overhead: the extra fields needed inside property objects.
2) it introduces a compiler overhead: the compiler should compile all the code for each instantation of the property template.
3) it introduces a programmer's overhead: it is quite easy to forget 'initializing' a property member with the proper pointers, especially if a class gets changed a lot.

A language change has several costs, even for "perfect" features (i.e. ones that don't break backwards compatibility), such as cost of making a proper specification, compiler or library implementation, education, etc.

I agree, but some of the proposed things are quite simple to implement, especially if the relevant thing has been done in other languages. Take properties, for example: C# has a very good implementation on properties. A real good base to start from. It is just not logical to have to wait 10 years to get properties.

if people like yourself (who want these things) participate in the language development, we could probably have had done more, by now.

Where do I sign up???

I think these new features are ok but we need libraries for network, serialization, inter-process communication, xml, data-base, threads...

I couldn't agree more. These libraries are long overdue. C++ is being abandoned in favor of Java, due to Java having a way much more complete SDK.

I don't think garbage collector is needed at all.

It is badly needed, but it should be an option. In most large projects, a great deal of effort is spent chasing pointers.

I think that breaks C++ constructor/destructor model (when are the destructors called?)

Why does it matter when destructors are called? when using garbage collection, destructors become almost irrelevant for heap allocated objects. After all, C++ has RAII, which is a much better way to release resources than any destructor.

and that new smart pointers can avoid nearly all manual memory management

No, smart pointers are not that good. First of all, they are much slower than GC; secondly, you can not use smart pointers in situations with circular references, and that rules out a lot of data structures.

And memory is not the only resource you have to manage, so I don't know if garbage collector overhead is justified.

One of the best things in C++ is RAII...and that's because C++ allows objects to live on the stack. When asking for garbage collection, I do not mean that stack based allocation should be abolished.

I think C++ has a bright future

In my company (more than 30 programmers), I am the only one that knows and supports C++. There are some other guys that knew C++, but have abandoned it...and having participated in Java projects, I can tell you that development with Java is waaay faster than C++...in fact, experienced programmers usually get the code right in their first try, something that is much less feasible in C++...and there is much less headaches with Java on finding libraries.

That done, try putting yourself in the shoes of the committee and decide how to proceed.

It's easy: implement all the proposals. They are not that many or that difficult to implement anyway.

Until template typedefs are available, there is a work-around which can confer some of the benefits:

template <class T> struct aliases {
   typedef vector<T, My_alloc<T> > vec;
};

aliases::vec<double> v;

This can also be a useful way to isolate the dependency of a program on the particulars of the library it uses.

For example, the g++ standard library provides a hash map in the __gnu_cxx namespace that you access through the header file <ext/hash_map> . If you care about program portability, you don't want to type "__gnu_cxx::hash_map" or "#include <ext/hash_map>" more than once.

Suppose you are writing a C++ program and need hash tables that always take strings as key values. We gather the necessary typedefs in the struct shmap (short for "string hash map").

Putting this in the header file string_hash.h:

#include <ext/hash_map>

using std::string;

struct string_hasher_op {
   size_t operator()(const string &s) const {
      int n= s.size();
      size_t x1=0;
      for (int i=0; i<n; i++){
         x1= 31*x1 + s[i];
      }
      return x1;
   }
};

struct string_hasher_eql_op {
   bool operator()(const string &a, const string &b){
      return a==b;
   }
};

template<class T> class shmap {
public:
   typedef __gnu_cxx::hash_map<string,T,string_hasher_op,string_hasher_eql_op> map;
   typedef typename map::const_iterator cit;
   typedef typename map::iterator it;
};

You could then use it like this:

#include <iostream>
#include <string>
#include "string_hash.h"

using std::cout;
using std::endl;
using std::string;

int main(void){
   shmap<int>::map map;
   map["a"]= 1;
   map["b"]= 2;
   map["c"]= 3;
   for (shmap<int>::it p= map.begin(); p!=map.end(); p++)
      cout << "m[" << p->first << "]=" << p->second << endl;
}

> I can tell you that
> development with Java is waaay faster than C++...

Having worked with Java (not much) and C# (way too much), I can only say that my experience is quite the opposite. Developing with C++ was both faster and less frustrating.

> Until template typedefs are available, there is a
> work-around which can confer some of the benefits:
>
> template <class T> struct aliases {
> typedef vector<T, My_alloc<T> > vec;
> };
>
> aliases::vec<double> v;

The use would be:

aliases<double>::vec v;

but otherwise, it'll work.

Note that, unlike real template aliases (and except for the syntax difference), the above won't allow template parameter deduction:

template<class T>
void f(aliases<T>::vec v);

f(aliases<double>::vec()); // Error: T can't be deduced

However, with the alias:

template<class T>
using vec = vector<T,My_alloc<T>>;

template<class T>
void f(vec<T> v);

f(vec<double>()); // Ok

> This can also be a useful way to isolate the dependency of
> a program on the particulars of the library it uses.
>
> For example, the g++ standard library provides a hash map
> in the __gnu_cxx namespace that you access through the
> header file <ext/hash_map> . If you care about program
> portability, you don't want to type "__gnu_cxx::hash_map"
> or "#include <ext/hash_map>" more than once.
>
> Suppose you are writing a C++ program and need hash tables
> that always take strings as key values. We gather the
> necessary typedefs in the struct shmap (short for "string
> hash map").
>
> Putting this in the header file string_hash.h:
>
> #include <ext/hash_map>
>
> using std::string;

I wouldn't put a using-declaration in a header-file... (at least in the global namespace) That would make it have effect on any subsequent includes, too.

> struct string_hasher_op {
> size_t operator()(const string &s) const {
> int n= s.size();
> size_t x1=0;
> for (int i=0; i<n; i++){
> x1= 31*x1 + s[i];
> }
> return x1;
> }
> };
>
> struct string_hasher_eql_op {
> bool operator()(const string &a, const string &b){
> return a==b;
> }
> };
>
> template<class T> class shmap {
> public:
> typedef
> def __gnu_cxx::hash_map<string,T,string_hasher_op,string_hasher
> _eql_op> map;
> typedef typename map::const_iterator cit;
> typedef typename map::iterator it;
> };
>
> You could then use it like this:
>
> #include <iostream>
> #include <string>
> #include "string_hash.h"
>
> using std::cout;
> using std::endl;
> using std::string;
>
> int main(void){
> shmap<int>::map map;
> map["a"]= 1;
> map["b"]= 2;
> map["c"]= 3;
> for (shmap<int>::it p= map.begin(); p!=map.end(); p++)
> cout << "m[" << p->first << "]=" << p->second <<
> ond << endl;
> }

I'd think that it's things like this that namespaces were meant for, and it would be a shame if we couldn't use them for it. How about (simplified example using just one template parameter):

// ext/hash_map.h

namespace __gnu_cxx
{
template<class T>
class hash_map { ... };
}

// some_other_map.h

namespace some_other
{
template<class T>
class hash_map { ... };
}

// my_map.h

#include <ext/hash_map> // or <some_other_map.h>

namespace my
{
using __gnu_cxx::hash_map; // or some_other::hash_map
}

my::hash_map<double> test;

Of course, this requires that the name and parameters of the map is the same (which it may not be, and in that case, you may need some kind of adapter/wrapper, anyway).

Oops, since you bind some template parameters (not just want to be able to select between versions in different namespaces), my example wasn't really a full replacement to your example, and therefore wasn't very relevant in this case.

> But the library solution has several drawbacks:
>
> In other words, she argues that if you want it, you can
> do it as a library solution
>
> But the library solution has several drawbacks:
>
> 1) it introduces a memory overhead: the extra fields
> needed inside property objects.

Not necessarily so. For what I call Internal Properties, the member field being represented by the property is contained within it, so there is no overhead. For what I call External Properties, there is a maximum 1-byte (+packing, if any) overhead for _all_ properties within a class. For example, in the current alpha version of XMLSTL, the node class for the MXSML mapping is 8 bytes: 4 for the IXMLDOMNode pointer, and 1 byte (+3 packing) for the property overhead for 23 properties.

As I mentioned in a previous post, most compilers inline all the harness code, making it fully runtime efficient.

> 2) it introduces a compiler overhead: the compiler should
> compile all the code for each instantation of the property
> template.

And the big deal with that is? Or, rather, this is a particular problem because? There're plenty of examples where template handling costs compile time.

(Actually, I must fess up and concede that the C++ Properties technique has required one compiler - Digital Mars C++ - to go through a bug fix recently, to avoid an unwelcome ICE. But most compilers support it admirably, and with the stated efficiencies: CodeWarrior 8, Comeau 4.3.3, Digital Mars 8.46+, GCC 3.4+, Intel 6+, VC++ 7.1+)


> 3) it introduces a programmer's overhead: it is quite easy
> to forget 'initializing' a property member with the proper
> pointers, especially if a class gets changed a lot.

My implementation naturally avoids such a risky strategy. Everything is automatic.

It's clear you've not read Ch 35 of Imperfect C++. Maybe now's the time to get hold of a copy. ;-)

> I think these new features are ok but we need libraries
> for network, serialization, inter-process communication,
> xml, data-base, threads...
>
> I couldn't agree more. These libraries are long overdue.
> C++ is being abandoned in favor of Java, due to Java
> having a way much more complete SDK.

Perhaps you'll be interested in checking out XMLSTL when I release the alpha in a few weeks. I plan to post a note on the Artima forum, if you keep an eye out there, or anywhere else you might recommend. (I'm currently spending most of my time working on volume 1 of my next book, Extended STL, which, I believe, does a pretty good job of showing just how much can be achieved within the current definition of the language, given a little thought and more than a little effort. <g>)

> if people like yourself (who want these things)
> participate in the language development, we could probably
> have had done more, by now.
>
> Where do I sign up???

Sean Kelly and I are about to put forward the first (and simplest: it requires nothing of compilers / library beyond C++-98) of what we hope may be several proposals to the C++ standard, as soon as we can work out how one goes about it. Any pointers?

Cheers

Matthew

> I don't think garbage collector is needed at all.
>
> It is badly needed, but it should be an option. In most
> large projects, a great deal of effort is spent chasing
> pointers.
>
> I think that breaks C++ constructor/destructor model
> (when are the destructors called?)
>
> Why does it matter when destructors are called? when using
> garbage collection, destructors become almost irrelevant
> for heap allocated objects. After all, C++ has RAII, which
> is a much better way to release resources than any
> destructor.

Well, RAII uses the destructor to release resources. And if I create an object via new that allocates resources (opens a communication, opens a file, or any other thing) I want to destroy it when I want because I want to close the file. Otherwise I have to close it by hand, and that's very error prone.

> and that new smart pointers can avoid nearly all manual
> memory management
>
> No, smart pointers are not that good. First of all, they
> are much slower than GC; secondly, you can not use smart
> pointers in situations with circular references, and that
> rules out a lot of data structures.

¿Much slower than GC? A lot of GC are based also on shared_ptr/weak_ptr scheme. And the language has to trigger the GC to start looking freeable objects. The difference is that I KNOW what is the cost of shared_ptr (atomic increment for every copy) and I can avoid those copies if in my code that's critical. The problem with GC is that I don't know what's going on. I agree that perhaps GC is very useful and productive, but since I'm used to manage memory by hand, I don't find memory allocation is a productive burden. And I DO think that almost all manual allocation can be avoided, when move semantics are added to the language + smart pointers. But manual does not mean that I lose control over allocation, I know what I'm doing, it's just I'm avoiding typing and avoiding usual errors. That's because I know what std::string does, what std::vector does, what std::shared_ptr does and most importantly I know WHEN.

Now imagine another resource: shared memory, a file, a communication device... There is no garbage collector for this. You have to close the file, you have to release shared memory, you have to close the device. And there is no GC collecting open files to close them. Memory is just another resource that in C++ I can control uniformly using RAII, destructors or another scheme.

> And memory is not the only resource you have to manage,
> so I don't know if garbage collector overhead is
> justified.
>
> One of the best things in C++ is RAII...and that's because
> C++ allows objects to live on the stack. When asking for
> garbage collection, I do not mean that stack based
> allocation should be abolished.

In my experience with languages with garbage collectors usually the perfomance is worse and the memory use, higher. Many times happens the same with manual management. But there is a difference in C++: I know what's happening. And I think that I can do it better than the GC (I'm not joking). Maybe some starter or medium programmers produces less buggier programs with GC, but when you know when memory is being allocated, and what the language is doing with every statement, no GC can't beat that.

For example: Java has garbage collector. I really think that you can do efficient programs in Java. But that isn't the norm. You just have to know where the performance win is. But since GC is going its own way, in another thread, enters when it wants (or in a low priority thread) you can't control that. You don't know if assigning a variable is allocating heap memory (and even less when is releasing it). Is not about features, it's about control. That's way every Java program I try needs huge memory quantities. And that really annoys me, because your program is not alone in the computer. If every program uses that much memory we could only start 10 processes in a computer. We are not alone in the world, and our application is not the only one running in the computer.

I'm not talking about benchmarks. Just take a text processor, a P2P client, a browser. Every Java program I use gets me sick because of the huge amount of resources it needs. There are unefficient C++ programs, but I can always find an efficient alternative. It's not about the programming language. I repeat: I'm sure you can program efficiently in Java. It's a problem of programmers. It's a problem of control. You know what's happening behind the curtains. You don't pay for you don't use. If you don't think about allocations, you lose control. And your program suffers, because memory allocation is not free. Maybe you will be more productive (but I doubt it if you are an experienced C++ programmer), and that can be fine in many areas, but not in others.

> I think C++ has a bright future
>
> In my company (more than 30 programmers), I am the only
> one that knows and supports C++. There are some other guys
> that knew C++, but have abandoned it...and having
> participated in Java projects, I can tell you that
> development with Java is waaay faster than C++...in fact,
> experienced programmers usually get the code right in
> their first try, something that is much less feasible in
> C++...and there is much less headaches with Java on
> finding libraries.

In my company everyone compiles in C++. Everyone. Some come from Java world. It's because we don't do web applications? Maybe yes. But we have programmers that can do web applications and program also embedded processors, using just a single language: C++. And do it efficienly. And some universities around here who changed from C++ to Java are now teaching C++ again, because they feel that students can't understand some basic programming concepts with Java.

We just need libraries. LOTS of them. That's the difference with Java/.NET. And I think we are doing great efforts with Boost.

> If I was on the committee, I'd pick something and work on
> it.

Feel free. Details on the WG21 site. There you'll also find all the current proposals, complete with longish discussion/analysis papers. My "wish lists" on my C++ page will give you a brief summary of what people have asked for and this discussion should also provide a few dozen ideas. On my publications page, you can find a few of the papers that I have authored or co-authored.

Here is a brief list of currently active topics

concepts (a type system for template arguments)
auto/decltype
memory model (to support concurrency)
threads libraries
nullptr
improved enumerations (or opaque types)
file system library
module system
reducing the number of "undefined behaviours"
initializer lists
control of default class behaviours
generalized constant expressions
support for dynamically linked libraries
arbitrary precision arithmetic
more C99 compatibility
static assertions
move semanics
simple compile-time reflection
class namespaces
local classes as template parameters

(that's just a sampling - to be sure consult the WG21 site)

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

PS Please don't complain that not enough is being done unless you have yourself contributed what you can. The ISO C++ standard process is a volunteer effort; not a well financed corporate effort with an associated marketing machine.

Since ISO standards are put on a 10-year upgrade track, what does the committee do after a standard is put out? I know that erratta is corrected, etc. Does the committee immediately begin work on the next decade of changes? Is there really that much work to be done?

> PS Please don't complain that not enough is being done
> unless you have yourself contributed what you can. The ISO
> C++ standard process is a volunteer effort; not a well
> financed corporate effort with an associated marketing machine.


How do you see the process for addressing problems/issues C++ users have with C++ language? Especially when there is no "well financed corporate effort" as in Java or C#, where scores of people are paid to listen to user problems and make language/libraries better.





Some of that was addressed in your post on January 4 and it is important to me to comment on that. You wrote:

BS> The standards process is open and - believe it or not -
BS> cheap compared to other processes defining our world.

I do not think that standard process is sufficently open. Two issues come to mind immediately:

1. A lot of committee discussions take place on the mailing lists not available to general public.
2. The community might not even know what is happening, because the information is not easily accessible.

I think this illustrates the problem very well:

Q: How do I get to main Python web site?
A: http://www.python.org

Q: How do I get to main C++ one?
A. Is there one? May be you should got to the commitee site. http://google.com, then search for WG21, then choose first link in the results.

BS> However, the investment for an individual is mostly time
BS> (weeks a year) and - if you want to vote - $800 a year."

I hope you are not saying that to affect the situation the only sensible choice C++ user have is to spend $800+travel expenses a year and weeks of his time as a member of the committee. I believe that this is just too much to expect.

I also think that we need to make sure that C++ development doesn't depend on availability of enthusiasts willing to sacrifice their personal time, money and energy.

> I also think that we need to make sure that C++
> development doesn't depend on availability of enthusiasts
> willing to sacrifice their personal time, money and energy.

This situation can be both an advantage and disadvantage: No one party/company controls the development of C++ - it's nonproprietary, but it also means there's no specific funding source. However, C++ shares this with many other languages (such as Perl, Python, PHP, etc.). However, unlike them, it's an ISO standard, meaning there's neither a BDFL, either.

> I think that the greatest strength of "other languages" is
> not that they are better languages, but that they come
> with larger collections of "free" libraries.

I agree, the large collections of free libraries are a major attraction of other languages, but this does beg the question: why are there fewer freely available C++ libraries? After all, C++ has been around longer than many of these languages.

Are C++ programmers less generous (I don't think so, but maybe participating in the standardisation effort exhausts their generosity), do they find it easier to make money from any libraries they write (certainly C++ is in demand), or is it simply harder to write good general purpose portable libraries in C++? Certainly it's harder to distribute prebuilt C++ libraries.

Of course, C++ works well with C and can make use of C libs. This enables programmers to get the job done, but it won't help them improve their C++ skills. Contrast this with e.g. Python, where the standard libraries are not only useful but also fine examples of how to use the language.

Boost is the leading supplier of free C++ libraries, but these libraries are often relentlessly modern C++ -- meaning they may not be suitable for use on some platforms (due to poor compiler support), and on other platforms a simple user mistake yields frightening compiler output.

The C++ standard library itself has lagged behind the core language and still suffers from the lack of a definitive online reference. Yes, there are some excellent sites (e.g. msdn) but all too often I need to refer to the ISO standard, which was not written with user-friendliness in mind.

> PS Please don't complain that not enough is being done
> unless you have yourself contributed what you can. The ISO
> C++ standard process is a volunteer effort; not a well
> financed corporate effort with an associated marketing
> machine.

I was under impression that compiler vendors are active members of the C++ standard comitee. Maybe we should send our complaints to them? After all, some of us are paying for our C++ compilers.

One way or another, I really believe it is important to move faster if we don't want C++ to become another COBOL. Just read first posts at this discussion at Code Project (which used to be a C++ community just a couple of years ago, and now it is mostly a C# place):
http://www.codeproject.com/lounge.asp?msg=1323694&mode=all&userid=14112#xx1323694xx

And again, please don't take this as disrespect: I am grateful for the work you have done and believe C++ is the best general purpose programming language today. It is just not realistic to expect all 3 million C++ programmers to take part in the standard process: most of us are simply not qualified for that. Personaly, I have no expertize at making compilers at all, and the kind of libraries I work on (natural language processing) are definitely not candidates for the Standard Library.

> The use would be:
>
> aliases<double>::vec v;
>
> but otherwise, it'll work.

Oops!

> I wouldn't put a using-declaration in a header-file... (at
> least in the global namespace) That would make it have
> effect on any subsequent includes, too.

Yes, I agree the natural thing to do is wrap the shmap delcaration inside a namespace, which is exactly what I did when I first wrote it. For posing here, however, I was trying to make the example as short as possible, and I decided the presence of the namespace would complicate the point I was trying to illustrate (the operation of the template typedef workaround).

I've only been actively using C++ for about 2 years and I remember only too well how confusing some of its syntax can be. What I really needed when I was trying to crack it was complete, executable, and short examples showing how each language feature operated.

While I think "The C++ Programming Language" is a great book in many ways, Mr. Stoustrup's use of code fragments to illustrate his points, and his lack of complete executable example code, made it hard for me to use it for learning the language.

Once I was comfortable with the language, however, I found his book delightful.