| ||||
| Comment on My //build/ talk on Friday @ noon PDT (webcast) by nullptr
C++14 lambda capture list looks a lot like let expression. Read More » Comment on My //build/ talk on Friday @ noon PDT (webcast) by Herb Sutter
@pjmlp and all: Thanks for listening. As VS shifts from a 2-3 cadence to a new faster cadence, all of us are learning it together — both internally as we figure out what’s possible and how to deliver VS faster, and externally as customers start to understand the new pattern as it emerges and learn what to expect. We’ve almost cranked one cycle on the new pattern, and it isn’t a pattern till you’ve done it twice, so this “during transition” period is the most difficult (and worry-creating) time because people have lost the previous familiar structure of the historical pattern of what to expect, without yet having a new pattern set to take its place. We (VC++) are excited that this means we don’t have to do our own separate out-of-band RTM releases after all to deliver more often than every 2-3 years, since all of VS has essentially moved to that kind of cadence. But it’s also understandably a period of uncertainty for everyone as we all build and figure out what the new pattern is settling down to be. Read More »Comment on My //build/ talk on Friday @ noon PDT (webcast) by Herb Sutter
PS — I finally went and dug up the 2-min video clip of exactly what I said in Feb 2012 when announcing “out of band” releases — as mentioned above, you can see it was specifically “sooner than 2-3 years.” Here’s the link: http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/C-11-VC-11-and-Beyond#time=9m19s . Read More » | ||||
| ||||
Sunday, June 30, 2013
FeedaMail: Comments for Sutter’s Mill
Saturday, June 29, 2013
FeedaMail: Comments for Sutter’s Mill
| ||||
| Comment on My //build/ talk on Friday @ noon PDT (webcast) by Martin
Thanks for the info. It’s great to hear that there are at least plans to fix some of the more serious issues others have, such as the getting the two-phase look up and ‘more fixed’ C header file preprocessing and all! Read More »Comment on My //build/ talk on Friday @ noon PDT (webcast) by bames53
I just watched the talk and I’m looking forward to the plans shown for VC++. On the question about how widely applicable deduced return types will be, I thought I’d point out that once modules are adopted it will be useful not just for template functions and other functions that appear in headers. Since modules, as described in Douglas Gregor’s presentations, allow for translation units to import declarations exported by other translation units without headers, one will be able to define a normal function with a deduced type, and whatever the deduced signature is will be importable into other translation units. Modules will be one of those added features that make C++ simpler, Read More »Comment on My //build/ talk on Friday @ noon PDT (webcast) by bames53
Oh, and two more things; You mentioned that VC++ hasn’t been using ASTs and that’s why it hasn’t been able to implement features like two-phase look up. Is there someplace I can read more about that? Secondly, I and people who’ve been complaining about non-conforming behavior will be happy to have two-phase lookup, as well as any other fixes we can get, but I wonder how loud the complaints will be from others who just want their legacy code to keep working with the new compiler? Read More »Comment on My //build/ talk on Friday @ noon PDT (webcast) by Felix Petriconi
It is nice that the mssing features are comming. And it is great, what is comming more. I personally am a little dissapointed that the new unions come so late, but I understand that the majority of users would profit more from the other features. Comment on My //build/ talk on Friday @ noon PDT (webcast) by Jonathan Ruttenberg
It was a very interesting talk, even for a non-Microsoft developer. Thanks for the heads-up! The Channel 9 video production was slick, but somewhat thoughtless. Somebody has too much fun pressing those video manipulation buttons and choosing cool camera angles. Far too many times, while code was being discussed, the code was obscured or totally invisible. Regards, Read More »Comment on My //build/ talk on Friday @ noon PDT (webcast) by Zura
Slight off-topic: Herb, could you please tell me if you’re still hiring? I mean the C++ team, C++ AMP, Casablanca, library and compiler teams, etc… Read More »Comment on My //build/ talk on Friday @ noon PDT (webcast) by pjmlp
Given the promises that were made in regard to MSVC++ 2012 updates, given the current situation, how many Visual Studio versions do you think we are willing to pay for, or even trust that what has been communicated today will not change as well? Read More »Comment on My //build/ talk on Friday @ noon PDT (webcast) by jalf
Ok, so several parts of the talk caught me by surprise: fixing two-phase lookup and adding (some) C99 functionality? I really didn’t see that coming. (If I wanted to be mean, I would say that I also never expected your team to actually *finish* variadic templates, given the delays so far, but hey, that would be mean :)) Anyway, I think those improvements are much needed, so thank you for that. :) However, as others above have said, it’s hard not to be concerned about a few things: - you’ve promised that *this* release would be different several times before. Remember the paradise of out-of-band feature updates we were promised for VS2012? Remember how you said back in 2010 that *now* your team was going to take C++11 seriously, after which… pretty much nothing happened? This roadmap looks very impressive, but can you deliver? (Or, again putting on my cynic hat, if you haven’t been able to deliver for the past 4 years, what is going to make the next year or two different?) - the faster release schedule seems to mean we’ll have to pay up twice as often, but what does it get *us*? It might reduce the latency from a feature is developed and until it is made available to us, sure, but I fail to see how it does anything to increase the throughput, and let’s be honest, the MSVC team’s throughput in terms of C++11 features has not been impressive so far. So we have to pay up more often (in a world where nearly every IDE and every compiler is available for free, I might add), but for what? Is that somehow key to the plan to catch up on C++ conformance? Why couldn’t (some of) these new features be shipped as free updates? (and no, I don’t buy the argument that simply putting them behind a paywall somehow makes them less risky or less likely to break existing code. Supporting and maintaining the updates, and making them optional reduces that risk. The paywall does not. That just seems like short-sighted greed) Anyway, I am impressed at the ambitions and intentions highlighted in your talk. I hope that *this time*, your team can deliver on your promises. :) Read More »Comment on My //build/ talk on Friday @ noon PDT (webcast) by Szymon Gatner
Does a promise of CTP for VS 2013 means the same as the last time? A tease of what will come in VS 2014? I bought VS 2012 because you promised “out of bands” C++ compiler updates. 3 updates for and no single feature added from Nov CTP. And now for some reason we suddenly need a new VC just a year after previous release. It used to be 2 years at least. Please don’t promise what you can’t keep. Read More »Comment on My //build/ talk on Friday @ noon PDT (webcast) by Concerned C++ Programmer
@Herb, can you please make a statement in no uncertain terms, with your credibility on the line, as to the exact nature of updates (+out of band) including language features, libraries and bug fixes for this recent release. I’m not asking you to promise great things, but as we are considering purchasing new licenses, we would like to know if we should: We need to make a decision urgently. Read More »Comment on My //build/ talk on Friday @ noon PDT (webcast) by summerlight
In the presentation, you said current VC does not generate complete AST. In my knowledge, there was an similar attempt to re-enginner compiler codebase by using AST. ( http://blogs.msdn.com/b/vcblog/archive/2006/08/16/702823.aspx ) Especially, I was interested in the plan to provide AST API – though it has not been delivered to user. Do you have any similar plan to expose programmable AST API to user? Read More »Comment on My //build/ talk on Friday @ noon PDT (webcast) by Herb Sutter
@Jay: I hope I didn’t give that impression last year, and I chose my words carefully to try to be very precise. I think you’re combining statements from two different talks: First, in Feb 2012 at GoingNative, we said we’d ship conformance features in “out-of-band” CTP and RTM updates faster than VS’s 2-3 year release cycle; for the CTP part, we did so by shipping the Nov 2012 CTP (and soon another one), and for the RTM stream, it turned out later that all of VS moved to a single-year release cycle so we didn’t need to do anything more than snap to that train and release Preview this month to get an RTM go-live compiler with new conformance updates, which we did. I think one place the confusion got started was that people took the “out of band” from this talk and connected the dots to the VS Updates that came later, but we didn’t even know about the Updates at this time. Then, in Nov 2012 at Build, we shipped the November CTP and announced that we planned “more batches” in the first half of 2013. And we missed the “more batches” promise — we did ship a batch this week at RTM quality in VS 2013 Preview, but “batches” is plural and that ended up being the only batch, so we missed. What we had intended was to ship an additional CTP in the spring, which didn’t happen mainly because VS 2013 ended up materializing on a short release cycle so we concentrated on getting the CTP features up to RTM quality (which means not just bug count, but with IDE support, Intellisense, debugging, and especially standard library use of the language features). Somehow the meme got started that we promised features in Updates, and we did not (at least, if we did, please point it out so I can correct it). I saw this happen over the winter and probably should have stomped on it sooner: Around Jan/Feb people started saying that “maybe” some of the CTP features would be in one of the Updates; then around Mar/Apr I saw people saying that “definitely” some of the CTP features would be in the next Update (which was not true and I probably should have corrected it then); then in just the past month or so I’ve started seeing it grow all the way to “Herb promised they would be in an Update” which I carefully didn’t. (And just a few days ago I even saw someone claim I promised this way back in 2010 of all things, which is two years off any statement about conformance that I’m aware of.) So in yesterday’s talk I tried to clarify, in words and in print on the slides, that RTM-ready conformance features would ship primarily in major releases, not Updates, because we do not ship breaking changes in Updates. It would be horribly awful if someone with a working VS 2012 project installed Update 1 and their project broke! We can and do break binary compatibility on major releases, in this case for the first time just one year apart between VS 2012 and 2013. And I should note that this is already a pretty aggressive schedule for pushing out breaking changes, and we worry about the risk of destabilizing enterprise customers who were used to planning two-year upgrades — a lot of shops can’t handle too-frequent feature updates. That said, this week I deliberately worded it that we reserve the right to ship “some” features in Updates, but if you happened to see a new language feature come in an Update this should be viewed as a pleasant surprise, and we would ship a feature in Update N+1 only if we could prove with very high confidence that it wasn’t going to break any projects using Update N. @Jonathan: Thanks, and sorry if the camera work was distracting — I haven’t seen it yet myself since the video is not yet available. I expect the slides will be made available when the talk video gets posted in a couple(?) of days. @bames53: There’s nothing published that I know of about our compiler’s internals, AST or otherwise. It’s not secret (or I wouldn’t have mentioned it), it’s just not something I’m aware of anyone writing about. Most people don’t care how the compiler works or how hard the compiler writers labors, they mostly just care about whether it supports features and it’s the compiler team’s job to make it so without complaining about how hard it is. :) We have a good team and they don’t complain, they just say, “okay, now we need to modernize this part” and go do the design and engineering work to make it so. And re your breaking changes question: Right, when we do two-phase lookup it could break code that relies on the current behavior. Even though such code is nonstandard and nonportable, we would treat such a breaking change seriously and migrate people through it. One usual path (but not the only possible one) is to first ship the feature under a switch that’s off by default in one release but still warn by default on code whose meaning could change that there’s a possible future behavior change coming; then in the next major release ship the new-behavior switch on by default; then eventually someway remove the old behavior and the switch. That’s one possible example, but in some way you want to enable customers to migrate to the standard behavior without forcing a bad “fix everything now” surprise on them all in one shot. @Felix: Yes, VS 2013 Preview has a go-live license, so it can be used in production code. See above for Updates — we are setting the expectation that new features will appear in CTPs or in (now-faster) major RTM releases, generally not in Updates. @Zura: Yes, we’re hiring. If you’re a compiler developer, please do email me your resume. @pjmlp: I don’t think we did promise new features in Updates, but clearly somehow that expectation got our there so I’m trying to be very clear about it. I do not know the update pricing for VS — I believe that will be announced in the near future though. Note that if you’re using Express (and we will continue to give away VS 2013 Express as a free SKU), or have a subscription (which includes free releases during your subscription), my understanding is that you have access to new compilers for free anyway. But check with whatever is actually announced, don’t go on what I say since I don’t decide pricing. @jalf: See above about out-of-band releases. We did that — shipped a CTP, and then not just VC++ but all of VS on a cycle faster than the usual 2-3 year band VS always followed before. Oh, here was where I saw the comment about 2010 — the first talk I gave on VC++ conformance to C++11 was GoingNative 2012, summarized above. Re pricing: Again, I don’t control or announce that, but what I can do is let you know about the CTP stream and the RTM stream, when to expect features in each stream (and by default not in Updates), and then you can decide what makes sense to purchase armed with that information. @Szymon: The VS 2013 release actually took the place of where we were thinking of shipping an out-of-the-2-3-year-band RTM release — all of VS essentially went out of the previous band, so we snapped to that. @Concerned: See above — we’re trying to be totally transparent so that you know what to expect and can decide what version to purchase or not purchase. Note that with the Express (always free) or subscription you always can get the latest release without additional cost, as far as I know (and that’s really all I know). We’re working on features, and as they meet the CTP bar and the RTM bar I outlined in the talk, they will be ready to get in the next CTP or the next RTM. But, as I said, RTM by default means major release, which is on a faster than 2-3-year cycle and this time was one year (but I’m deliberately not saying what the next cycle after VS 2013 will be because we don’t know, all we can say is that we’re working on faster cycles than 2-3 years and here’s what it was this time). @summerlight: We’re working on the AST in parallel with C++11/14 features, and maybe after we’re done that we can think about exposing it via an API but right now our focus is on having it internally so we can implement the Standard fully. After that we can see about considering doing more. Read More »Comment on My //build/ talk on Friday @ noon PDT (webcast) by Olaf van der Spek
Can’t wait to get non-static initializers and more. string chunk; while ((chunk = read_chunk()).size()) { .. } Wouldn’t while (auto chunk = read_chunk()) { … } be nicer? Comment on My //build/ talk on Friday @ noon PDT (webcast) by pjmlp
Thanks for taking the effort to explain the whole situation. Read More » | ||||
| ||||
Friday, June 28, 2013
FeedaMail: Comments for Sutter’s Mill
| ||||
| Comment on My //build/ talk on Friday @ noon PDT (webcast) by Grout
Still no C99 to speak of in MSVC. Hate, hate. Read More » | ||||
| ||||
Thursday, June 27, 2013
FeedaMail: Comments for Sutter’s Mill
| ||||
| Comment on My //build/ talk on Friday @ noon PDT (webcast) by Jay
Will the talk cover the awkward question to “what happened to the promise of out-of-band compiler updates”? You were pretty vocal a year ago about how we all should just “wait and see” all the C++11 improvements that were going to be delivered out-of-band for VS2012. ;) Read More »Comment on My //build/ talk on Friday @ noon PDT (webcast) by Flo
At least the example code from your own slides (The C++ Concurrency Talk) also works now with VS. Thanx to finally working unified initializers ;). But I agree with Jay, all this was promised to be in VS2012 via free updates. Read More » | ||||
| ||||
Wednesday, June 26, 2013
FeedaMail: Comments for Sutter’s Mill
| ||||
| Comment on Effective Concurrency: Prefer Using Active Objects Instead of Naked Threads by Isaac
I’m curious to find out what blog system you’re working with? Comment on GotW #100: Solution by Herb Sutter
I temporarily took down those temporary pages for GotWs #100-104 to avoid confusion as I generate new ones. I’ve now restored them exactly where they were, and as I revise them for C++14 I’m replacing the page contents with a redirect/link to the permanent version. See also /gotw. Read More » | ||||
| ||||
Tuesday, June 25, 2013
FeedaMail: Comments for Sutter’s Mill
| ||||
| Comment on GotW #91 Solution: Smart Pointer Parameters by earwicker
@GregM “which is a problem no matter which kind of pointer” See, Herb made exactly the same kind of observation in his parenthetical caveat: “… but in this respect it's no different than any other aliased object.” What difference does it make to whether we need to take care in this situation? It’s not just a problem for pointers, it’s a problem for any object with mutable internal state, e.g. a string vs. a ‘const string&’ This doesn’t stop it from being a problem in the case of shared_ptr, does it? By accepting a parameter that is a const &, you’ve already introduced at least one alias. You’ve said, in effect, “I don’t care if this object stays alive – I assume all my callers will ensure that for me”. Rather than saying “it’s a guarantee (except it’s not)”, why not instead say we always have the same trade-off to make: 1. copy (slow, but ensures object will survive) If you follow 2 by default throughout your code, you are practicing the art of “write fast code, then fix it”. If you follow 1 by default, you’re following “write correct code, then optimize it”. Again, choose your poison! Due to the severe performance problem caused by all the ref-counting, optimizing a correct program may be as hard as finding/fixing bugs in a fast program. Read More » | ||||
| ||||
Monday, June 24, 2013
FeedaMail: Comments for Sutter’s Mill
| ||||
| Comment on GotW #100: Solution by Franklin?
Couldn’t find an alternative link for the solution (link broken). Are you still maintaining pages for these older articles? Read More »Comment on GotW #92: Auto Variables, Part 1 by auto: il linguaggio non è tutto | Italian C++ Community
[…] enfasi di recente è stata posta sul nuovo uso della keyword auto in C++11 (si veda per esempio qui). In sintesi, auto sostituisce un tipo esplicito con una richiesta rivolta al compilatore di […] Read More » | ||||
| ||||
Sunday, June 23, 2013
FeedaMail: Comments for Sutter’s Mill
| ||||
| Comment on GotW #93 Solution: Auto Variables, Part 2 by Andrei Alexandrescu
Thanks Herb for bringing this to my attention. Replies @Sebastian within. >This doesn't help much. The unexpected type conversion happens as part of integer_expr; all the "helper" does is afterwards cast it back. Yes, the behavior of unsigned to signed when not in range isn't undefined, just implementation-defined, but that's enough to make the code non-portable. This seems to be a misunderstanding of the intent. You use as_xxx in lieu of a cast, and eliminates committal to the width of the type without eliminating committal to the consequences of changing signedness. >> double f4 = f1 + f2; // … this might keep more bits of precision >This is incredibly obscure and would definitely not pass code review from me. If you want higher precision, cast the inputs to double. If you don't want higher resolution, assign the result to a float. Everything else is just a maintenance nightmare. Makes sense (especially for +, which would use ADDSS thus operating in single precision). My point here is that a common pattern in math code is: * use float for input due to store size restrictions * do intermediate computation in double because it costs just a little more for a big win in accuracy * get back to float when writing results to the store Due to this pattern, you want to actively cast to double early in the computation chain, sometimes as simple as double x = array[k]; If auto were used, x and computations derived from it would be float. That’s what I’m saying. Read More » | ||||
| ||||
Saturday, June 22, 2013
FeedaMail: Comments for Sutter’s Mill
| ||||
| Comment on GotW #91 Solution: Smart Pointer Parameters by GregM
“What actual firm claim is being made here?” Absent aliasing, which is a problem no matter which kind of pointer you are using, and can’t be dealt with just by using a different kind of pointer, you can be guaranteed that the object will be alive for as long as the function call. “When can it be relied on? How can we tell?” It can be relied on as long as there is no aliasing of the pointer. As for how you can tell, that’s going to require that you look at your program to see if there is any aliasing going on. Read More »Comment on GotW #94 Special Edition: AAA Style (Almost Always Auto) by jlehrer
I don’t have an 11 compiler to play with right now or I’d answer this question myself. What does this do: auto i=1,f=2.0; Does that make two integers, an int and a float, or two floats? Read More »Comment on GotW #93 Solution: Auto Variables, Part 2 by Adrian
@Jon: Yes, I’m familiar with Bjarne’s “too pedantic” comment, but I watched one of his presentations from 2012, and the examples in his slides used vector::size_type. Having spent many blissful years with the compiler warning on reliably catching real bugs, and then a few years at another company with “int i” for loop (and therefore the warning disabled), I conclude that there’s nothing pedantic about it. Signed/unsigned bugs are insidious and hard to find. I’m not really worried about the for-loop indexes, but what we miss because those indexes force us to disable the warnings. Read More »Comment on GotW #94 Special Edition: AAA Style (Almost Always Auto) by Róbert Dávid
@jlehrer: That’s ill-formed, both have to deduce to the same type. I’m not sure but as I remember GCC does allow it, and gives you an int and a float, but that’s nonconforming behaviour. Read More »Comment on GotW #94 Special Edition: AAA Style (Almost Always Auto) by jlehrer
So this is well formed: auto i=1,j=2; but this is ill-formed: auto i=1,j=2.0; Okay. What about this: auto x=1,*j=&x; I’m going to guess that is ill-formed as well. Read More »Comment on GotW #94 Special Edition: AAA Style (Almost Always Auto) by André Müller
@jlehrer auto i = 0, j = 1; //does compile auto i = 0, *j = &i; //does compile auto i = 0, j = 2.0; //error: inconsistent deduction for 'auto': 'int' and then 'double'Read More » | ||||
| ||||
Friday, June 21, 2013
FeedaMail: Comments for Sutter’s Mill
| ||||
| Comment on GotW #92 Solution: Auto Variables, Part 1 by Maxim Yanchenko
@Herb, thanks for the article! typedef float aligned_block[4] alignas(16); aligned_block a{...}; auto b = a; // is b aligned on 16? 2) what about explicit auto? Is there any protection for private classes that we don’t want to expose (e.g. because it holds references to temporary objects from the enclosing full expression)? Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by earwicker
re: Herb’s caveat “(Yes, you have to be careful if the smart pointer parameter can be aliased, but in this respect it's no different than any other aliased object).” Reminds me of the guy who was hitting himself with a hammer. When his doctor told him “Stop hitting yourself with a hammer”, he replied “Oh, come on, you can’t blame the hammer. It would be just as bad if I hit myself with a brick or anything else for that matter!” Yes, if g calls f then as long as f is still running, then g is still running. But g could pass to f a member variable, m, which presently refers to an object, and then some unholy, filthy chain of callbacks set off within f could reach back and cause m to be mutated, all while f – and therefore g – still have not returned. So Herb’s paragraph “However, we already get this for free…” would seem to be followed by the caveat “… (except when we don’t).” What actual firm claim is being made here? When can it be relied on? How can we tell? Read More » | ||||
| ||||
Wednesday, June 19, 2013
FeedaMail: Comments for Sutter’s Mill
| ||||
| Comment on GotW #93 Solution: Auto Variables, Part 2 by Amali
// best auto get_size = [](const auto& x) { return x.size(); }; This code for auto lambda parameter types gives compiler error messages in gcc 4.8.0. Is there a compiler where it will work? Comment on GotW #93 Solution: Auto Variables, Part 2 by Ralph Tandetzky
Just for your information: These named lambdas with auto parameters have a very interesting use-case which makes them more flexible than the template function alternative. For instance, if you have a template function template <typename T> void func( T t ) { /*...*/ } and a generic template function template <typename F, typename T> void call( F f, T && t ) { f(forward<T>(t)); } then the following code will not work call( func, 42 ); since I would have to write func instead of func here. However this code should work, because func(42) is a valid expression. I actually had this problem in real world code in a physics simulation software I wrote. I can fix it by manually inserting the but with C++14 lambda with auto parameters it’s much easier and even less code. I just have to replace the definition of the func template function by static const auto func = []( auto T) { /*...*/ } This is even less typing. It makes the code more flexibly usable. I also wondered, if it might be generally a good idea to write named lambdas with auto parameters instead of template functions where possible. This might be food for another GotW. ;) By the way, I posted this stuff on Stackoverflow: http://stackoverflow.com/questions/17169498/why-do-i-need-to-specify-the-template-argument-type-of-a-templated-function-here It is possible to write this code in old C++ also, but it’s a bit more verbose. It’s gonna work with struct { template <typename T> void operator()(T t) { /* ... */ } } func; This is what I’m going to do for my code until C++14 is implemented. Read More »Comment on GotW #93 Solution: Auto Variables, Part 2 by Ralph Tandetzky
I just asked a question on StackOverflow about what the differences between template functions and name lambdas with auto parameters is. Some good answers are coming in. See http://stackoverflow.com/questions/17188485/template-functions-versus-named-lambdas-with-auto-parameters Read More »Comment on GotW #93 Solution: Auto Variables, Part 2 by Pablo Halpern
In 1(d), the original version creates a function which, when invoked, returns void. The alternative versions return size_type. I think you meant something like function<size_t(vector<int>)> Nice overview of the benefits of auto. It contained some things I had not thought of. Note that there is at least one situation in which auto is [b]extremely[/b] dangerous: expressions that return proxy types. Consider this problem: vector<bool> v = { ... }; auto b = v.back(); // Oops! b is of type vector<bool>::reference, which is NOT a bool v.pop_back(); bool a = b; // Oops! b has been invalidated! Some members of the standards committee have suggested ways to fix this in the language, but I am not familiar with specific proposals. Read More » | ||||
| ||||
Tuesday, June 18, 2013
FeedaMail: Comments for Sutter’s Mill
| ||||
| Comment on GotW #93 Solution: Auto Variables, Part 2 by Adrian
@Herb: C++ isn’t just used on modern machines with 64-bit address spaces. It’s also used on 16-bit embedded processors, where it’s reasonable to have containers with sizes that might peak in the 32K to 64K-element range. I’ve debugged far too many crashes in my career caused by someone using a signed 16-bit int instead of an unsigned one. Even on 32-bit machines, there are too many programs that can’t handle a 4GB file. Regardless of whether vector::size_type _should_ have been unsigned, the fact that it _is_ unsigned. Mixing signed and unsigned forces you to disable compiler warnings that can help catch hard-to-reproduce bugs in other parts of the code (including some of the ones where you should have used signed arithmetic instead of unsigned). I’ve also debugged far too many crashes caused by comparing an unsigned 32-bit millisecond counter to a signed timeout value. Style guidelines that require disabling useful compiler warnings are broken. Read More »Comment on GotW #93 Solution: Auto Variables, Part 2 by Jon
@Adrian: I’ve debugged far too many bugs caused by incorrect use of unsigned variables, and far fewer bugs related to using a signed int with a collection with more elements than MAX_INT. So my experience differs from yours, and I belong to the “size_type should have been unsigned” camp. I completely agree with you that mixing signed and unsigned is broken. So, perhaps casting the vector’s size to a signed variable (with an exception if it would overflow) is a solution. This limits the size by half, but avoids mixing signed/unsigned and avoids unsigned-related bugs. Note that Bjarne himself doesn’t seem too fussed using a signed variable. See http://www.stroustrup.com/bs_faq2.html#simple-program: “Yes, I know that I could declare i to be a vector::size_type rather than plain int to quiet warnings from some hyper-suspicious compilers, but in this case,I consider that too pedantic and distracting.” Read More » | ||||
| ||||