"C++ Templates" isn't about using the STL. It's about writing templates, and how they work. It will let you understand how to build extensions to the STL, or how to design its successor, if you make the effort.
My review is online at http://www.jamesd.demon.co.uk/reviews/c++-template s.txt, if I recall correctly.
The C++ template system is a Turing-complete programming system. Yup, you can compute things using the type system at compile-time. This allows for remarkable optimizations in compiled code.
Bloat can be avoided in a number of ways, and in any case is never worse than if you wrote equivalent code without using templates.
Templates are not a super #define.
Used without understanding, templates can produce bad code. As can any other language features. Used wisely, templates can give elegant, efficient code that is is hard/virtually impossible to achieve in other ways.
I'm getting used to Mac OS X. Previous versions of Mac OS weren't going to be on any computer I owned, but Mac OS X is fine. Not as solid as Linux yet, but I can run MS Word natively and the TiBooks are nice.
Having attempted to establish my credentials as a non-MS fan (sadly I really do need to use MS Word, although OpenOffice is getting close to being compatible enough to avoid that), let me say that
1: The upgrade to 10.2 broke Mozilla's Java support for m2.
2: The upgrade to 10.2.4 broke my httpd.conf (a quick fix on each of two machines, but this is a little sloppy of Apple).
3: Each upgrade breaks sendmail (an even quicker fix, as I have a script that fixes the permissions so that sendmail will send mail for me).
Mac OS X is a lot better (for my uses) than Mac OS 9 could ever be, and in some ways it's ahead of other Unix-based systems -- but in many ways it is still somewhat immature (10.1 felt like a beta release, 10.2 fixed 90% of my problems). I'm glad Apple finally released a fairly robust OS, but it does still have some problems. As do they all.
Most compilers get more testing with optimisations enabled, so while there are bugs in optimisers there are also latent bugs exposed when the optimiser is turned off
With modern C++ code, turning the optimiser off completely can kill performance. At least some basic inlining is needed to make code work at tolerable speeds.
I run my own mail server, for a laptop which is connected to the Internet via a number of different ISPs at different times. Using a local mailserver means that I don't need to reconfigure mail clients to point at each ISP's mail server.
However, I currently do need to reconfigure the mail server because some lame ISP does block port 25, so I have to use their mailserver (which, naturally, I can't access if I'm not using their connectivity).
Port 25 filtering is an idea I've only come across recently, and appears to affect a lot of legitimate use without bothering spammers who use lax ISPs anyway.
The people who make money sending spam will pay to get to ISPs who will allow them to do so, but legitimate private users are greatly inconvenienced by ill-informed choices such as interfering at the level of packet filtering in what is a high-level protocol problem.
Given that only a few days ago I was in dialog with Mr Stroustrup regarding publicising some work he is publishing at http://www.research.att.com/~bs/applications.htm l it would be surprising to me if he had made plans to abandon his post at AT&T so suddenly.
On the other hand, AT&T research did recently shed a large number of staff, including Matt Austern, author of the fine book "Generic Programming and the STL" (fear not, Matt is now working for Apple), so who knows what's going on there.
Teaching is something Bjarne feels very strongly about, and indeed his "directions for C++0x" thoughts emphasize the importance of making C++ easier to teach.
Ah well, if this is true, a lot of FAQs will need to have updated URLs...
It might be your fault, and it's just that neither 2.9x nor 3.1 shows up the bug. Or it might, as you say, have been a bug in 3.0.x. Without seeing the code, I can't say.
If you really want a solid gcc, 3.0.4 is probably your best bet right now. The 3.0.x line has had by far the most testing of any recent version. 3.1 seems pretty good, but many regressions have been fixed "at the last minute" and there are still some known and some unknown regressions. If you want the improved conformance and better optimizers etc. then 3.1 is a good bet. If it's just stable you're looking for, then 3.0.4 is sane, or maybe 3.1.x fairly soon.
Re:Most Notable Improvements - export?
on
GCC 3.1 Released
·
· Score: 1
export is unlikely to help to reduce bloat. Coding well or using a smart compiler will do that. Compile time doesn't appear to much be affected by initial implementations of export.
Export helps to reduce header file dependencies, which is a good thing. It also makes it possible to ship template libraries without exposing implementation details as plain text.
Re:Most Notable Improvements - export?
on
GCC 3.1 Released
·
· Score: 3, Informative
Nope, the only compilers which are close to having export are the EDG-based ones. Comeau might be on sale in release (rather than beta) form this month. No released compiler has export just yet, but some are real close now. (http://www.edg.com/ or http://www.comeaucomputing.com/ for some more details if you care.)
FUD. C++ for embedded work is perfectly sensible, if the tools aren't crud. C++ is known as the second best language for any given job -- but in actual fact that often makes it the best when you've taken the non-technical factors into account.
And yes, I have used a wide range of languages professionally. I know about choosing the right tool for the job. It's just that C++ is usually eliminated, when it is, because people believe myths, not because of valid reasons (which do sometimes exist).
Who, then, do you think would pay for the standardisation process? In our capitalist world, it just about has to be funded by those who stand to gain from it.
But you're missing the fact that VC++7.0 can still generate non-.NET binaries. And the fact that it can is a Good Thing..NET isn't going to be the whole world, and for some while yet it's still a fairly small corner of it.
Sure, I'll take a crack at constructive criticism.
Most of those in the C++ standards group are employed by companies with an interest in how the standard works out. By the time it comes to voting on issues for inclusion in the standard, however, each country gets just one vote, so no company can impose its will; standardisation works by building concensus.
So, sure, Microsoft will be pushing for things which suit them. And likewise for Sun, Oracle, Comeau Computing, and any number of other companies. The ISO standards process isn't so easy to buy.
Get it right: it's both an ISO/IEC and an ANSI/ISO/IEC standard, and may well have been adopted by other national bodies as well.
The name on my copy is ISO/IEC 14882:1998, but I believe that in the US it's ANSI/ISO/IEC 14882:1998.
Cooperation between the ANSI C++ panel and the rest of the ISO C++ community is excellent, fortunately.
You're not wrong about Mr Sutter being trustworthy though, in my experience.
Re:Mmmm.... smart move, but seems a "bazaar" appro
on
Interview With Herb Sutter
·
· Score: 3, Informative
Herb is the creator and sole mind behind the "Guru of the Week" series, not just one of a panel.
He's also a moderator of comp.lang.c++.moderated, and recently has also joined the comp.std.c++ moderation panel, on which I also sit.
His "Exceptional C++" and "More Exceptional C++" books are more than just printed copies of the GotW material, which is freely available online. Exceptional C++ in particular is a fine book, and all truly serious C++ programmers should read it.
You shouldn't find it so strange that a "guy which is secretary in the standards committee" works for a company which has recently declared its intention to change its ways and produce a fully conforming C++ compiler. Their internal build supports partial specialization now, and in fact most stuff other than export. It's finally getting to be about as compliant as compilers from other companies.
Did you know that Microsoft has relatively recently rejoined the C++ standards process, and even hosted the last ISO/ANSI C++ meeting? That's quite a turnaround.
After a little initial concern, I'm pleased to have someone with Herb's integrity working inside Microsoft. Over recent months (indeed, even before Herb joined MS) we've finally seen a willingness from Microsoft to discuss the flaws of VC++, and what they plan to do about it.
We can't assume that MS will play fair forever in this area, but we shouldn't assume that they'll double-cross the community. Much though the quality (or lack thereof) in VC++ annoyed me, I'm willing to give them the benefit of what little doubt is left. VC++7.0 is a step forward, and the next release is make-or-break in terms of the credibility of MS's C++ development team. If it's up with the leading group they'll have won the (possibly grudging) respect of large parts of the C++ community. If not, they might not get another chance so easily again.
Pthreads generally are *not* implemented in user space, and they're not under Linux. Ah well.
No export in *any* C++ compiler yet
on
GCC 3.0 Released
·
· Score: 2
It's the last of the Standard features to fall. Comeau C++ is allegedly close, predicting that their compiler will support export before the end of the year, but I haven't heard anything on the gcc developer's mailing list about g++ supporting export anytime soon.
ISO C++ limits scope to the loop
on
GCC 3.0 Released
·
· Score: 1
The code you posted is legal (modulo the missing signs). The only current compiler I know which doesn't think so is MSVC++ 6, which is so far from the C++ Standard as to be a joke.
Why you think there's a problem with the Standard is a mystery to me. It's well-defined, and has been for years. There's no controversy.
g++ has a feature which allows broken code which assumes the old rules (extended scope) to work with a warning, but it always prefers the new, Standard rules.
When "audiophiles" first reported audible differences between cables, including digital interconnects, they were laughed at, until double-blind tests showed that they *could* tell the difference. Measurements showed nothing.
But then new measurements (of "jitter") came along and correlated rather nicely with the observed audio properties; the listeners provoked the measurers into improving their technique.
I approve of the goal of measurement, coupled with listening; I buy equipment which sounds good *to me*, and use measurements just to narrow the field for what I'm going to test. My system looks boring, and sounds divine. Was it worth the money? Hell yes, I grin like an idiot sometimes when listening. (Draw your own conclusions...)
Read a book which covers use of friend, and encapsulation at the component level, instead of accepting naively that the "OO way" is the one true solution. OO does not offer the best encapsulation, only the best object-level encapsulation. It's possible to do better. C++ ain't perfect, but assuming that friend harms encapsulation just because too many people misuse it is ignorance.
Slashdot Mirror
"C++ Templates" isn't about using the STL. It's about writing templates, and how they work. It will let you understand how to build extensions to the STL, or how to design its successor, if you make the effort.
e s.txt, if I recall correctly.
My review is online at http://www.jamesd.demon.co.uk/reviews/c++-templat
The C++ template system is a Turing-complete programming system. Yup, you can compute things using the type system at compile-time. This allows for remarkable optimizations in compiled code.
Bloat can be avoided in a number of ways, and in any case is never worse than if you wrote equivalent code without using templates.
Templates are not a super #define.
Used without understanding, templates can produce bad code. As can any other language features. Used wisely, templates can give elegant, efficient code that is is hard/virtually impossible to achieve in other ways.
I'm getting used to Mac OS X. Previous versions of Mac OS weren't going to be on any computer I owned, but Mac OS X is fine. Not as solid as Linux yet, but I can run MS Word natively and the TiBooks are nice.
Having attempted to establish my credentials as a non-MS fan (sadly I really do need to use MS Word, although OpenOffice is getting close to being compatible enough to avoid that), let me say that
1: The upgrade to 10.2 broke Mozilla's Java support for m2.
2: The upgrade to 10.2.4 broke my httpd.conf (a quick fix on each of two machines, but this is a little sloppy of Apple).
3: Each upgrade breaks sendmail (an even quicker fix, as I have a script that fixes the permissions so that sendmail will send mail for me).
Mac OS X is a lot better (for my uses) than Mac OS 9 could ever be, and in some ways it's ahead of other Unix-based systems -- but in many ways it is still somewhat immature (10.1 felt like a beta release, 10.2 fixed 90% of my problems). I'm glad Apple finally released a fairly robust OS, but it does still have some problems. As do they all.
Some reasons we use optimisation by default:
With modern C++ code, turning the optimiser off completely can kill performance. At least some basic inlining is needed to make code work at tolerable speeds.
They don't block all port 25 traffic; just port 25 traffic either
Their own mailservers, it is hoped, will accept outgoing mail only from their own customers and incoming mail only if it is to their own customers
I run my own mail server, for a laptop which is connected to the Internet via a number of different ISPs at different times. Using a local mailserver means that I don't need to reconfigure mail clients to point at each ISP's mail server.
However, I currently do need to reconfigure the mail server because some lame ISP does block port 25, so I have to use their mailserver (which, naturally, I can't access if I'm not using their connectivity).
Port 25 filtering is an idea I've only come across recently, and appears to affect a lot of legitimate use without bothering spammers who use lax ISPs anyway.
The people who make money sending spam will pay to get to ISPs who will allow them to do so, but legitimate private users are greatly inconvenienced by ill-informed choices such as interfering at the level of packet filtering in what is a high-level protocol problem.
I've read it in e-mail from Bjarne, it's true.
He'll still have ties to AT&T though, so maybe we won't have to update all of those links after all.
Given that only a few days ago I was in dialog with Mr Stroustrup regarding publicising some work he is publishing atm l it would be surprising to me if he had made plans to abandon his post at AT&T so suddenly.
http://www.research.att.com/~bs/applications.ht
On the other hand, AT&T research did recently shed a large number of staff, including Matt Austern, author of the fine book "Generic Programming and the STL" (fear not, Matt is now working for Apple), so who knows what's going on there.
Teaching is something Bjarne feels very strongly about, and indeed his "directions for C++0x" thoughts emphasize the importance of making C++ easier to teach.
Ah well, if this is true, a lot of FAQs will need to have updated URLs...
It might be your fault, and it's just that neither 2.9x nor 3.1 shows up the bug. Or it might, as you say, have been a bug in 3.0.x. Without seeing the code, I can't say.
If you really want a solid gcc, 3.0.4 is probably your best bet right now. The 3.0.x line has had by far the most testing of any recent version. 3.1 seems pretty good, but many regressions have been fixed "at the last minute" and there are still some known and some unknown regressions. If you want the improved conformance and better optimizers etc. then 3.1 is a good bet. If it's just stable you're looking for, then 3.0.4 is sane, or maybe 3.1.x fairly soon.
export is unlikely to help to reduce bloat. Coding well or using a smart compiler will do that. Compile time doesn't appear to much be affected by initial implementations of export.
Export helps to reduce header file dependencies, which is a good thing. It also makes it possible to ship template libraries without exposing implementation details as plain text.
Nope, the only compilers which are close to having export are the EDG-based ones. Comeau might be on sale in release (rather than beta) form this month. No released compiler has export just yet, but some are real close now. (http://www.edg.com/ or http://www.comeaucomputing.com/ for some more details if you care.)
FUD. C++ for embedded work is perfectly sensible, if the tools aren't crud. C++ is known as the second best language for any given job -- but in actual fact that often makes it the best when you've taken the non-technical factors into account.
And yes, I have used a wide range of languages professionally. I know about choosing the right tool for the job. It's just that C++ is usually eliminated, when it is, because people believe myths, not because of valid reasons (which do sometimes exist).
Who, then, do you think would pay for the standardisation process? In our capitalist world, it just about has to be funded by those who stand to gain from it.
But you're missing the fact that VC++7.0 can still generate non-.NET binaries. And the fact that it can is a Good Thing. .NET isn't going to be the whole world, and for some while yet it's still a fairly small corner of it.
Sure, I'll take a crack at constructive criticism.
Most of those in the C++ standards group are employed by companies with an interest in how the standard works out. By the time it comes to voting on issues for inclusion in the standard, however, each country gets just one vote, so no company can impose its will; standardisation works by building concensus.
So, sure, Microsoft will be pushing for things which suit them. And likewise for Sun, Oracle, Comeau Computing, and any number of other companies. The ISO standards process isn't so easy to buy.
Get it right: it's both an ISO/IEC and an ANSI/ISO/IEC standard, and may well have been adopted by other national bodies as well.
The name on my copy is ISO/IEC 14882:1998, but I believe that in the US it's ANSI/ISO/IEC 14882:1998.
Cooperation between the ANSI C++ panel and the rest of the ISO C++ community is excellent, fortunately.
You're not wrong about Mr Sutter being trustworthy though, in my experience.
Herb is the creator and sole mind behind the "Guru of the Week" series, not just one of a panel.
He's also a moderator of comp.lang.c++.moderated, and recently has also joined the comp.std.c++ moderation panel, on which I also sit.
His "Exceptional C++" and "More Exceptional C++" books are more than just printed copies of the GotW material, which is freely available online.
Exceptional C++ in particular is a fine book, and all truly serious C++ programmers should read it.
You shouldn't find it so strange that a "guy which is secretary in the standards committee" works for a company which has recently declared its intention to change its ways and produce a fully conforming C++ compiler. Their internal build supports partial specialization now, and in fact most stuff other than export. It's finally getting to be about as compliant as compilers from other companies.
Did you know that Microsoft has relatively recently rejoined the C++ standards process, and even hosted the last ISO/ANSI C++ meeting? That's quite a turnaround.
After a little initial concern, I'm pleased to have someone with Herb's integrity working inside Microsoft. Over recent months (indeed, even before Herb joined MS) we've finally seen a willingness from Microsoft to discuss the flaws of VC++, and what they plan to do about it.
We can't assume that MS will play fair forever in this area, but we shouldn't assume that they'll double-cross the community. Much though the quality (or lack thereof) in VC++ annoyed me, I'm willing to give them the benefit of what little doubt is left. VC++7.0 is a step forward, and the next release is make-or-break in terms of the credibility of MS's C++ development team. If it's up with the leading group they'll have won the (possibly grudging) respect of large parts of the C++ community. If not, they might not get another chance so easily again.
Pthreads generally are *not* implemented in user space, and they're not under Linux. Ah well.
It's the last of the Standard features to fall. Comeau C++ is allegedly close, predicting that their compiler will support export before the end of the year, but I haven't heard anything on the gcc developer's mailing list about g++ supporting export anytime soon.
The code you posted is legal (modulo the missing signs). The only current compiler I know which doesn't think so is MSVC++ 6, which is so far from the C++ Standard as to be a joke.
Why you think there's a problem with the Standard is a mystery to me. It's well-defined, and has been for years. There's no controversy.
g++ has a feature which allows broken code which assumes the old rules (extended scope) to work with a warning, but it always prefers the new, Standard rules.
When "audiophiles" first reported audible differences between cables, including digital interconnects, they were laughed at, until double-blind tests showed that they *could* tell the difference. Measurements showed nothing.
But then new measurements (of "jitter") came along and correlated rather nicely with the observed audio properties; the listeners provoked the measurers into improving their technique.
I approve of the goal of measurement, coupled with listening; I buy equipment which sounds good *to me*, and use measurements just to narrow the field for what I'm going to test. My system looks boring, and sounds divine. Was it worth the money? Hell yes, I grin like an idiot sometimes when listening. (Draw your own conclusions...)
1. Timing errors of 100s of picoseconds are audible, astonishingly.
2. Linn already make music distribution systems which use Cat5 cable, I believe.
Read a book which covers use of friend, and encapsulation at the component level, instead of accepting naively that the "OO way" is the one true solution. OO does not offer the best encapsulation, only the best object-level encapsulation. It's possible to do better. C++ ain't perfect, but assuming that friend harms encapsulation just because too many people misuse it is ignorance.