Slashdot Mirror

Of course, each O/S provides its own set of routines (e.g. Interlocked functions of Windows), but it would be better if the language provided the primitives for atomic operations.

Given that the C++ committee is seriously considering garbage collection for inclusion in C++09, and Bjarne Stroustroup personally considers it one of the most important improvements, I'd say that people claiming that GC is not the "C++ way" are wrong.

Given that the C++ committee is seriously considering garbage collection for inclusion in C++09, and Bjarne Stroustroup personally considers it one of the most important improvements, I'd say that people claiming that GC is not the "C++ way" are wrong.

1. Is is C++0x ready?
2. Does it work with FreeGLUT or MESA for OpenGL support?
3. Can it make ice cream?

But. As much as I love C++ ( and I do ) the real weakness is the lack of usable closures/lambda.

But. As much as I love C++ ( and I do ) the real weakness is the lack of usable closures/lambda.

Then I guess you'll be happy to hear that the proposal for lambda expressions is well on its way to getting included in C++09.

See the proposal for the next gen of c++:

http://www.open-std.org/JTC1/SC22/WG21/docs/papers /2007/n2329.pdf

Well I would like to see your evidence of that! Having worked on the the original C standard extensively and done a fair bit of work on the C++ standard, I find it rather annoying that an unsubstantiated statement like this is trotted out.

If you have been involved in drafting the C standard then you should be aware of the list of defect reports. You should know that it is almost impossible to precisely specify every single detail that a normal working human would naturally assume.

The standard is far from complete in the sense that a literal and mechanical interpretation of it won't produce a working C compiler. You still need a human to fill in the gaps and to guess the trivially sane assumptions. Also remember that C standard is a much simpler thing to specify than the file format for an office suite. And yet it takes, as you say, 50 people in a room reading every single word.

And for the record, I work with implementing and testing JSR:s. They also contain goatse-sized holes, which is why the JCP requires reference implementations because specs never specify everything they need to specify.

Also, shared_ptr has been promoted to the draft standard C++-0x so you can use std::shared_ptr.

You'll be able to use C++-0x in gcc-4.3 with a switch.

I also heard that std::auto_ptr is being deprecated (not removed) I guess in favor of rvalue references.

Finally, there is a motion to include garbage collection in the C++ language. This is sponsored by none other than Hans Boehm among others.

I realize this doesn't help immediately.

