> > 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.
>
> I wouldn't critize Boost for being "modern". I think the
> real problem is that many "boosters" are interested in
> "neat/advanced" libraries rather than in providing
> yet-another, but more standard and usable directly useful
> component. For example, why weren't boost threads, boost
> sockets, boost XML, boost unicode, and boost files among
> tthe very first boost components? Such foundation for
> applications are hard and non-glamorous - it takes a major
> effort to get people to create and maintain such
> components.

IIRC, Boost.Threads was among the first ones - I am not sure why W. Kempf gave up on it. But generally I agree, people work on whatever they find interesting.

For XML, there are Apache libraries (xerces and xalan), and for Unicode ICU - they are de facto standard in C++ world. Maybe it would be a sensible approach to just start from them and add a API layer on top of them that would be more in the spirit of C++ Standard Library?

>
> IIRC, Boost.Threads was among the first ones - I am not
> sure why W. Kempf gave up on it. But generally I agree,
> people work on whatever they find interesting.

I know (of course) and now there is a boost::treads, but the fact is that there is less activity that I would like to see and less than one might expect given the size of the C++ community (the underlying problem is that the C++ community is fractured). Boost wasn't meant to be just STL-like libraries, but it has come to be perceived that way by some.

One technical problem (that the boosters are trying to find a solution to) is that boost is a monolith. This has been a problem with outher libraries also, such as ACE. For example, say I want to be able to download and use just the regular expressions and don't want any other library to complicate my system, how can I get just boost::regex and what it depends on and nothing else.

> For XML, there are Apache libraries (xerces and xalan),
> and for Unicode ICU - they are de facto standard in C++
> world. Maybe it would be a sensible approach to just start
> from them and add a API layer on top of them that would be
> more in the spirit of C++ Standard Library?

Yes, that would be one plausible approach. All we need is a small group of people to do it; people who have the patience to follow through and who won't be dismayed when -inevitably - their first cut won't be good enough.

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

> First of all I want to give respects to Bjarne Stroustrup
> for the most powerful programming language I ever seen.

Thanks

> Practice of programming big OOP projects shows me two weak
> things in C++ which I think MUST be solved in the next
> generation of language.

but what does "MUST be solved" mean in the context of a formal standard written by volunteers?

> First of all: dynamic object creation by some class id.
> It is very often operation in programs which maintains
> polymorphic object's collections. So I very often suffer
> from declaring ugly macroses like DECLARE_DYNAMIC and own
> implementations of minimalistic RTTI tables for that
> behaviour.

Please explain. What is it you do that can't be handled by a simple factory? (i.e. a use of the factory pattern)

> The second problem is: after each time I add new data
> member to the class I forget to add a few important lines
> of obvious code to program. Typical examples are:
> serialization methods, log/dump activities.
> I see perfect solution in conjuction of generic
> programming with embedded MPL concept.
> Let's see next pseudo-code:
>
> class some_class
> {
>
> [persistent] int data1, data2; // serialization code can
> an be generated automatically
> ...
> void save_to_stream( stream &s )
> {
> mpl_for_each_data_member([persistent] x){ s << x; };
> };
> };
>
> This is some kind of treating marked data-members as
> compile-time collection (tuple) which can be manipulated
> in generic manner. This doesnot involves any overhead and
> as I see similar ideas was mentioned.

But as far as I can judge, doing this in general rather than for a particular problem would involve a complete interface to a compiler's information. That's distinctly non-trivial.

I am working in this area - using tools external to the compiler - and dealing with desclaration in general (incl. templates, specializations, access controls, etc.) is not easy to make accessible.

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

First of all let me explain my point of view to the evolution of programming techniques.

This evolution makes one important things: simplifies process of programming.
How does it?
I think there is two means by thich it is done:
1. decreasing size of code which must be written to accomplish a task
2. decreasing inner relations between parts of program code which depends each on other

