I guess it was inevitable. The Canadian invasion continues. Just like same-sex marriage is spreading to the US. Hopefully at some point they'll get it right by copying one of the single-payer health care systems around the world as well.
> The sample code will copy a and b twice, once to put them in the lambda closure, and then to pass them as arguments to do_something. Some may consider this wasteful (the easiest fix is to modify do_something to take the values as const references).
No, the easiest fix is for a & b to be moveable types, which they may well be, in which case one of those copies becomes a move, and all is right in the universe.
> So we all program in different dialects, and then scratch our heads when we read other peoples' code.
The practice of programming in dialects is more a function of the origins of the language than the size of the language. Stroustrup's most recent book does a marvelous job of demonstrating how little you have to know to program in C++ effectively: http://www.stroustrup.com/prog...
C++'s C compatibility is both its strength and its weakness, and the weakness primarily comes from people treating it as a bunch of add ons to C. If you scrap that attitude, it is entirely possible to be proficient in the language after a year of use and capable of reading most anyone's code (assuming they aren't shooting for obscurity) in another year or two. That's longer than some simpler languages, but it is hardly sufficient to excuse people's ignorance.
Perhaps not the best example of a successful software project.
Regarding repeatability: the language is fully deterministic, and compilers have as much of an incentive to be consistent as they do otherwise. If you can't get repeatable builds, then the problem is with your build environment/process more than anything else. Aside from hardware entropy sources, computers are, by design, deterministic, so if you can't reproduce a build it is because you haven't constructed a proper build closure. Certainly there is nothing about C++ that makes builds any more non-deterministic than say, C. Debian actually has a project for this: https://wiki.debian.org/Reprod..., and you may find some helpful information there. You'll notice nothing they've run in to is specific to C++.
Regarding code-to-binary structural coverage analysis. Certainly I can imagine the argument that as you get to higher and higher levels of abstraction, it becomes harder for humans to track all the transformations all the way through to assembly. One solution is to restrict the levels of abstraction you work with. I would argue that is still error prone and you are better off with using theorem prover type automated solutions (and in general, languages built around provability like ML or Coq) rather than manual verification. Even better would be to perform the verification on the compiler itself rather than the code it compiles. That said, C++ compilers do a pretty good job of tracking the origin of each bit of code they generate, which ought to make it easy to have the machine inform you of the origin of any particular code block, and C++ also does a great job of letting the programmer decide what level of abstraction they want to work with and only making the runtime pay for the abstractions they are using. Its stronger type safety also helps ensure that there aren't "hidden" code paths do to programmer error. Of course, optimizers really complicate this, so you may need to turn them off as you mentioned.
Internationalization. That sounds like an old project... one that predates the C++ standard (which means a lot of bad C habits are involved). C++ is actually very well set up for internationalization, particularly because it is so agnostic about how stings are handled. Languages like Python, Perl & surprisingly Ruby have made all kinds of unfortunate decisions around internationalization that make it look like you are fine with internationalization, but it actually blows up in your face. As an example, ICU is probably one of the foremost libraries out there, and its primary language targets are C++ & Java. The C++ target has the virtue that you can pretty much just drop in ICU strings in to a well structured C++ program and all is well in the world, where as the Java one is a bit of a pain to take advantage of (fortunately, Oracle periodically syncs the ICU code in with the JDK, but that means you have to wait for a JDK update to get the latest ICU solution).
Especially if those automated software deployment packages like SCCM are Microsoft products.
Thanks for the bug report
Those shiny distributed file systems run on top of boring local filesystems.
So tux2 was ready in 2000, and it took 14 years to rewrite it to avoid parents? Oh how much patents help innovation!
Few more years and those patents will expire and we can use both!
Tux3 is a better design. Tux2 was more along the lines of ZFS and Btrfs, that is, multiply-rooted trees sharing subtrees. Tux3 is a single tree with exactly one pointer to each extent. Considerably easier to check and repair. Of course we need to see if it turns out that way so please stay tuned.
Indeed, different aims. Tux3 has the modest goal of being a light, tight and fast filesystem without ambition of also being a volume manager.
First, it's not my site.
Second, I've never been burned by the new host. But I have been burned twice by Bruce. Why should I give Bruce a third chance to burn me?
Will soon be hosted at AltSlashdot.org or a site linked through that domain.
It will be for the Nerds, by the Nerds, focusing on the Stuff That Really Matters: The community that makes the comments the best part of Slashdot.
The name will change to avoid any trademark problems.
Some have suggested encouraging Bruce Perens to resurrect Technocrat.net for the third time. With all due respect to Bruce, the problem with that is he has shown he is not a reliable host. He has twice deleted that site, the second time without warning. I don't think we want to get burned a third time.
"When the going gets tough, the tough get empirical." -- Jon Carroll