Use -std=c99 instead - this will switch to ANSI C99 (aka ISO 9899) mode
(which isn't fully implemented yet...)

Check these out:

http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/

http://www.artima.com/cppsource/threads_meeting.ht ml

http://www.usenix.com/publications/login/2007-02/o penpdfs/standardsfeb07.pdf

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1 164.htm

or, just google for "boehm threads c++"

C is a language, not a program.

Yes, I realize that.

And the preprocessor directives are part of that language. Or perhaps you missed sections 5.1.1 and 6.10 of the description of that language? (Assuming the numbering stayed the same from draft to final.)

C++ is likely to get quite a few things in 2009:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers / // ville

I think you're right, you have to know C or C++ intimately to be able to write correct code. C++ is a half-assed attempt to add modern features to C which results in an explosion in complexity. The thing is, C is not an easy language to program in because there is almost no protection against shooting yourself in the foot. Luckily C is pretty small and simple, and it is possible to understand the language well enough to be able to write a simple compiler after you've used it for a couple of years. Now C++ is pretty much impossible for one person to understand. Even the compiler writers find themselves struggling with the specification. If anyone still have doubts, have a look here http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_de fects.html for some eye-opening reading material...

As for my auto_ptr complatint, what I meant was that there was no mechanism in standard C++ to transfer ownership of an object to a container without copying the object.

This is called "move semantics" and is part of the plan for C++0x (although Bjarne's article didn't make mention of it). See http://www.open-std.org/jtc1/sc22/wg21/docs/papers /2002/n1377.htm

If you're interested in reading about possible future extensions to C++, check out the official home of the C++ Standards Committee. The papers page links to all the "mailings" containing every paper submitted to the committee, as well as draft standards and such. There's a lot of interesting ideas floating around: true "metacode" macros (like Lisp), flexible initialization (so that the {...} initializer could be "overloaded" on your own classes), automatic type deduction, etc.

If you're interested in reading about possible future extensions to C++, check out the official home of the C++ Standards Committee. The papers page links to all the "mailings" containing every paper submitted to the committee, as well as draft standards and such. There's a lot of interesting ideas floating around: true "metacode" macros (like Lisp), flexible initialization (so that the {...} initializer could be "overloaded" on your own classes), automatic type deduction, etc.

See the SEAL Reflex project, the OpenC++ project, the PUMA project(now in AspectC++), Arne Adams' reflection library, and XVF by Kurt Stephens. These all work and provide introspection to some degree. There are other projects like Stroustrup and dos Reis's The Pivot and Vandevoorde's Metacode that may make it into future C++ standards to make it easier to provide good introspection support.

SEAL Reflex http://seal-reflex.web.cern.ch/seal-reflex/

OpenC++ http://opencxx.sourceforge.net/

AspectC++ http://www.aspectc.org/

Reflection library http://www.arneadams.com/index.html

XVF http://kurtstephens.com/research/paper/xvf_paper/

The Pivot talks http://charm.cs.uiuc.edu/patHPC/slides/stroustrup- a.pdf
http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks /DosReis.pdf

Metacode talk http://www.open-std.org/JTC1/SC22/WG21/docs/papers /2003/n1471.pdf

POSIX threads could propably be considered a standard threading library for C/C++. Though for true C++ standarized threading library, check out N1907 which is propably going into TR2 and later into the standard.

Because C++ compilers can ("implementation-defined") modify your main() to call static constructors. If this happens, your globals get stomped. You are also disallowed in C++ to compute the address of main(), lest you try to call main via a pointer.

See Section 3.6.1 paragraph 3 of IEC 14882.

Actually, what I was looking for (and had escaped my mind) was one of the following:

Library Extensions Technical Report 1

or

Library TR1

I knew TR stood for technical report. I have seen both of these refered to when introducing TR1 in articles--primarily in C/C++ Users Journal.
While I am mentioning it. You can download an older draft (January 2005) of TR1 here, and Scott Meyers has updated his page with information mapping items in TR1 to Effective C++ ( which is a must read for all C++ programmers).

Well, if I'm reading this right, "C++0x"* will give us:
I don't think you've read this right, if at all.

C++ is bringing us much more than the tiny details you are focussing on. For a picture of what's going one, check the many proposals that are currently being reviewed:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers /

Templates in C++ are much more than a macro system, which already existed in C. What exactly are you looking for that is not supported in C++ templates? Maybe introspection, or the definition of constraints on the template parameters? Well, there are proposals for adding both of these features to C++0x.

Boost has been a powerful tool for studying the design and implementation of new features as library extensions. Many have matured, and now that the community has gained experience with them, they are being integrated to the standard language. Just because of this higher level of maturity, I expect to see them properly implemented much faster than the original STL.
Many features offered in Boost work nicely as is, and are being integrated in the standard library (e.g. function objects/delegates, ref-counting smart pointers, tuples, regular expressions, threading).
Others were proven to require language changes, which are being proposed for integration in the core language: typeof, closures, etc.

Finally, "C++0x" is not the name of a new language. It is a reference to the next standard, expected sometime before 2010 (therefore 200x), which will become The C++. There is just no marketing guy giving this a fancy name to sell it as the next big thing.

Here's an explanation. Here's a manual. Here is a writeup.

I encourage you to look at any of those and then this C++ proposal (from the ISO people).

http://www.open-std.org/jtc1/sc22/wg21/docs/papers /2004/n1736.pdf

Let me know what you think.

> False. Member function pointers are
> standardized and not implementation dependent.
> They do have a syntax that is unusual, however.
> It's unreasonable to expect C++ to support
> delegates "like C#" considering that C# was
> designed long after C++.

Um, I think parent was referring to the fact that the size of mfps are implementation-dependant -
http://www.codeproject.com/cpp/FastDelegate.asp

> If you program in C++ from dawn to dusk, the =0 notation should be perfectly normal to you, and not a problem in the slightest

Yes its a problem - the creator himself even aknowledged himself that it was basically a hack because a keyword wouldn't be accepted. Just get it over with and use abstract already :).

> You cannot call constructors, PERIOD. Placement
> new is not invoking a constructor, it's
> evaluating a "new expression" using an
> allocator function that returns the address it
> is given, and a SIDE EFFECT of that is the
> invocation of the constructor. It's simply
> impossible to directly call a constructor in
> C++.

Wow, that's some real nitpicking there :\. As long as you remember to call the destructor beforehand or call it on an uninitialized object it is the functional equivelent of calling the constructor of an object.

> Placement delete is only used to cleanup the
> memory when an exception causes the constructor
> to fail

Yes, but I think what parent meant was that it makes logical sense to match every new with a delete, which in the case of placement new is generally not the case.

> And, as an obviously competant C++ programmer,
> you should know that if the constructor exits
> with an exception, the destructor is NOT
> invoked because the object wasn't constructed
> and therefore doesn't really exist.

One of the complicated things about c++ that routinely trips up even experts in practice.

> You're correct, and you may find that we're
> trying to address this topic in C++0X. If
> you're interested, see http://www.open-std.org/jtc1/sc22/wg21/docs/papers /2004/n1737.pdf

Good luck. Personally, I think the embedded c++ standard was the best comprimise between c and c++.

One more thing - please remember that that standard will have big consequences for compilers to come - for wxWidgets I still have to deal with old, arguably broken, compilers. Please don't rush it and make sure it gets right this time :).

First, with ISO-quality standards, updates are made carefully and slowly to insure the least pain to all users relying on the standard. Backwards compatibility is usually the most important concern to the maintainers; there's no "willy nilly" changing going on. [Compare this to say Java, whose specs change much more quickly and perhaps more "willy" than C++]

There are many reasons to update standards periodically:

1. Most standards bodies (such as ISO) *require* that all standards be updated, or at least re-affirmed, on a periodic basis; usually once per decade. Otherwise they are considered abandonded and "revoked" from having its standard status. This helps weed out truely abandoned standards as well as insures that the standard is properly maintained and retains its usefulness.

2. As with most language standards, there are always many many small technical imperfections, or more commonly ambiguities, that need to be addressed or clarified. Most of these will never affect the "common" programmer, except perhaps those on the fringe (such as with embedded systems and so forth).

3. Practical experiences with a language often show shortcommings that, although may be technically minor, greatly detract from the language's usefulness in some cases. For instance when the C standard was last updated they made the numerical semantics much tighter (because they found out FORTRAN programmers could not adequately port programs to C without them). These changes would be hardly noticed by most programmers who don't do heavy and precise computation; but greatly welcomed by those who did.

4. Sometimes novel techniques or components are invented which prove to be very general solutions to widely-encountered problems, and which fit the "style" of the language very closely. Once these experimental components are deemed very mature and stable, adding them into the language proper can benifit all language users. For C++, many of these new extensions come out of the Boost project. But only the most mature and the most general-purpose extensions should be considered for standardization.

For a look at what's on the C++ issue lists, look at http://www.open-std.org/jtc1/sc22/wg21/

False. Member function pointers are standardized and not implementation dependent. They do have a syntax that is unusual, however. It's unreasonable to expect C++ to support delegates "like C#" considering that C# was designed long after C++.

2. The "virtual =0" syntax instead of something nice like "abstract" or "interface" is just weird. How can you set a prototype equal to 0? What's wrong with nice words?

There is hesitation to introduce keywords, for fear of breaking backwards compatibility. If you program in C++ from dawn to dusk, the =0 notation should be perfectly normal to you, and not a problem in the slightest. They could have made it more descriptive, but it's certainly not a showstopper, and no C++ programmers I know even notice it anymore, as it is just a part of how things are done. Maybe it's a problem for newbies, but you're only a newbie for a short time.

3. Operator new and delete were designed by someone on crack. The only way to call a constructor is with placement new, whose syntax looks like: new (var) type(). Placement delete, however, doesn't call the destructor, which must be invoked manually. Furthermore, delete can't take parameters like new. What. You cannot call constructors, PERIOD. Placement new is not invoking a constructor, it's evaluating a "new expression" using an allocator function that returns the address it is given, and a SIDE EFFECT of that is the invocation of the constructor. It's simply impossible to directly call a constructor in C++.

As for "placement delete", I think you lack understanding. Users are not supposed to invoke placement delete, they are supposed to just invoke the destructor for objects created with placement new. Placement delete is only used to cleanup the memory when an exception causes the constructor to fail. And, as an obviously competant C++ programmer, you should know that if the constructor exits with an exception, the destructor is NOT invoked because the object wasn't constructed and therefore doesn't really exist. Operator new and delete are about MEMORY MANAGEMENT and not object lifetime issues. Constructor and destructors are about that. A "new expression" makes use of operator new and also invokes a constructor. You seem to have confused the "new expression" for operator new.

4. There is a "typeid" operator but no "typeof" operator. GCC has an extension for this, but it's not standard C++ I think.

You're correct, and you may find that we're trying to address this topic in C++0X. If you're interested, see http://www.open-std.org/jtc1/sc22/wg21/docs/papers /2004/n1737.pdf

Perhaps your googling skills need a bit o' work ;-)

TR1 is the Technical Report (#1) on C++ Language Extensions. In other words it covers the standard library rather than the language itself.

Try one of the following:
Technical Report PDF http://www.open-std.org/jtc1/sc22/wg21/docs/papers /2005/n1745.pdf
Scott Myers Summary: http://aristeia.com/EC3E/TR1_info_frames.html

The function called at program startup is named main. The implementation declares no prototype for this function. It shall be defined with a return type of int and with no parameters:

int main(void) { /* ... */ }

or with two parameters (referred to here as argc and argv, though any names may be used, as they are local to the function in which they are declared):

int main(int argc, char *argv[]) { /* ... */ }

or equivalent; or in some other implementation-defined manner.

If the return type of the main function is a type compatible with int, a return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument; reaching the } that terminates the main function returns a value of 0. If the return type is not compatible with int, the termination status returned to the host environment is unspecified.

One is support for multiple return values, which I love.

Have you seen the new tuple library being added to C++? See here. GCC 4.0 already supports them. At first I was reading through and wasn't that impressed, but then I saw things like:

#include <tr1/tuple>
#include <tr1/functional>
using namespace std::tr1;

tuple<int,char,double> doStuff(); ...
{
int a; char b;
tie(a,b,ignore)=doStuff();
}

Yes, the above works. And with inlining or the named return value optimization, it doesn't slow down your program. And it shuts up those people who don't like returning data in references :)

I was reading through the list of things already in the first library addition and got pretty excited. see here. Already added are reference-counted smart pointers (much more impressive than the usual), regexp, standarized hash tables, a new parameter binder, additional support for template metaprogramming and a few other things.

In the pipeline for TR2 are lambda functions (see Boost.lamba, say: Function F= _1*_2) and a lot of other fun stuff.

Heh. And Java is barely on templates :P

One obvious example of a messy C++ (non-)feature which doesn't help to solve any problems is the reliance on header files. Watch how this destroys any hope of separate compilation when mixed with templates.

• std::tr1
• Utilities
• • shared_ptr
  • regular expressions
  • random numbers
• Meta-Template-Programming
• • reference_wrapper
  • lambda binders and adaptors
  • type_traits
  • tuples
• Containers
• • arrays
  • hash containers

Surely if we want this in the standard library, it should be included as part of the next version of the ISO C++ standard?

Which at least significant amounts of it is likely to be. Check out the standards committee Library Working Group's web pages for more details. You can find a list of proposals that have already been accepted into the library TR here.

memory addressing starts at zero

Any pointer type may be converted to an integer type. Except as previously specified, the result is implementation-defined. If the result cannot be represented in the integer type, the behaviour is undefined. The result need not be in the range of values of any integer type.