Examples of evolution by first point are: functions, templates, inheritance of classes, damned automatic garbage collectors, C++ algorithms. All this techniques decreases size of code I must write to accomplish my programming task.
Examples of evolution by the second point are: variables/functions symbolic names (instead of direct memory addresses), incapsulation, smart pointers or auto GC again, OOP at all. I think the main goal of this techniques is: if I (re)write some part of code I need no to review another parts of it.

So... I call "error-prone code" such code which:
1. is longer and more complex than it can be
2. forces me to seek and (re)write another code then I want to (re)write this code

So this is my criterion to the "ideal" programming language/technique:
1. I need to write only minimal text of code
2. I need to rewrite only minimal text of code

Quite simple, isn't it? :) Some other languages solves these problems by reducing its complexity and flexibility (for example - GC). That is no way for C++.

So now I can express why I want to have mentioned modifications to the C++ language:
I do not want more to write my own implementations of class factories which usual based on boring macroses DECLARE/IMPLEMENT_DYNAMIC.
Also I do not want more to seek in the *.cpp and rewrite serialization or zero-fill-initialization code every time I add new data member in the *.h to the class.

Some other languages have built-in facilities to simplify this tasks. Such as full dynamic run-time-TI with reflection API.
C++ have great potention to solve this tasks easily in the compile-time. And I wish it. :)

This is my point of view and I hope you will agree with it. However it is just a wish. :) Probably you can solve this "evolution questions" in another manner.
Also I think that new generation of C++ will be the super-language when boost can be rewritten in it without using macroses. :)

Thank you.

> 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 can tell you why I had a hard time learning C++ from the books I looked at. I obviously can't speak for people whose minds work differently, or who get tripped up over different issues in programming ;-)

Now, in my case, I had been programming in C, Java, and R for many years. I looked at TC++PL, "Thinking in C++" (Eckel), and "C++ Primer" (Lippman) and couldn't find what I was looking for in any of them.

I didn't realize this until recently, but what I wanted to know about C++ (or, about any new language I try to learn) was how to translate it into C; if I can see how to translate a statement in language X into a set of statements in C to do the same thing, then I feel comfortable that I understand what the statement is doing in language X and am willing to learn more about the language. If I can't, then I feel like I am stumbling around in the dark, which drives me nuts.

It has always amazed how much it is possible to do in C (and its preprocessor) given what a small language it is. I think this is another way of saying that C's way of thinking about what programs are doing is extremely well conceived. It is the algebraic notation of procedural programming, greatly simplifying the notational zoo that preceeded it (or that proceeded it's earliest ancestor with the same conceptual framework).

BTW, I never had any problem learning how to reduce Java programs into C as I learned the language, which may be why some people have such an easier time learning it than C++.

Here's a concrete example of what I mean.

Take the following the C++ statements:

int x=1;
int y=2;
cout << "X=" << x << ", Y= " << y;

These are the corresponding C statements I wanted to see:

ostream *f1(ostream&,char *);
ostream *f2(ostream&,int);
ostream *f3(ostream&,double);

int x=1;
double y=2;

f3(f1(f2(f1(cout,"X="),x),",Y="),y);

If I were to write a book on C++, my target audience would be people who know C and OOP (from another language) well and I would open chapter 2 with this example. I think most people who know Java well would fit in this audience.

Chris Marshall

> The short answer is that "it's not on the list of approved
> deductions" :) (The standard has a list of cases where
> deduction can happen - 14.8.2.4/3). In the definition:

I see. Thanks for pointing that out and telling me where to look the deductions list up. You're being very helpful.

> The question then becomes "Why?" As I understand, the
> reason is that due to possible specialisations, the
> compiler can't necessarily know at the point of
> instantiation, what the nested member is. Consider:
>
> f(aliases<double>::vec()); // Let's say we allow this, and
> T deduces to "double".
>
> then later in the code:
>
> template<>
> struct aliases<double> {}; // Oops, no "vec" member
> available, anymore...

I'm not sure I see the problem with the code you wrote. If f() were called at a point in the translation unit after the specialization were introduced like this:

struct aliases<double> x;
f(x)

