> Sorry for following up on myself, but could I have a quick
> poll? Please make at most three suggestions for C++0x.

1. Support for modules
what: language support for modules as described in WG21/1778 or similar
why: solve, please, the problem with order of dynamic initialization of non-local entities at last.

2. Standard way for specifying character encoding of source file.

what: standard #pragma or another mechanism.
For example:
#pragma meta(encoding="windows-1251") // encoding name as registered in IANA

why: Better internationalization support.

3. class/struct/union namespaces as described in SC22/WG21/1420 or similar
what: let consider code example:
namespace Implementation
{
class Foo
{
class Rep
{
typedef int& TReference;
TReference f();
// and much more members
}
};
}

Current style for out of class implementation:
inline
Implementation::Foo::Rep::TReference Implementation::Foo::Rep::f()
{ /* */ }

Easy and simple, you are sure?. But do not forgot about template members of template class with template template parameters!!!

Proposal:
class namespace Implementation::Foo::Rep
{
inline TReference f() {/* */}
// another members implementation
}

or
namespace class Implementation::Foo::Rep { }

'class' in both cases is optional keyword and may be also 'struct' or 'union'.

why: stop discrimination for users that prefer to hide implementation details from class definition.

4) CTTI (sorry, can't stop :) )
what: compile time type information (typeof, bases typelist and so on).
why: allows new programming technics.


Can I also protest again the unhelpful suggestions? Thanks's.

1) garbage collection.
what: last hope for thoughtless programmers.
why: smart pointers are enough in most cases.

2) network library, GUI library, Klingon language parsing library and others "must have" libraries as parts of C++ standard.
what: some stuffs that "must have" only for it contributors .
why: too large standard library knock down the language standartization process and the compilers vendors. Please see how much issues are still open for relatively small std library. And when we take the stable std0x library if it will include hundreds of "must have" libraries? In 202x? If someone wants XXX standard library let it begin independent standartization process. I will glad to see the "Standard XML library for C++", "Standard GUI library for C++" and so on but not in "International Standard for C++ programming language".

This all is my HO, of course.

Thanks for attention,
Dmitriy Litskalov

Sorry for typo:

> Can I also protest again the unhelpful suggestions?
again --> against

> /* The last GC I sent you did not require availability of
> twice the memory you ever use, and it was a copying one.
> It also did not use indirections, as each pointer points
> s to the real objects and not to another pointer, and the
> per-object data needed where minimal (16 bytes, if I
> recall correctly).
> */
>
> This truly sounds cool, but I can't find the post where
> you linked to this GC. Could you repost the link?


I sent it to Stroustrup without ever publishing it anywhere. But I can sent it to you as well if you like (if I have not deleted it, that is!).

> Can I also protest again the unhelpful suggestions?
> ions? Thanks's.
>
> 1) garbage collection.
> what: last hope for thoughtless programmers.
> why: smart pointers are enough in most cases.

Smart pointers are good for trivial tasks only.

> If someone wants XXX standard library let it begin
> independent standartization process.

If a library is not (at least) endorsed by the C++ standards commitee, no one will consider it a 'standard'.

How about the addition of anonymous stack objects?
Something like this:

struct Foo
{};
 
int main()
{
  ...
  auto Foo(); // NOTE: the name of a variable is omited
  ...
}

The stack object Foo would be destroyed not immediately after creation, but at the end of the function main scope.

> > 1) garbage collection.
> > what: last hope for thoughtless programmers.
> > why: smart pointers are enough in most cases.
>
> Smart pointers are good for trivial tasks only.

Garbage collection is also good for trivial tasks only. How garbage collector will be proccess the complex data structures with the crosslinked entities? While a C++ programmer is responsible for the memory management he must keep it in mind and it always possible to find the appropriate solution. For example two stage deletion or something else.
I'm afraid that if garbage collection will become the part of standard runtime support then any novice or semi-skilled programmer will never think about the memory managament rely on the garbage collector possibilities. And you will never prove that some library has a memory leak. The library author will say "this is bug in garbage collector".

> > > 1) garbage collection.
> > > what: last hope for thoughtless programmers.
> > > why: smart pointers are enough in most cases.
> >
> > Smart pointers are good for trivial tasks only.
>
> Garbage collection is also good for trivial tasks only.

No, garbage collection allows arbitrary organization of structures, up to a complexity level that smart pointers do not allow.

> y. How garbage collector will be proccess the complex data
> structures with the crosslinked entities?

Please search the web on how garbage collectors work, there is plenty of documentation.

>While a C++
> programmer is responsible for the memory management he
> must keep it in mind and it always possible to find the
> appropriate solution.

