ISO C++ Committee Approves C++0x Final Draft 375
Randyll writes "On the 25th, in Madrid, Spain, the ISO C++ committee approved a Final Draft International Standard (FDIS) for the C++ programming language. This means that the proposed changes to the new standard so far known as C++0x are now final. The finalization of the standard itself, i.e. updating the working draft and transmitting the final draft to ITTF, is due to be completed during the summer, after which the standard is going to be published, to be known as C++ 2011. With the previous ISO C++ standard dating back to 2003 and C++0x having been for over eight years in development, the implementation of the standard is already well underway in the GCC and Visual C++ compilers. Bjarne Stroustrup, the creator of C++, maintains a handy FAQ of the new standard."
Yay for C++'0B (Score:2, Redundant)
Enough said!
-Chris
Re: (Score:2)
WTF People?! Rename it already!.. The 201th decade is over, 202 is here!
Re:Yay for C++ 0x7DB; // FTFY (Score:5, Insightful)
Enough said!
-Chris
Incorrect. The year 2011 A.D. is 7DB Hexadecimal A.D. Ergo, if you're going to abbreviate the numeral using the last two digits you should be heralding C++'DB or simply shorten it to C++'B.
Note: Due to the fact that legacy versions are abbreviated as YEAR mod 100 in radix (base) 10, the new hexadecimal notation should include the a prefix or suffix indicating the radix in use. For quite some time there has existed such a hexadecimal radix prefix in C and C++: 0x
Thus: /* WTF! */ };
Hurray for C++ 0xB;
(Also note the above line does not parse as valid statement in C++, even though the ++ operator actually does take a dummy int parameter as the right-hand-side to differentiate it from the ++C; prefix increment operator.
operator++(int){
For meatball's sake people, even the ++ operator is a kludge in C++? [wikipedia.org] ( "C++" translates to "C (with kludges)" to me.)
Even without any #define macros present, I still can't tell what a single snippet of C++ code is going to do. (Does the simple statement: C++; open a temporary file, and record the number of increments or throw an exception? Should I wrap all such statements in a try / catch block!?) If you haven't studied the entire inheritance graph of the type that the C variable is declared as, there is really no way (beside a debugger) to know what will happen next. (What if a pointer is to a polymorphic class? *my_ptr->operator++(42); Now, it's not supposed to do anything with that "dummy" 42 value, the base type doesn't but a subclass might...)
Don't get me wrong, I code in C++ every day, and prefer it to C, but it surprises me just how messed up things have been allowed to get because we're shoe-horning in features into an existing syntax instead of just creating a new language that has less kludges.
int main() { //Constructed an int "object" by calling it's "constructor" // DOES NOT call the int object's empty constructor. // ERROR, the previous line declares a function. ... }; ARGH.
int my_var_a( 1 );
// ^^^ Uh.. OK ints are object-ified now.
int my_var_b();
my_var_b = 10;
return my_var_a;
}
^^^^^^ Declares a new function in the function/method body WTF? (because C lets you do that, for better or worse... )
use: int myvar; to "instantiate" a new int "object" using the empty constructor instead... So, why can't I subclass an int? class my_number : public int {
Look, it's clearly time to stop hacking extra features into the language, or stop letting it be hindered by legacy C conventions / syntax. I think that C++ could be much better than it is if it weren't pandering to C coders... It's too bad that we started down that path with C++, there's far too much time and energy invested to reboot it now.
I'm glad for some of the new C++ features, but at this point there's not much to celebrate for me -- Doing without for so long has caused us to create our own systems: the C++0x garbage collector is incompatible with my multi-threaded hybrid strategy (pool / slab & heap-like) memory manager (thank Spaghetti Monster, theirs is optional), I already have a ton of code that uses my cross platform multi-threading libraries, we've been using a HashContainer for over 10 years in our company...
C++0x7DB adoption to us means: "Oh great, they finally got around to standardizing all these things we've needed for years and made ourselves -- It's going to be a headache writing new code that conforms to the new standard while remaining compatible with our current code-base."
(And there was much rejoicing: "... yay... ")
Re: (Score:2)
Even without any #define macros present, I still can't tell what a single snippet of C++ code is going to do. (Does the simple statement: C++; open a temporary file, and record the number of increments or throw an exception?
to be fair, all the other 'oo' languages don't let you do that either, and C can give you the same problems if you're using #defines (C's equivalent to operator overloading :) )
At least in C++, you can look at the header file for the class definition and see what its doing. In languages
Re: (Score:3)
Just as a side note, regarding "objectified int" - the term "object" in C++ standard actually comes from plain C, and doesn't have much to do with objects in OO sense. I'll just quote the C99 spec:
3. Terms, definitions, and symbols ...
For the purposes of this International Standard, the following definitions apply.
3.14 object
region of data storage in the execution environment, the contents of which can represent values
Re: (Score:2)
Enough said!
-Chris
Olly Olly 0x 'an C
Like a zombie (Score:3, Insightful)
C++ just keeps on going, eating the brains out of anyone who dares to use it. When template metaprogramming was invented, the language should have been internationally banned by treaty. Now with lambdas, garbage collection, rvalue references, and a host of other features, C++ should be officially classed as a Weapon of Mass Destruction.
Re: (Score:2)
C++ should be officially classed as a Weapon of Mass Destruction
It's also a Cruel and Unusual Punishment for those of us who try to earn a living writing code.
Re: (Score:2)
Now with lambdas, garbage collection, rvalue references, and a host of other features, C++ should be officially classed as a Weapon of Mass Destruction.
That's why C++ is so awesome - it's a WMD that can be wielded by a single man. Granted, this gives the whole new meaning to the expression "shoot your own foot", but once you get past that, you can shoot so many other things in very spectacular way!
I only hope that user-defined literals are still in (there was a proposal to take them out). ~
Re: (Score:2)
you can shoot so many other things in very spectacular way!
The most popular is shooting the guy who maintains your old code, in the head, by his own hand.
Re: (Score:2)
It's so easy it's not even sporting. You don't even need C++ for that.
Bonus points for tucking it away into some build script as a compiler switch instead. Double bonus when build scripts are generated.
None of your business! (Score:5, Insightful)
Yes, you hate C++. We get it. Instead of complaining about it so much, just don't use it, stick to your own favorite language, whatever it may be, and leave C++ alone. There are plenty of us who love C++ and wouldn't give it up for anything. We mind our own business, write great code, and try to avoid complaining about whatever it is you are using. Please try to do the same.
Re: (Score:2)
Re: (Score:2)
There are many places where anything other than C++ simply doesn't make sense.
Example Please.
The entire Linux kernel is written in pure C. Just where and in what circumstance are you talking about?
Re:None of your business! (Score:4, Funny)
How fucking dare anyone out there make fun of C++ after all it has been through!?
What you don't realize is that C++ is making you all this money, and all you do is write a bunch of crap about it!
Leave Bjarne alone!! You're lucky he even publishes an FAQ for you BASTARDS!!
Speaking of professionalism, since when is it professional to publicly bash a language whose standard is going through a hard time?
Anyone that has a problem with C++ you deal with ME, because it's not well right now!
Re:Like a zombie (Score:5, Informative)
C++ just keeps on going, eating the brains out of anyone who dares to use it. When template metaprogramming was invented, the language should have been internationally banned by treaty. Now with lambdas, garbage collection, rvalue references, and a host of other features, C++ should be officially classed as a Weapon of Mass Destruction.
It's because there isn't a good replacement for it. The only programming language that I know of that _really_ replaces C++ is D, I did a bit of research on it a while ago, it's great. Better than the C++ language in almost every aspect. But D has problems as well, just not in the language design department. There is no working D IDE, you can't find a lot about it online, the language has not 100% stabilized yet, only has backwards compatibility with C, and many other things that we take for granted in the C++ language.
Anyway, what I'm trying to say is that D is a well designed language that could potentially replace C++ better than any other language.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
C++ may give you enough rope to hang yourself, but you are the one putting your head in the noose.
Not if you work for a large software company. Some idiot could use c++ to write incomprehensible code, then leave or be sacked. You get the job of maintaining the ever so clever rubbish he left behind.
Re: (Score:2)
Not if you work for a large software company. Some idiot could use c++ to write incomprehensible code, then leave or be sacked. You get the job of maintaining the ever so clever rubbish he left behind.
For you guys that think C++ is hard or incomprehensible, please, for the good of mankind, change your line of work. You're not worthy of calling yourselves programmers.
You know, I have to say I've been a professional programmer for 15 years. And, in fact, C/C++ is in many ways my preferred language. That said, I have to agree with GP. While I love C/C++, I have never run across any other language (that's actually used, please don't mention malboge and the like) where a programmer can so easily obfuscate his code WITHOUT INTENDING TO. No, C++ is not hard or incomprehenisble, if used right. But there are coders out there who seem to have a knack for taking the beautifu
Re: (Score:2)
Perl. And this is from someone who sees Perl as the first solution for everything (C/C++ as second).
I have blocked my few experiences of maintaining Perl code completely from my memory. *shivers*
Important note: I love C. I was just noting that I can easily understand how young programmers who had unfortunate experiences in their first legacy C++ code could be traumatized for life.
Re: (Score:2)
I've worked on a couple of C++ compilers and implemented the RTTI / exception handling runtime for C++. There's nothing like implementing the language to make you hate it. I thought that the designers were sadists who hated the people who would use their creation, but I think they hated the people were expected to implement it.
I've also worked on compilers for C, Objective-C, Smalltalk and JavaScript, but C++ is the only one that has a specification that is almost impossible to implement correctly (and,
Re: (Score:2)
There are so many design philosophies out there - going way beyond whether you put the opening { on the same line as the function name or else. These are just fourteen I can recall:
o Separate dll's vs separate static libraries
o Separate directories for each class
o Separate header/source files for each class
o Inheritance vs class member objects
o inline functions or not
o use of STL vs Boost vs own templates
o multiple template class types
o Use of smart pointers
o enum's vs defines
o The use of class identifiers
Re: (Score:2)
next version, we get rid of pointers :P
You say this like it is a joke, but it is actually not so terrible an idea. Dumb pointers introduce a whole host of ways for things to go wrong, and in a lot of cases the compiler is in a position to create a pointer for you (see: Common Lisp) when it is truly what you need. If you are writing code at the lowest level, then sure, you need pointers and it would be st
Re: (Score:2)
Re:Like a zombie (Score:5, Insightful)
Or for the projects where having to manage every allocation and deletion is tedious and gets in the way of actually implementing a program.
you know, for folks that never understood what RAII (Resource Acquisition Is Initialization) is or how to use it.
C++ offers both dumb pointers (for those rare occasions when you actually need them) and smart pointers, and C++0x will offer vastly improved smart pointers (shared_ptr)--currently available in Boost, and one of the best reasons for using Boost up until now.
People who insist on writing C++ as if it were a mildly enhanced form of C have no one to blame but themselves for the problems they encounter.
It is a valid complaint that C++ makes creating dumb (dangerous) pointers so much easier than smart pointers, but then if you use RAII for your classes more broadly, the need for pointers of any type is usually greatly reduced. Why, you can create whole complex structures of trees of lists of sets of strings, modify them wildly on-the-fly, and never once have to worry about pointers or allocation or deallocation.
There are plenty of reasons to complain about C++. The language is full of warts, and has some really tedious and error-prone corners. But if your complaint is simply about overuse/abuse of pointers leading to memory leaks, Ur Doin' It Rong(tm)!
Re: (Score:2)
you know, for the folks that never understood what a memory leak is.
It's like wikileaks, but with memristors instead of wikis
Re: (Score:3)
One of the main reasons why C/C++ are so popular is precisely the reason why there are so many complications with it. It's fast; it deals at a low level and gives you full control over what you're doing. Want something bounds-checked? Bounds check it. Don't want it bounds-checked? Don't bounds-check it. This sort of stuff falls over to assignment operators. A higher-level language, when you assign from rhs, will generally just automagically duplicate all member arrays and objects, even strings. Do y
That's what C++0x means (Score:2)
I've been reading about C++0x for years now, and never realized that the 0x referred to a new revision of C++ to be released in 200X, until I just now saw the FAQ entry about C++1x. I assumed it was some odd inside reference to hex number prefix that I just didn't get. I thought the Y2K bug incident had purged everyone who didn't use full dates :)
My first question. (Score:2, Interesting)
Re:My first question. (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)
This is what I call the lawyer talk. I don't want a run around. I am not checking for size() == 0. I need to know the number of elements in the list. The standards allow splice() to be O(N). Most people expect size() to be O(1) that is how they interpret the standards. Making splice() O(N) to give size() in O(1) is the reasonable and user friendly thing to do. Hiding behind opaque english, using lawyer talk and blaming the user is antagonizing the user.
Mate, you need to pay attention to your own sig. The C++ standard is clear on where big O performance is prescribed. Where it is not, don't make assumptions. This is not some grand conspiracy against you, just suck it up and fix your code.
Re: (Score:3)
No, that's not reasonable. If std::list doesn't track size internally, it is still possible to have an O(1) size() equivalent by tracking it yourself. If it does track size internally, it becomes impossible to have an O(1) splice() equivalent. That's very important for moving sections of memory around in a resource-constrained environment.
Re: (Score:2)
The reason behind is easy. When one use a lnked list, one usually does not need to know its size frequently. Therefore counting the number of element is pretty much redundant and a performance hog in most application.
If you really need to know the size of the list, then you can do the accounting manually. It is not hard at all to do.
I am personnally very happy that std::list does not know its size. Because I never need this information and I would hate having to rewrite list just to kick the accounting out.
Re: (Score:2)
Actually, the reason why size() is O(N) in gcc is because, if you have a counter in the list itself, then splicing [microsoft.com] the tail of another list into yours becomes an O(n) operation (because you need to count how many elements are there to splice to update the counter). Thus, you either have O(1) size(), or O(1) splice(), but not both. VC and gcc had different ideas about which one of those operations is more common.
Having the counter itself is hardly a space or performance hog, especially given that std::list i
Re: (Score:2)
The lack of a singly-linked list is aggravating, but I'm guessing the reason for not providing one was that simple things like deleting a specified node blow up to O(N) because of the need to update a pointer in the inaccessible (except by iterating from the beginning) preceeding node. I.e., if there's no elegant way to do a simple thing, just don't provide it at all, and tag everybody with the overhead of a doubly-linked list and its often superfluous back-pointers.
Anyway, thanks to the Powers That Be for
Re: (Score:2)
When one use a lnked list, one usually does not need to know its size frequently. Therefore counting the number of element is pretty much redundant and a performance hog in most application.
The implementation is a doubly linked list. Setting a backwards pointer on every element is pretty much redundant and a performance hog in most applications, that only iterate forwards.
Re: (Score:2)
Re: (Score:2)
most porting operation leads to stupid bugs or behavior like that.
Who ports these days? Java is more portable by virtue of the VM. C is more portable by virtue of its simplicity.
Re: (Score:2)
Re:My first question. (Score:4, Interesting)
Re: (Score:2)
Leaping into the middle of the conversation: why? It seems like you could implement caching logic like:
Voila. size() is O(1) almost always, except immediately after a splice(). In the worst case, it'd be O(n) immediately after a splice(), but only the fi
Re: (Score:2)
Because undefined (as in changing depending on the circumstances) complexity is worse than "always the same but depending on the implementation".
Re: (Score:3)
Because undefined (as in changing depending on the circumstances) complexity is worse than "always the same but depending on the implementation".
I'm sorry, but I reject that outright. Optimizing compilers have been surprising us with unexpected gains for years, but as long as they don't worsen the situation, no one minds. I can't think of a situation where an optimization that falls back to the default behavior in the absolute worst case but offers a nice speedup in others is a bad thing.
I don't claim that I'm a supergenius and that I spent 30 seconds solving a problem that the libstdc++ guys have been working on for years, but I don't accept that t
Re: (Score:2)
It's easy to wrap std::list to do that yourself. What you propose would mean that if you get a list passed from some other opaque part of the code you have no way to predict whether size will be O(1) or O(n), because it may or may not be the result of a splice.
Plus like it is now allows the spec to make simple and clear complexity promises (list::size() is O(n), splice is O(1)) without having to specify how the implementation should work in too much detail.
Re: (Score:3)
Plus like it is now allows the spec to make simple and clear complexity promises (list::size() is O(n), splice is O(1)) without having to specify how the implementation should work in too much detail.
If you still document it as being O(n), but it's actually O(1) most of the time, I promise you no one will mind.
Re: (Score:2)
It would be unpredictably awesome. Suppose you have a million splice() calls that insert one item each, followed by a million size() calls. If size() is O(1) and splice is O(n), that would require about a million list traversals and about 500 billion (sum([1..1,000,000])) visits to items in the list. If size() is O(n) and splice() is O(1), that would take a million list traversals and a trillion visits. In my algorithm, size would be O(n) once and O(1) every other time, for exactly one traversal and one mil
Re:My first question. (Score:5, Insightful)
Will they resolve the question of std::list::size() function's speed?
Yes. From the most recent C++0x FCD, 23.l2.1[container.requirements.general] table:
Expression: a.size()
Return type: size_type
Operational semantics: distance(a.begin(), a.end())
Assertion/note pre-/post-condition: -
Complexity: constant
Re: (Score:2)
Re: (Score:3)
Seems to be N2909 [open-std.org], revised as N2923 [open-std.org], and voted into the draft [open-std.org] in July 2009.
On a side note, the new std::forward_list does not have size() at all, so for those scenarios where having size is superfluous (either because you don't want to pay the overhead of an extra size_t for an empty list, or because you want to splice ranges), you can use forward_list for best performance.
Re: (Score:3, Interesting)
Re: (Score:2)
SGI docs do not represent the Standard, however.
Re:My first question. (Score:4, Interesting)
Re: (Score:2)
size() should not be a member of std::list at all if the O(n) crowd is to be listened to, for its inclusion is then only a trap to be fallen into.
Thank you Bjarne (Score:3)
Re:Thank you Bjarne (Score:4, Interesting)
Re:Thank you Bjarne (Score:4, Funny)
Stroustrup C++ 'interview' (Score:5, Funny)
http://www-users.cs.york.ac.uk/susan/joke/cpp.htm
This one still makes me laugh
D is C++ redesigned (Score:5, Interesting)
Given all the negative comments about the complexity and misfeatures of C++, I one day decided to take a good look at D programming language [wikipedia.org].
I know Ruby, Python and Common Lisp, and as I have used Ruby's NArray and NumPy quite much, I appreciate that D language has first class Array objects and vector operations for arrays built into the language. D is also compatible with C and has two-way bridge for Objective-C. The version 2 also supports functional programming.
Overall, D seems to have taken good influences from dynamic programming languages like Ruby and Python.
I wonder why D isn't more popular? Maybe the division of the standard libraries is a big factor?
PS. I have been looking a similar library to NumPy for Common Lisp, but GSLL just doesn't cut it and Matlisp only handles two-dimensional matrices. Of course you can use map, but iterating even slices of two-dimensional matrices with map can be a hassle and is much more verbose than having a good iterator abstraction.
Re: (Score:2, Interesting)
I like D as well. The elimination of many screwy cases from C++ and ability to just link up with C or ASM object files for speed is very nice.
It takes time for languages to gain followers, tools, maturity and stability. Python was started in the early 90s. Ruby was in 1995. I hope D and Perl 6 both become at least semi-mainstream programming languages.
Re:D is C++ redesigned (Score:4, Interesting)
D is not as popular because it largely only appeals to C++ developers who want a better C++. However, unlike C++, D is not standardized by any standards body, so the language can change on a whim by the author. There is also only one real implementation of D, as opposed by having support by multiple vendors (most likely, this is a function of its lack of standardization. Corporations don't want to take on writing compilers for non-standard languages).
Certainly, lack of standardization hasn't prevented other languages, such as Java in the past, but look what happened there. Microsoft was litigated out of the market, and now Oracle is sueing Google and possibly others. This is not very commercial compiler friendly.
There would likely be questions of intellectual property that need to be answered, and grants or licenses of such IP to ensure that third party vendors won't get sued. Yes, I know they say it's open source, but i doubt it has had a full audit and due dilligence done on whether or not it violates any IP.
Don't get me wrong, what they've done with D has been fantastic. I think Walter needs to seriously consider submitting it to a standards body if he wants to go anywhere with it.
Re: (Score:2)
Also, before anyone climbs down my throat about the gnu d compiler and the .net d compiler, these are really just ports of the main D code, not entirely new implemenations. That's what I meant by only one real implementation.
Nice! (Score:3)
As someone who spends all day developing a C++ library for massively parallel engineering simulation.... I'm really excited about this announcement. My team has played with some of the early C++0x features in Intel's compiler and GCC and we're definitely going to be adopting a few of them, but can't commit ourselves until they are a bit more universally available.... which now, they hopefully will be.
C++ certainly still has it's strong points over many other languages... especially when you need that cross section of good OO design and performance (like we do). There are many things I love using Python for but there a also a TON of times I need complete control over everything in order to get the most out of the machine I'm using.
Re: (Score:2)
Machine code. It's not as difficult as you think, I have a bunch of macros and a program that just reads in the macros and outputs the machine code. I modify the macros for each hardware platform -- Our "cross-compile" process scales in O(n) time!
I scoff at Assembly Language programmers because they have to use a "compiler" which frequently doesn't support every op-code/instruction the machine has to offer. The instructions are just sitting there, wasting power unless you use them!
In C or C++, Pytho
++curmudgeon; (Score:5, Funny)
Ah, it's articles like this that make me so glad I'm retired!
C++ programmers have it too easy. Why, in C we had to code our own bugs. C++ programmers just inherit them!
Still no designated initializers (Score:2)
Some monster warts not addressed, like no designated intializers, no flexible arrays. Some backwards progress like the idiotic narrowing errors in cases like { 1, 2 } for an array of floats. But in general, a better language, I switched to -std=gnu++0x a few months back.
Re: (Score:2)
Re: (Score:2)
I did indeed mean flexible arrays. I did not know about std::array, maybe it really is always better than classic C arrays. But I am skeptical, I will try it and see. In any case, there is no plausible excuse for not supporting variable arrays, especially in their role as function arguments. They are required for C99 anyway, which typically uses the same back end as C++.
Re: (Score:2)
I use them for a number of applications including 3D rendering and 2D filtering. In C++ such code gets ugly fast if you have to compute multidimensional indices by hand. Even buried in helper methods its still ugly and less maintainable than the C incarnation. I typically write code like that in C and call it from C++. This introduces its own awkwardness.
Okay, but.... (Score:2)
How do you pronounce 'C++0x', and why does my modem keep resetting when I type it?
Re: (Score:2)
How do you pronounce 'C++0x', and why does my modem keep resetting when I type it?
The answer to both is the same: nerdgasm
Woopdeedoo (Score:2)
That's like that couple who has been together for 20 years
and has a couple of high-school age kids
telling you that they just decided to get married.
Job interviews (Score:2)
Brilliant. It was bad enough in job interviews when they try to catch you out on your knowledge of the obscure bits of C++ that nobody ever uses, and now there's a whole new level of complex syntax, pitfalls and gotchas to deal with. C++ is turning into a warty freakshow. I could even start to forgive Python's idiotic indentation nonsense at this rate.
Re:Question (Score:4, Insightful)
As someone who has written software using GObject, FUCK YOU.
Re: (Score:3, Interesting)
I think you can easily determine the competence of any programmer by how much they hate their primary language. I've never seen this rule fail when it comes to C++. Almost every expert modern C++ programmer I've met thinks C++ is unsurpassed in a few important areas - yet they can bitch about the language for as long as you keep them talking.
Re: (Score:2)
Re: (Score:2)
My collection of C++ books from Addison Wesley (who has apparently cornered the market for C++ books above intro level) has just become obsolete.
Yeah, if only they had spent an entire decade making sure that it was fully backwards compatible. It sucks how C++ just completely throws out compatibility, like that time when they threw out compatibility with existing C code to make the language easier to maintain.
Re: (Score:2)
There's probably another year or two before you can expect the latest version of MSVC to have support for most of the features (and that's if they even get it into the next version!)
There are already quite enough C++0x features in VC++2010 to invalidate a lot of old techniques and rules: it has lambdas, rvalue references, and decltype/auto. Lambdas make STL much more attractive to use, so you're going to see more of that (but that should be covered well by existing books, and lambdas themselves are easy to understand). But rvalue references and decltype open a whole new dimension for generic code and template metaprogramming. Combined with new rules for SFINAE, you can now make substit
Re:sigh (Score:4, Interesting)
Thanks to g++, I've been coding in C++0x for months. Programming without it has now become painful. 0x is such a huge leap. I love, love things like:
while (true) thread( [](shared_ptr p){ p->process(); }, Packet::read()).detach();
That's a one-line network subsystem ;) In a loop, hang until you can read a packet, then process it in its own thread, continue reading new packets while it processes, and when a given packet finishes processing, delete it. Your "Packet" base class simply requires a factory read() method and a virtual process() function.
The only "gotcha" for me was that you still have to link in pthread.
Thread pairs very nicely with lambdas. Shared pointers were already fine in Boost, but it's nice to be able to ditch boost where possible. I can't wait for futures to make it into g++ as part of the c++0x standard. Futures + lambdas = trivial inline threading of arbitrary statements.
Re: (Score:2)
Actually I'm looking forward to re-learning C++ after GCC et. al. are updated and the spec is finalized. They've added a great deal to the standard libraries, the syntax, and the collections/containers since I last worked with C++. I've no need for C++ -- it's just something I want to do for fun.
Re: (Score:2)
Actually I'm looking forward to re-learning C++ after GCC et. al. are updated and the spec is finalized. They've added a great deal to the standard libraries, the syntax, and the collections/containers since I last worked with C++. I've no need for C++ -- it's just something I want to do for fun.
Have at it. If I have to use C++ I'll stick to LLVM/Clang/LLDB/Libc++
Re: (Score:2)
It's time to move on.
If you want to write efficient code (have control of all allocations, etc) with some OOP sugar, C++ is a fairly decent choice...
And with some coding guidelines, C++ is not bad for application development either... I would rather use Qt/C++ than C#/Windows.Forms for GUI applications... Mainly because of Qt though, but C++ is not dead... It's a perfectly fine tool for many projects... Choose a tool that is right for the job...
And C++ is certainly still an important tool, what other well established fairly-
Re: (Score:2)
And yet despite all the hype I find C# incredibly more cumbersome and verbose and when I'm at work I truly can't wait to get home to work on my c++ hobby project. Part of it will be in javascript too, because it is better for some of the parts of my project.
There is no such thing as an universally simpler and better language, and some of c++ features that people love to hate such as RAII, templates (not those half-assed generics that c# offers) and operator overloading permit to make some complicated things
Re: (Score:2)
Scheme, Java, Ruby, Python, D, C.
I can't understand why anyone would start a new project in C++. The only reason anyone could seriously consider it is if they have to maintain or enhance an existing C++ code base.
Re: (Score:2)
I can't understand why anyone would start a new project in C++. The only reason anyone could seriously consider it is if they have to maintain or enhance an existing C++ code base.
While I agree with the sentiment, the reason people keep using C++ is pretty clear: habit. Everyone knows C++ or some very similar language, there is a lot of legacy C++ code, and people are still being trained to write code in C++ (or some similar language). If you were starting a new project and you said, "Let's use Scheme," half the people in the meeting would say they had never written a single Scheme program, and that they did not have time to learn it, and that it would be easier to just use C++
Re: (Score:2)
Do not underestimate the friction that you face when it comes to C++ and similar languages.
I was in exactly this situation this week on a training course where we had ~12 hours to do an entire project.
We had 1 non-programmer on the team (of 6), one "software architect" and the other 4 of us were "software engineers." 4 of them wanted to use C++. I convinced them to do it in bash. Only one had sort of done some bourne shell a long time ago.
We got it done, and it worked. If we'd done it in C++ I dare say
Re: (Score:2)
Neither Java, Ruby nor Python are true contenders to C++ when it ever comes down to raw performance. They are surely more elegantly designed languages, although they have their own sets of flaws. D is an interesting language with many good ideas, but there's no decent IDE support for it and there's the standard library confusion as well (and the incompatibilities between D1 and D2). Once compilers like GDC are mature enough it'll actually be usable for serious work.
Well, C is sort of fine if you stick to re
Re: (Score:2)
C++ sits in an area that is reasonably unique amongst languages. It is very performant (unlike Scheme, Ruby, and Python), but it also has an ability to support very rich abstractions (unlike Java and C).
True, but it hasn't been done at all well in C++. That's why I said that C++ had to happen so that people could see which ideas would work and which wouldn't.
I'm not at all convinced by these arguments. I'd much rather write performance-critical code in something like C, and the clever stuff in a much hig
Re: (Score:2)
^ this
A lot of people seem to be very black-and-white when it comes to C++. Some love it and think it's the best language ever, some hate it and want it abolished. C++ has its place, the gaming industry knows it extremely well and there is absolutely nothing out there to compare to it (unless you count the mobile sector, but that's a different kettle of fish). I wouldn't use C++ for a lot of things, where other languages have been created to make certain types of development easier, but where you have any k
Re: (Score:2)
Almost any computer language is simpler than C++. If you don't know that, you haven't explored it much. As for better... well I have switched pretty much exclusively to C++ now. Love, hate.
Re: (Score:2)
You're right. Like back to C or pure assembler.
Indeed. There's so much you can do with well-written C and good libraries quicker, more reliably, more simply and much more efficiently than in C++.
With C you have a chance of being able to read and understand your source code 6 months after you wrote it. The syntax is relatively clean, If you're into syntax-highlighting editors, they usually get it right.
There aren't the ABI headaches that come with C++. The compiled code is smaller and faster.
C can fit i
Re: (Score:2)
I couldn't agree more ... strange ...
Why do I have this feeling that it's somewhere between 15 and 20 years ago, and that you're about to get flamed by the sysop?
Re: (Score:2)
Clearly we see something about it you don't. You are welcome to love your "interesting modern languages", while we love our C++. We certainly have no obligation to help you with yours.
Re: (Score:2)
"Let's use [insert non-C++ language], since it is the best fit for this project."
"Wait a minute! I don't know that language, and I do not have time to learn it! Nobody except
Re: (Score:2)
I call BS!
Ok here is the deal in very very simple examples C++ is faster. Namely because you can override the safety nets. For example if I access memory using pointers. BUT if I add bounds checking, and other things that C# gives me C++ is not faster. I write MonteCarlo code in C# and have found there are things you do and don't do in C#. If you stick to those things there is absolutely ZERO advantage to C++. In fact I found that if you are very careful you can almost match raw C++ (about 10% slower). Rem
Re: (Score:2)
It's a very nice idea which brings the best of both worlds. FEniCS [fenicsproject.org], an open-source finite element framework , uses pretty much the same technique to allow one to set up the simulation in Python, yet get the speed of hand-optimized C++ code.
And using Python capabilities one can write code which is much closer to the underlying math, which significantly improves the usability. Here's the core of an example [fenicsproject.org] using FEniCS:
Re: (Score:2)
Re: (Score:2)
I hate C++. I have so many objections to it that I can't even list them here reasonably.
However, there is nothing that can replace it.
Nothing ... except for C
Re: (Score:2)