then I imagine that the deduction algorithm would stop the compilation with an error message to the effect that there was no acceptable value for T that could successfully instantiate f as used in f(x).

I don't see how we would be any worse off in that case than without the additional deduction rule. Without it, deduction fails more often than with it.

Chris Marshall

> > For XML, there are Apache libraries (xerces and xalan),
> > and for Unicode ICU - they are de facto standard in C++
> > world. Maybe it would be a sensible approach to just
> start
> > from them and add a API layer on top of them that would
> be
> > more in the spirit of C++ Standard Library?
>
> Yes, that would be one plausible approach.

That's exactly what I've done with XMLSTL so far. It is a unifying wrapper over both MXSML DOM (virtually complete) and Xerces DOM (a significant coverage so far).

One remaining issue with the Xerces DOM version is I've yet to decide - and will be happy to take input - is how to do the various initialising actions that Xerces DOM. I'm considering Schwarz counters, but am still pondering the matter.

> All we need is
> a small group of people to do it

As soon as I've got the first draft of Extended STL volume 1 (http://extendedstl.com/) done - this week! - and placated my commercial client (who very kindly gave me 6 weeks to work on my book, and who has some needs to satisfy next week), I plan to release the first alpha.

Given the amount of discussion and hearty sentiment on the need to pull together in this forum, I expect a lot of input/help. Of course, if it falls on deaf ears, then this would be a very sad indictment of all-talk-and-no-trousers. But I am really hopeful that it won't.

> people who have the
> patience to follow through

As I said, it's largely complete for MSXML DOM. There are several remaining issues that need to be addressed before it could be ready for a proper release - such as it is currently using a couple of components from the Synesis libs (current requiring the use of a DLL), until I modify things and make it all header-only open-source like the rest of STLSoft. But I plan to release it virtually as it stands now, so that people can play and criticise the interfaces first, while I put in the couple of days' work to get rid of such dependencies.

I've got several example programs that conditionally compile both variants - which live in xmlstl::msxml::dom and xmlstl::xerces::dom - which should serve as good illustrations of the library, and how closely (but not yet completely) I've managed to unify the syntax.

(FWIW: The layers provide, if your compiler supports it and you don't define XMLSTL_NO_METHOD_PROPERTY_SUPPORT, properties for the various components - node, document, attribute, etc. - so you can write code such as


char const *fileName = . . .
document    doc(file);
element     el    = doc.documentElement;
string_t    name = el.nodeName;

cout << "Document element: " << el.nodeName << endl;

node_list nodes = el.selectNodes("./ToolSuites/ToolSuite");

{ for(size_t i = 0; i < nodes.get_length(); ++i)
{
named_node_map attrs = nodes[i].attributes;
string_t        name = attrs["name"].nodeValue;
string_t        desc = attrs["description"].nodeValue;

cout << "ToolSuite " << name << ": " << desc << endl;
}}


if not, you can use the function forms:


char const *fileName = . . .
document    doc(file);
element     el    = doc.get_documentElement();
string_t    name = el.get_nodeName();

cout << "Document element: " << el.get_nodeName() << endl;

node_list nodes = el.selectNodes("./ToolSuites/ToolSuite");

{ for(size_t i = 0; i < nodes.get_length(); ++i)
{
named_node_map attrs = nodes[i].get_attributes();
string_t        name = attrs["name"].get_nodeValue();
string_t        desc = attrs["description"].get_nodeValue();

cout << "ToolSuite " << name << ": " << desc << endl;
}}


The MSXML variant works with both ANSI and Unicode compilation.

And, for those who are concerned about modern-only libs, this works with compilers as dull-witted as VC6 (albeit without the properties). <g>)

> and who won't be dismayed when
> -inevitably - their first cut won't be good enough.

That won't happen. I'm like a T-1000 to criticism. ;-)

But I can't make the community interested in my work, any more than anyone else. But, Bjarne, you can, so I would ask that you at least follow along on the progress every now and then, and, should it meet your standards, you might comment on it? It that fair enough?