Exactly, that's one of the problems: trying to keep track which objects must be deleted and where they must be deleted distracts from the main task.

> I'm afraid that if garbage collection will become the
> he part of standard runtime support then any novice or
> semi-skilled programmer will never think about the memory
> managament rely on the garbage collector possibilities.

GC shall be optional.

> And you will never prove that some library has a memory
> leak. The library author will say "this is bug in garbage
> collector".

Any good idea is first ridiculed, then rejected, then finally accepted.

>
> Please search the web on how garbage collectors work,
> there is plenty of documentation.

I known this mechanics but do google by you advise. May be industry invent something new...
Second link, http://www-128.ibm.com/developerworks/library/j-jtp10283/ :

"The benefits of garbage collection are indisputable -- increased reliability, decoupling of memory management from class interface design, and less developer time spent chasing memory management errors. The well-known problems of dangling pointers and memory leaks simply do not occur in Java programs. (Java programs can exhibit a form of memory leak, more accurately called unintentional object retention, but this is a different problem.) However, garbage collection is not without its costs -- among them performance impact, pauses, configuration complexity, and nondeterministic finalization."

See phrase in parenthesis. It point to same problem that I describe. And keep in mind that C++ pointers can be passed to the another subsystems which not under control of garbage collector. This is not closed Java world. For example in Windows GUI programming I can store one available reference to object in special lParam data field what maintained internally by common controls such as TreeView, ListView and so on. How garbage collector will known that this object live if no other references to it exists? This object must by deleted only in response to the special Windows message, not by any collectors.

> > I'm afraid that if garbage collection will become the
> > he part of standard runtime support then any novice or
> > semi-skilled programmer will never think about the
> memory
> > managament rely on the garbage collector possibilities.
>
> GC shall be optional.

Please clarify for me what does mean "optional".

For example some library LibA rely on GC.
Another library LibB uses LibA internaly in few places.
LibB use handmade memory managament.

I'm use LibB in my program. I'm never create objects from LibA directly. Moreover I don't known anything about LibA.

Some questions:
- Will be GC runtime engine linked to my program?
- Will be GC engine recieve control in any point of my program even if I use LibB only on startup?
- My program is single threaded. How GC recieve control?


> Any good idea is first ridiculed, then rejected, then
> finally accepted.

May be.

/* [me] This truly sounds cool, but I can't find the post where you linked to this GC. Could you repost the link?

[response] I sent it to Stroustrup without ever publishing it anywhere. But I can sent it to you as well if you like (if I have not deleted it, that is!).
*/

I'd be interested. You can reach me at mlybbert(at)users(dot)sourceforge(dot)net.

> retention, but this is a different problem.) However,
> garbage collection is not without its costs -- among them
> performance impact, pauses, configuration complexity, and
> nondeterministic finalization."

I know all about gc problems - but with C++, these problems are minimal. Let's see them:

1) performance impact.

C++ has advantages over Java. Specifically, Java requires all objects to be on the heap, and Java code is supervised. On the other hand, most C++ objects, especially small ones, are allocated on the stack, and code runs native. So C++ gc will not slow down a program, since the number of actual objects on the heap are much less than in Java, and C++ code does not need to be monitored. I see no performance impact.

2) pauses.

GC will be optional. If you are doing a real-time project and pauses are unacceptable, don't use it.

3) configuration complexity.

I don't understand what that is. What complexities?

4) nondeterministic finalization.

Order of finalization is not something GC must be concerned with. Destructors/finalizers are there in order to finalize resources that are is difficult to determine when they shall be finalized. In most cases though, finalization of resources takes place when some sort of event takes place: a user option, a program exit, an algorithm end, a new file opened, etc. Furthermore, C++ has RAII, which Java lacks.

> at I describe. And keep in mind that C++ pointers can be
> passed to the another subsystems which not under control
> of garbage collector. This is not closed Java world. For
> example in Windows GUI programming I can store one
> available reference to object in special lParam data field
> what maintained internally by common controls such as
> TreeView, ListView and so on. How garbage collector will
> known that this object live if no other references to it
> exists? This object must by deleted only in response to
> the special Windows message, not by any collectors.

It is silly to store garbage-collected pointers in non-pointer structures. The solution is one: don't do it.

For those libraries that manage code manually, the solution is to keep doing it manually, unless a new version of the library comes that is garbage collected.

>
> > > I'm afraid that if garbage collection will become the
> > > he part of standard runtime support then any novice
> or
> > > semi-skilled programmer will never think about the
> > memory
> > > managament rely on the garbage collector
> possibilities.
> >
> > GC shall be optional.
>
> Please clarify for me what does mean "optional".

Optional means that the programmer can

