 Comment on A quick poll about order of evaluation… by Peter What is wrong with You people? How it could possibly be 01? that would mean i++ evaluates to 1 two consecutive times! This better not happen regardless the order of evaluation!
:D
Consider v[i++] = v[i++] = i++; // <– how this should evaluate? Read More » Comment on Trip report: Fall 2015 ISO C++ standards meeting by C++ Annotated: Fall 2015 | JetBrains CLion Blog […] Stroustrup and Herb Sutter published detailed reports about Fall 2015 ISO C++ standards […] Read More » Comment on Trip report: Fall 2015 ISO C++ standards meeting by C++ Annotated: Fall 2015 | ReSharper C++ Blog […] Stroustrup and Herb Sutter published detailed reports about Fall 2015 ISO C++ standards […] Read More » Comment on Reader Q&A: auto and for loop index variables by Greg Marr Adam, even better than both in that it doesn’t introduce variables into the outer scope: for (decltype(object.size()) i = 0, n = object.size(); i < n; ++i) That is, unless the loop body does something that can change the size of object, in which case you do need your second form, and you have to live with any extra size() calls. Read More » Comment on Reader Q&A: auto and for loop index variables by adam915 Hi all, I’m not sure about insert object.size() (or any other function) in for statement is good solution, i think the auto object_size = object.size(); decltype(object_size) i = 0; for (i = 0; i < object_size; i++) { … } it’s better than for (decltype(object.size()) i = 0; i < object.size(); i++) { … } because we don’t call object.size() function in every iteration (in second example, it’s called twice) Read More » Comment on Trip report: Fall 2015 ISO C++ standards meeting by Tony Van Eerd For variant, eg variant<int, string> note that functions like get<int> already needed to check if the discriminant was an int. And throw if it was a string. Now it throws if it is a string or invalid. So no extra code. And visitation needs to check the discriminant as well, so no real extra code there either.
As for “separate tag value for invalid state internally”, assume the variant has uses an int (or enum) as the discriminant of which type is currently set (ie 0 means int, 1 means string for the above variant). -1 can mean invalid. Read More » Comment on Trip report: Fall 2015 ISO C++ standards meeting by Ilya Popov Does it mean there will be a separate tag value for “invalid” state internally? Read More » Comment on Trip report: Fall 2015 ISO C++ standards meeting by Herb Sutter @jmckesson: “Modules phase 1” is essentially Gaby’s approach, and “phase 2” is essentially adding support for exporting macros. As for variant, “zero overhead” means at run time — no extra space consumed, and no extra code executed — compared to writing it (correctly) by hand using a raw union and a discriminant tag. Read More » Comment on Trip report: Fall 2015 ISO C++ standards meeting by ZaldronGG jmckesson, why check it? If the variant invariants’ are not met, chance’s are your function doesn’t know enough to act accordingly, and should just let it throw. Read More » Comment on Trip report: Fall 2015 ISO C++ standards meeting by jmckesson > Modules has reached a milestone: design agreement! This was done by separating "phase 1" and "phase 2" of modules What are the two phases exactly? Is “phase 1” going to be what Gabriel Dos Reis presented at CppCon2015? Because if we get that, I’m not sure what could happen in “phase 2”. And if “phase 1” doesn’t include all of those elements, I don’t know how useful that phase could be. > attempting to access the invalid variant causes defined behavior, such as throwing an exception, instead of undefined behavior. Does this not mean that every function that uses the variant must check its validity? How exactly is that “zero overhead”? Granted, I don’t care all that much, as long as we have a never-empty variant that can get through the committee… Read More » Comment on My talk at CppCon by Juergen Busch I really was electrified by Bjarne’s and your talk. Resource and type safety is definitely an issue. I have seen many libraries where even a quick view into the code easily revealed at least the one or other resource leak. What might be in there too – but hidden much “better”? So, I like the idea of owner to ease the work for an analysis tool (compiler or external based) and I liked to see how far you already got with such a tool. But I found no information how that might work with non-pointer resources or if it is even planned to extend it in that direction. You know, we have HANDLE-s and int-s as resources too. I would like to have a unique_owner and shared_owner for such resources somewhat like unique_ptr and shared_ptr for pointers. When I tried to sketch such a unique_owner class following the guidelines I wondered how to signal the “deleter” (CloseHandle or such) for the owned resource to the analysis tool. Did I miss something in the GSL documentation and/or your or Bjarne’s talk? Or would we need a deleter wrapper too that signals a function object to be the equivalent of delete for a non-pointer resource type T? Or is that idea of non-pointer resources owners a bad one? Comments appreciated! Read More » Comment on My talk at CppCon by Daniel Teske So I looked through the paper in the core guidelines paper and all of that looks pretty fantastic. I’d love to try that out on Qt to see if the rules and the tool are suffiecently smart that the effort is reasonable. One pattern, that is very common in Qt, is that parents take ownership of their children. To give a concrete but example, imagine a class like this: (Drastically simplified to only the memory management.) class Thing
{
Thing(Thing *parent = 0)
{
if (parent)
parent->children.append(this);
}
~Thing()
{
for (auto child, children)
delete child;
}
vector children;
}; Now the semantics of that are, pretty obvious. If a thing has a parent, then that parent takes care of deleting its children. Otherwise the user has to take care of that Thing. In pratice, for e.g. widgets in windows, pretty much everything has a parent and thus is automatically deleted, except for top level windows. So it does actually work pretty well. Now, since Qt values source and binary compability a lot, we can’t really change the API, but still I would like to change it so that the tools can detect memory errors in Qt code. The first step would probably to uses two constructors:
Thing() // needs to be assigned to a owner, or stack allocated.
Thing(NotNull) // needs to be assigend to a raw pointer Looking at the paper I couldn’t find any way to express the comments in code or annotations for the tools though. Any thoughs on this? Read More » Comment on My talk at CppCon by Germán Diago This is easily the best c++ news since I started to use it. And that was by 2002. So it is not a light assertion. Boost, C++11 and much, much more has happened since then. But this is… simply unbelievable. Great thanks to everyone, and thanks for pushing this forward. Read More » Comment on My talk at CppCon by Anon Great presentation. Your talk and the demos with Neil brought a lot of excitement to C++. The ability to be guaranteed memory safety in C++, really takes the wind out of a lot of competitors (I am looking at you Rust) and helps with introducing C++ into new areas. Great work. Looking forward to trying out the tools when they are released. Read More » Comment on My talk at CppCon by Craig Henderson Compile times are a serious problem in large scale C++ projects. Loading the compiler with all the diagnostics will slow compilation down even further. An external tool might be a better home for such code analysis. Read More » Comment on My talk at CppCon by alexmatto Your presentation was fantastic, currently is my favorite one on CppCon2015. Type and Memory Safety, without verbosity or heavy annotations, in current C++ is great! Read More » Comment on My talk at CppCon by Lilian Thank you guys for the effort.
Last monday I cross-compiled Rust for our ARM target and was planning on how to try to introduce it in our company.
Now my priority has changed for tommorow(monday), I have to introduce GSL in production. We use GCC 4.4.1 but with “experimental” C++11 we could use at least the non_null implementation with minor changes to replace nullptr. As you see by the compiler version, people in that big company are not very accepting to changes, hopefully to introduce a library will be a lot easier than to introduce another programming language. Read More » Comment on A quick poll about order of evaluation… by somedude I hope the result of the voting isn’t undefined. Read More » Comment on Reader Q&A: Why was implicit int removed? by somedude While I think this is a good change which will improve readability without sacrificing to much flexibility, the int type is still special in some circumstances, for example when doing arithmetic operations on smaller-than-int types the operands are upconverted to int first. Read More » Comment on Trip report: Spring ISO C++ meeting by David Greene SIMD types is a very bad idea. Use of such types locks the code into a particular style of vectorization, making it less (performance) portable. It’s much better to add bits of language to allow the user to tell the compiler what is safe and/or profitable. For pointer-heavy code, a directive to tell the compiler to ignore potential data dependencies is very helpful (in addition, insert request for something like “restrict,” but better, here). Compilers have all kinds of transformations to improve cache usage, rework loops for better parallel efficiency, etc. Do not constrain the compiler by forcing it to vectorize a particular loop in a particular way. Tell the compiler what is safe and hint at what is profitable and let it do it’s work. It’s the compiler’s job to map to hardware, not the user’s. The original Intel paper on this cited cache utilization as a motivating example, with the valarray “operate on all elements in one operation before doing the next” semantics being blamed. Fortran array syntax has similar semantics and vectorizing compilers have got along with it just fine. C++’s real handicap with respect to parallelization is ambiguous pointers. Providing tools to eliminate that problem will go a long way toward improving parallelization. Read More » Comment on A quick poll about order of evaluation… by Aaron If I didn’t know any better, I would assume the following based off of the OOO. v[i++] = i++; // Just evaluating this expression. v[i++] // place address of v[0] on the stack, increment i (i == 1);
i++ // load i (i == 1) on the stack, increment i (i == 2);
= // pop the value 1 from the stack, pop address of v[0] from the
// stack, assign v[0] the value of 1; I would expect an output of 10. Read More » Comment on CppCon program online by Yuriy Grishin Thanks, Herb. It is much appreciated by at least one person. :) Read More » Comment on CppCon program online by Herb Sutter @Yuriy: Yes, same as last year — the program will be professionally recorded and will be freely available online, and you should expect post-event video processing and online posting to take a couple of months. Of course, it won’t be like being there. :) Read More » Comment on CppCon program online by sachinjoseph Awesome! Looking forward to it :-) Read More » Comment on CppCon program online by Yuriy Grishin Looks very interesting. Are there any plans on recording [some|most|all] of this talks? Read More » Comment on CppCon program online by jon I noticed you weren’t on the program and thought to myself “oh no great loss I’m not going then if Herb isn’t talking”, but now I’m in a quandary again :) Read More » Comment on Trip report: Spring ISO C++ meeting by Where is C++ heading? | Computing language […] Well, there is still some time for 2017…sigh. Let’s see what the meetings at the end of this year bring. […] Read More » Comment on Announcing a financial assistance policy for ISO C++ meetings by Matt Hi Herb, this is a great idea to push things forward – well done. Please, also motivate more guys to give talks like the following that include beautiful and elegant examples:
1. Sean Parent – C++ Seasoning
2. Eric Niebler – STL Concepts and Ranges
I also like webpages explaining things by looking at examples
http://en.cppreference.com/w/cpp/algorithm
or
http://theboostcpplibraries.com
and I think the C++ community needs more well designed web pages collecting all the nice and elegant examples. Thanks for your work and I’ll hope you are pushing more the “ExampleotW” then the GotW in the future, Matt Read More » Comment on Stroustrup & Sutter on C++: Mar 31 – Apr 1, San Jose, CA by S&S Postscript | Software Engineer InformationSoftware Engineer Information […] on the previous post regarding Stroustrup & […] Read More » Comment on My CppCon talks by My CppCon Plenary (updated) | Software Engineer InformationSoftware Engineer Information […] we announced the CppCon conference program and I posted my final talk selection, the original plan for my Friday ‘endnote’ plenary was for it to focus on giving an […] Read More » Comment on My CppCon talks by Georg Hi Herb! Thank you for your talk on CppCon 2014! It was really enlighning and helpful! Read More » Comment on Trip report: Spring ISO C++ meeting by Tomas When will be the new SG14 mailing list made publicly available through isocpp.org forum links? Read More » Comment on Announcing a financial assistance policy for ISO C++ meetings by Kunal Vichare Very nice keep it up sir Read More » Comment on A quick poll about order of evaluation… by Gareth I was only thinking yesterday that everyone knows what multiple uses of i++ should do so why don’t that define it properly in the standard? I figured maybe compilers have better opportunity to optimize code where multiple increments are not used or something like that. After seeing this survey I realize that people’s ideas of what it should do vary quite a lot. I went for 10 on the basis that i is incremented after it is used each time. Now I see that is not as obvious as I thought it would be. Read More » Comment on Reader Q&A: Why was implicit int removed? by David Thornley Unnamed parameters are often used to indicate that the parameter is not used in the function. This means the compiler doesn’t have an additional identifier that it will flag as unused, and the next person to look at the code understands that immediately. Good parameter names do indeed make the code more readable, and if we’re using the name to indicate the role of the parameter, an unused parameter should have no name. Parameters can be unused for good reasons. A function for a library callback may not use all the information the library provides. A function in a set of overloaded functions may have no use for one of the parameters. Read More » Comment on VS, Clang, cross-platform, and a short video by commentllain It may be heretical, but it would be awesome to be able to cross-compile c++ code for linux from visual studio. Test locally, perhaps using a docker managed container running on a stripped down linux via hyper-v, and then push to production on azure. Read More » Comment on Reader Q&A: Why was implicit int removed? by Chris Chiesa In your ambiguous example, it seems to me an alternative language fix might have been to forbid unnamed parameters in the declaration of a function. After all, I seem to remember reading thirty years ago that named parameters were an important part of making C code “self-documenting” (which it was, compared to the e.g. assembler or Fortran which preceded it (directly, in my own workplace of that era)). Unnamed parameters evade this important mechanism. On the other hand, am I correct in recalling that C, too, permitted unnamed parameters in function declarations? If so, well, then, I’m egotistical enough to say that “it shouldn’t have” — since we would then have avoided this entire issue forevermore. If we simply stipulate that C did permit unnamed parameters, I can imagine the argument against forbidding them in C++ going something like, “But look at the enormous volume of existing code that would have to be changed!” — to which I say, “A one-time burst of pain is preferable to perpetuating an architectural error forever.” Read More » Comment on Reader Q&A: Why was implicit int removed? by ChristianSC Dear Herb Sutter,
how I can suggest a question for Reader Q&A. I did not find an email address of you on this page.
Thanks! Read More » Comment on Reader Q&A: Why was implicit int removed? by Vikram Ojha Sir am quite clear that why int as a default data type is removed as it can add confusion but why “int” as a default return type is removed is removed ? Read More » Comment on Reader Q&A: Why was implicit int removed? by cartec69 Once Concepts makes it into the standard we can add an “implicit auto” rule. C++ will be that much closer to Perl ;) Read More » Comment on Reader Q&A: Why was implicit int removed? by Herb Sutter @Motti: Fixed, thanks. But think of the value of implicit “it”: seems that having would make easier to write tersely when matters. :) Read More » Comment on Reader Q&A: Why was implicit int removed? by Motti Lanzkron Typo alert:
> If we had implicit it “for small values of ‘n’ ” ;) Read More » Comment on Reader Q&A: auto and for loop index variables by Satish Should be able to use an STL alogrithm if possible?. Read More » Comment on Reader Q&A: auto and for loop index variables by buttink I want the nifty way python does it for (tie(i, elem) : enumerate(list)) { ... } Just need to be able to define variables in tie. Read More » Comment on My CppCon talks by Alex Say we have 20 people writing a piece of infrastructure code that controls lifetime of the objects and uses tables with shared pointers. We have 10s of APIs that expose plain pointers to these objects (no lifetime control). We have have several groups writing infrastructure. We have 1000+ developers working on 4 continents who can get assigned to do a bug fix in a relatively random piece of code. We do not want them to be able to call delete on a pointer even if they feel that it is a great idea. These are non-owning pointers I am talking about. Again it is not a big deal to work around make_share+private-destructor issue one way or another but somehow it does not seem right. Read More » Comment on My CppCon talks by Herb Sutter How does a non-owning pointer (such as a child node’s back pointer to the parent that owns it and so will outlive it) imply a private destructor? Read More » Comment on My CppCon talks by Alex There is one thing somehow bothers me a lot. Non-owning pointer means private destructor, private destructor means make_shared would not work. Yes one add some boiler plate code and do the same with out make_shared – but is not the way towards basics ans simplicity. Read More » Comment on A quick poll about order of evaluation… by DowntownDave Herb I’m ready for a new blog post now… :) Read More » Comment on Visual C++ Compiler November 2013 CTP by 天龙八部开私服一条龙服务 风云雄霸天下服务端天之炼狱一条龙大话西游服务端精灵复兴服务端
劲舞团私服开服热血江湖私服开服倚天I私服开服网页游戏私服开服天堂2私服开服
骑士开区一条龙天上碑开区一条龙美丽世界开区一条龙科洛斯开区一条龙石器时代开区一条龙
天龙八部开私服一条龙服务 http://www.e7if.com/ Read More » Comment on Reader Q&A: auto and for loop index variables by Daniel Nyström I would actually like to propose a breaking change; I think auto i = 0; should not compile. The reason is, 0 is a valid constant for all signed integral types, all unsigned integral types, all floating-point types and all pointer types. So the type really can’t be deduced. This could lead to code like auto i=0, sz=77u; working, since i don’t participate in deduction, and the rest agree Read More » | 