Matthew

Now that we are here and big and famous people are reading this forum thread, I would like to propose a garbage collection solution that can be done in a library...it's actually very small and very easy to do, and I hope it offers good performance.

Let's see what we need for a minimal garbage collector:

a) we need to know which objects are collectable.
b) we need to know the root set.

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.

For knowing the root set, the solution is, again, quite easy: a 'smart pointer' class pushes itself, during construction, in a pointer stack that exists as thread local storage; upon destruction, the pointer pops itself from the pointer stack. The pointer class does not need to have extra fields; it will be the same size as a normal pointer, and using TLS makes the operation quite fast.

Garbage collection will be perfomed when the allocation size exceeds the GC user-defined limit, inside the allocation routine. The collector will be a simple stop-the-world, then mark-and-sweep algorithm:

1) all garbage-collected threads, except the current one, are suspended.
2) all pointer stacks of garbage-collected threads are traversed and reachable objects are marked.
3) all unreachable objects are deleted.
4) all previously suspended threads are resumed.

This solution assumes very little: the only requirement is the existence of a thread library that allows thread local storage.

What does everybody think?

> > The question then becomes "Why?" As I understand, the
> > reason is that due to possible specialisations, the
> > compiler can't necessarily know at the point of
> > instantiation, what the nested member is. Consider:
> >
> > f(aliases<double>::vec()); // Let's say we allow this,
> and
> > T deduces to "double".
> >
> > then later in the code:
> >
> > template<>
> > struct aliases<double> {}; // Oops, no "vec" member
> > available, anymore...
>
> I'm not sure I see the problem with the code you wrote.
> If f() were called at a point in the translation unit
> t after the specialization were introduced like this:
>
> struct aliases<double> x;
> f(x)
>
> then I imagine that the deduction algorithm would stop the
> compilation with an error message to the effect that there
> was no acceptable value for T that could successfully
> instantiate f as used in f(x).
>
> I don't see how we would be any worse off in that case
> than without the additional deduction rule. Without it,
> deduction fails more often than with it.

The problem is that if it did the deduction _before_ the specialisation was encountered, then when the specialisation was encountered, the deduction it did earlier would be wrong. One way around it might be that it keeps track of what deductions it has done, and then reconsiders them, if there are any specialisations.

However, there might be other problems with this. Consider what is to be deduced:

template<class T>
void f(typename aliases<T>::vec) { ... } (*)

Now you call f with a value of type X:

X x;

f(x);

Here, the compiler will have to search a theoretically unbounded number of specialisations, to find an instantiation of aliases<T> that has a "vec" member with the type X.

Note that, in the general case, "vec" can be the result of an arbitrarily complex type-computation, that the compiler could have a very hard time of "running backwards" to find the right value for the template parameters (and any other compile-time values being used in the computation).

(*) "typename" is actually required, even though many compilers will let you get away with it, because - before instantiation time - the compiler doesn't know that "vec" is a type, or something else. I see I didn't use this in the earlier posting.

> But I can't make the community interested in my work, any
> more than anyone else. But, Bjarne, you can, so I would
> ask that you at least follow along on the progress every
> now and then, and, should it meet your standards, you
> might comment on it? It that fair enough?

A rather obvious suggestion, but still...: I suggest you post about it at Boost, once you have something that people can look at and play with, and invite comments. I know the boosters have expressed interest in getting an XML library, if you'd be interested in submitting it there. As many committee members are on the mailing list, you're sure to get their attention, this way.

> "-No true message passing."
>
> Boost.Signals does this quite well, not requiring you to
> specify the interface up-front.

I am not talking about signals and slots, but message passing ala Objective C / Smalltalk.

>
> "-No retrospection."
>
> You talk about the "run-time structure" of a class, but
> also say this will have no run-time overhead, so I'm
> guessing you mean compile-time introspection information
> (or what to call it). Bjarne Stroustrup has an XTI
> (Extended Type Information) project, that provides this
> information at run-time, and then there's Daveed
> Vandevoorde's "Metacode" extension proposal, for making
> the type information available at compile-time, and for
> making metaprogramming easier, being able to use normal
> C++ syntax for it.