a) allocate a data structure either in the garbage-collected heap or in the manually managed heap

b) turn GC off and on at will

>
> For example some library LibA rely on GC.
> Another library LibB uses LibA internaly in few places.
> LibB use handmade memory managament.

Since LibB uses LibA, it means LibB is constructed after LibA is constructed. Therefore I see no reason why LibB would have manual memory management where it knows that LibA uses GC.

> Some questions:
> - Will be GC runtime engine linked to my program?

Yes.

> - Will be GC engine recieve control in any point of my
> program even if I use LibB only on startup?

I do not understand this question fully, but if you use GC stuff, then the GC engine will be invoked somewhere.

> - My program is single threaded. How GC recieve control?

Personally I see no reason why GC should be a separate thread. So my reply is 'a single threaded app with gc shall have no other threads'.

> /* [me] This truly sounds cool, but I can't find the post
> where you linked to this GC. Could you repost the link?
>
> [response] I sent it to Stroustrup without ever publishing
> it anywhere. But I can sent it to you as well if you like
> (if I have not deleted it, that is!).
> */
>
> I'd be interested. You can reach me at
> mlybbert(at)users(dot)sourceforge(dot)net.

Unfortunately I have erased it. If mr Stroustrup has it, then he can sent it back to me/you (I erased it because I was out of space and I did not consider it something worth keeping, as it was a platform/architecture-specific solution).

Anyway, it went like this:

1) it was for win32 on 80x86 only, as it used very platform-specific APIs.
2) it used the imagehlp library to find out where the app globals are.
3) garbage-collected threads were constructed by a custom call, in order to get the thread's id, handle and stack top.
4) the functions GetThreadContext and SetThreadContext (Microsoft debug library) were used to manipulate thread contexts.

The collection algorithm went like this:

1) suspend all registered threads.
2) scan all globals, registered threads' stacks and CPU contexts for garbage-collected object pointers.
3) if a pointer was found, then mark the object as reachable, calculate its new address, scan the object for further pointers.
4) rescan all globals, registered threads' stacks and CPU contexts; adjust pointers to point to the new addresses of objects.
5) traverse the list of objects, moving reachable objects to their new positions, and finalizaing unreachable ones.
6) resume all registered threads.

In order to find valid pointers, I used a magic number before the memory block.

/* [me] This truly sounds cool, but I can't find the post where you linked to this GC. Could you repost the link?

[response] I sent it to Stroustrup without ever publishing it anywhere. ...

[me] I'd be interested. ...
*/

Thanks for the description. Unfortunately it is very platform-specific, but the Hans-Boehm collector notes that GC is generally going to be platform specific. Even so, it's interesting.

Hi,

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

Personally I feel that I am neither experienced nor smart enough to contribute technically in a meaningful way.

However, given that the process is a resource limited volunteer effort, would the situation improve if the community (ie all of us demanding users) were to contribute somehow financially?

Given the enormous amount of money that is spent on projects developed by people/companies using this wonderful language it seems bizarre that development of same is resource limited! Surely there are enough community conscious people/companies that we can alleviate this problem? I know I would be happy to contribute, and surely the big companies that are making large sums of money from c++ community are also (morally) obliged to do so? Obviously this would have its own difficulties, but would they be easier to manage than resource limitations?

Cheers,

Michael

"but the Hans-Boehm collector notes that GC is generally going to be platform specific"

If C++ supported aspect-oriented programming and compile-time reflection, then it would be trivial to write a precise garbage collector that was platform-indepentent.

With compile-time reflection, it would be possible to construct precise garbage collection information for each object, including stack frames.

With aspects, it would be possible to inject the code that calls the collector and registers those garbage-collection metadata about each object at run-time.

Of course both compile-time reflection and aspects are different views of the same problem: manipulation of code at compile time. C++ needs a decent clean macro system that can be used to manipulate code at compile-time.

> Given the enormous amount of money that is spent on
> projects developed by people/companies using this
> wonderful language it seems bizarre that development of
> same is resource limited! Surely there are enough
> community conscious people/companies that we can alleviate
> this problem? I know I would be happy to contribute, and
> surely the big companies that are making large sums of
> money from c++ community are also (morally) obliged to do
> so?

It's an interesting idea. According to a recent blog by Guido van Rossum, he gets to spend 50% of his time at Google working with Python, no strings attached (the other 50% will be with Python, too. :) ). After all, Google is a big user of Phyton (after C++ and Java), so this benefits themselves, as well.

Maybe if larger companies that are using C++, where some of the more active members of the C++ committee, or other C++ contributors, work, could do similarly - allow them to work on C++ proposals, prototype implementations, etc. in a part of their working day.