Artima has published a PDF document that contains the presentation materials from Scott Meyers' three-day training course on C++0x, the next major version of C++. It provides an incisive overview of the most important new language and library features in the remarkably wide-reaching revision of C++ that compiler vendors have already started to support. You can purchase a copy here:
Same content as the training course: The PDF you'll
get is an exact snapshot of Scott's full-color training materials on the
day he generates the PDF. You'll get not only the
slides Scott shows in class, you'll also get the accompanying notes—the
very ones Scott uses. To see exactly what you'll get you can
view a free sample.
No DRM: You may copy the PDF to as
many devices as you like, annotate it in any way you want, print it in part
or in full as many times as you choose. Because the PDF is for your
personal use only, you are not permitted to provide copies to friends or
colleagues, may not install it on servers for public access, can't use it
as the basis for presentations, etc., but we trust you to adhere to these
restrictions; the PDF itself doesn't try to prevent unauthorized uses. (For
more permissive usage options, consider licensing
the materials.)
Free updates for life: You are entitled to
free updates to the materials as long as Scott produces them.
Major revisions are included, so you won't have to pay again later for a "new edition."
<rant>C++ is getting more and more confusing. I'm thinking of going back to C and using it like it was objects. (That is, functions and data structures grouped together). Looking at this overview does nothing for me, (not dissing Scott Meyers who is a favorite C++ author) but it seems the language has grown beyond the scope of being useful, and has become more of an intellectual exercise. </rant>
> If > you don't like a particular feature, then just don't use > it.
For any language, this argument only works if you program in isolation. If you work with others, then somebody is likely to use those features you don't like (unless you have the authority to prohibit such use).
> > If > > you don't like a particular feature, then just don't > use > > it. > > For any language, this argument only works if you program > in isolation. If you work with others, then somebody is > likely to use those features you don't like (unless you > have the authority to prohibit such use).
Let's, intentionally, take it into some extreme: - What if the other people do not like the naming I use in C++? Should be naming rules in the standard? - What if the other people do not like my methods? Should the language contain standardized methods/routines? (hey, could be a nice put-together-under-GUI-and-run solution). - What if the other people do not like C++ at all? - What if the other people do not like to work at all?
> Let's, intentionally, take it into some extreme: > - What if the other people do not like the naming I use in
> C++? Should be naming rules in the standard?
I don't see why not. There are many different naming conventions that are equally good. The key to naming is consistency. A. There is no advantage to going from one (good) naming convention to another and B. The more consistent the naming the better. Standardizing naming for languages therefore has lots of advantages without any real downsides. I've never really understood the resistance to naming/coding standards.
> - What if the other people do not like my methods? Should > the language contain standardized methods/routines? (hey, > could be a nice put-together-under-GUI-and-run solution).
If there are already commonly used routines that fit your needs, you should use them.
> - What if the other people do not like C++ at all?
They should either find a project/job using a different language or suck it up.
> - What if the other people do not like to work at all?
The problem for me, is that things have become un-obvious. An easy example is
void foo(int &val) { ... val = 1; ... }
int myval=2; foo(myval); Any programmer calling foo has no indication that myval will change without looking at the called program.
I preferred the syntax for passing a pointer foo(&myval); because then you know that myval is up for grabs.
templates seem to work differently for different compilers, and boost is just a chore to get working correctly.
How hard is it to create a linked list by hand? Not very. I can see the template advocates saying that to create a linked list using the stl is even easier.
But then all the gotcha's start appearing. You can't do this with it, you have to watch out for special cases and so on. I can't remember the details, but I've tried to reimplement code to use the stl, and the code ended up bigger and more fragile. Debugging broken code is much more difficult when using templates.
My personal coding standard is to avoid templates as much as possible. You get more work done, you can debug/trace through the code, and there are fewer hidden gotchas. Especially when dealing with multiple compilers.
Reading the overview of the article Scott Meyers talks about using move as a new tool. He uses 28 pages to explain the concept with examples.
I can't get through it. I don't understand why it is important. If you want to move some data, isn't that just copy and delete the old data? Or change the pointer? Or copy and overwrite the old data?
It feels like complexity for complexity's sake.
I'm starting to see the wisdom of rejecting c++ for anything dealing with kernel code in Linux. C can do the same job and it is easier to understand.
Chris Bruner's opinion (C++ is too confusing) is nothing new. I will note, however, that much of the new standard is meant to simplify many use cases. The tiniest probably being that there will no longer be a need to put a space between the two >'s in std::vector<std::vector> >. Another, probably more confusing, change will be to make the following code legal:
class A { int foo; } a;
std::vector<A> v;
This code does not currently compile because A does not have external linkage. If your first response to that is "what's external linkage, and why should I care?" then the fact that this is changed means that you won't need to care. In other words, simplifying the use of the language.
The new standard will also have standardized threading (with standardized ways to ferry exceptions across threads, the expected primitive mutex types, futures which I personally haven't seen in other languages (note: they may exist in other languages, I just haven't seen them)) easier syntax for initializing sequences like std::vector and several other improvements.
They're even going to deprecate things. Personally I'm not convinced about the deprecations, but such deprecations do make the language simpler for the user.
Does C++ 0x make it illegal to allocate memory in an formal argument to a procedure? That's a huge gotcha I would love to see eliminated, because if another argument passed to the procedure throws an exception, then it could cause a memory leak. That's a syntactic deathtrap.
void foo(int &val)
{
...
val = 1;
...
}
int myval=2;
foo(myval);
> Any programmer calling foo has no indication that > myval will change without looking at the > called program.
A programmer that calls a function that takes parameters by non-const reference should suspect that the function may do something to the parameters. It's not obvious which parameters are passed in what ways when you're reading the code later, but when you originally write the call to the function, you probably should know what you're calling.
> Does C++ 0x make it illegal to allocate memory in an > formal argument to a procedure? That's a huge gotcha I > would love to see eliminated, because if another argument > passed to the procedure throws an exception, then it could > cause a memory leak. That's a syntactic deathtrap.
> threads, the expected primitive mutex types, futures which > I personally haven't seen in other languages (note: they > may exist in other languages, I just haven't seen them))
> Does C++ 0x make it illegal to allocate memory in an > formal argument to a procedure? That's a huge gotcha I > would love to see eliminated, because if another argument > passed to the procedure throws an exception, then it could > cause a memory leak. That's a syntactic deathtrap.
One of the better programmers where I work is fond of saying that the First Amendment to the C++ Standard is "The Committee shall make no rule that prevents programmers from shooting themselves in the foot."
No, the new standard will not make this illegal. OTOH, I don't see how somebody could enforce this suggested rule in all cases (what if you allocate memory through something other than new, new[], malloc, std::allocator and related objects? Is the restriction enforced at runtime or compile time?). I've personally never had a problem with this issue because I don't expect procedures to deallocate memory that they themselves didn't allocate. So my pattern is allocate -> pass to procedure -> after procedure completes, deallocate. And then I can use a smart pointer to remember to deallocate for me at the appropriate time.
Flat View: This topic has 40 replies
on 3 pages
[
123
|
»
]
Previous Topic