No, I am talking about probing a type for information about its structure at run-time. There is no performance impact at run-time; there is memory impact, but introspection could be optional.

> > > For XML, there are Apache libraries (xerces and
> xalan),
> > > and for Unicode ICU - they are de facto standard in
> C++
> > > world. Maybe it would be a sensible approach to just
> > start
> > > from them and add a API layer on top of them that
> would
> > be
> > > more in the spirit of C++ Standard Library?
> >
> > Yes, that would be one plausible approach.
>
> That's exactly what I've done with XMLSTL so far.
> It is a unifying wrapper over both MXSML DOM (virtually
> complete) and Xerces DOM (a significant coverage so far).

Is it something like Arabica? http://www.jezuk.co.uk/cgi-bin/view/arabica/roadmap

> > But I can't make the community interested in my work,
> any
> > more than anyone else. But, Bjarne, you can, so I would
> > ask that you at least follow along on the progress
> every
> > now and then, and, should it meet your standards, you
> > might comment on it? It that fair enough?
>
> A rather obvious suggestion, but still...: I suggest you
> post about it at Boost, once you have something that
> people can look at and play with, and invite comments. I
> know the boosters have expressed interest in getting an
> XML library, if you'd be interested in submitting it
> there. As many committee members are on the mailing list,
> you're sure to get their attention, this way.

Boost is the best forum that I can think of. I'm not the only person interested in XML tools (e.g. see the libraries wishlist). I do try to keep up with the various proposals and developments that might become proposals, but there are many and I don't have more hours in a day than anyone else. So, it's a very good idea to be in a forum where several people from the committee participates rather than just relying on me.

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

> > But I can't make the community interested in my work,
> any
> > more than anyone else. But, Bjarne, you can, so I would
> > ask that you at least follow along on the progress
> every
> > now and then, and, should it meet your standards, you
> > might comment on it? It that fair enough?
>
> A rather obvious suggestion, but still...:

Well, in one way it's a cheap sneak, but in another it's not. Bjarne's here. He's (rightly) bemoaning the (possibly unjustified) perception that the C++ standards process is a dim and impenetrable domain. People are responding. Is it too much to ask that such responses receive a modicum of active attention?

For my part, I've several things I'd like to propose for the standard - some very small and simple (one of which is all but ready to be submitted); some large and not-so-simple - but 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/n1810.html, but beyond that it's still pretty opaque to this little pixie. Will my submission be immediately disseminated to panel members? 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 ...) Do I need to join the committee (assuming they'd have me .. LOL)? Do I have to stump up $800? (Having taken off all the time I have in the last couple of years for the perverse pursuit of writing books, I suspect that were I to suggest lashing out such an amount merely to give me the right to volunteer my services freely to my business manager (and better half), she might well render me incapable of furnishing her with any more sons.)

So, if, at this point in time I/we have the attention of the author of the language, it can't be too surprising that I/we are grabbing on to his wrist like hungry little children to prevent his departure. (Ok, outrageously honey-soaked analogy, I grant you, but there's truth running through it.)

(FYI: Chuck (Allison: editor of The C++ Source) has agreed to my "diarising" my experiences, such as they may be (warts and all), in making these proposals in The C++ Source, so at least others in this position may be a little better informed should they seek to make proposals in the future.)

> I suggest you
> post about it at Boost, once you have something that
> people can look at and play with, and invite comments. I
> know the boosters have expressed interest in getting an
> XML library, if you'd be interested in submitting it
> there. As many committee members are on the mailing list,
> you're sure to get their attention, this way.

I'm not interested in submitting it as a Boost library, but I'll bear in mind the possibility that useful criticism might be elicited from the Boost community.

Cheers

Matthew

> but I'll bear in mind the possibility that useful
> criticism might be elicited from the Boost community.

Post-"Post Message" click that reads as sarcastic, which was not intended.