| ||||
 Comment on Reader Q&A: Acquire/release and sequential consistency by Herb Sutter
@Fernando: That code is fine and needs no special code generation for many reasons (disjoint stacks so those locals won’t be adjacent; escape analysis and constant propagation would eliminate c and b outright; even if c and b were static and laid out adjacent in memory it’s fine because all modern processors have single-byte reads so no need even to inject alignment/padding, etc.). Ah, and now I see Bjarne already answered this right in that FAQ. :) Read More »Comment on Reader Q&A: Acquire/release and sequential consistency by Fernando Pelliccioni
Hi Herb, I’ve seen the Atomics Weapons (1 and 2) videos, I found great, thanks! In all examples where you explain the Memory Model you’re using atomic declarations, right? My question is: // thread 1: // thread 2: … Does this mean that a C++11 compliance compiler must insert “lock” instructions (barrier, fences, adquire/release, etc…) to protect NON-Shared NON-atomic memory? Thanks and regards, | ||||
| | ||||
| ||||
Thursday, October 31, 2013
FeedaMail: Comments for Sutter’s Mill
Monday, October 28, 2013
FeedaMail: Comments for Sutter’s Mill
| ||||
| Comment on Perspective: "Why C++ Is Not 'Back'" by Craig
Managed languages are the right choice for the large majority of use cases. C is usually the most pragmatic choice for use cases that call for a lower level of abstraction and/or higher level of control. C++ just doesn’t have enough to offer to justify it’s horrifying complexity, internal inconsistency and glacial compilation speed. Ensuring the job security of and dependence upon the sadists willing to learn it is just about the only thing it has going for it. Read More »Comment on Trip Report: Fall ISO C++ standards meeting by terry
>whether the programmers start using all these wonderful features and leave the past behind | ||||
| | ||||
| ||||
Sunday, October 27, 2013
FeedaMail: Comments for Sutter’s Mill
| ||||
| Comment on atomic Weapons: The C++ Memory Model and Modern Hardware by KerrekSB
Could I ask for some clarification? In the “relaxed” section of the talk, you have a “stop” variable and a relaxed load from it to check whether a thread should end, paired with an SC store “stop = true;” in the main thread. Is it actually guaranteed that the store operation propagates and becomes visible eventually? Would such a guarantee depend on the existence of an acquire-release-pair? (I appreciate that actual synchronization isn’t required in the example and that we don’t need a release sequence, but I don’t see how eventual propagation is guaranteed.) Thanks! Read More » | ||||
| | ||||
| ||||
Monday, October 21, 2013
FeedaMail: Comments for Sutter’s Mill
| ||||
| Comment on Reader Q&A: When will better JITs save managed code? by Jon Harrop
“This is a 199x/200x meme that's hard to kill…a JIT can never be as good as a regular optimizing compiler because a JIT compiler is in the business of being fast, not in the business of generating optimal code” In my experience, the variance between different C++ compilers is much greater than between C++ and managed languages. For example, I have found that MSVC++ usually generates poor code that runs slower than most managed languages. The Clang C++ compiler usually generates fast code but it uses the same backend (LLVM) that managed languages use. So I don’t believe your claim. Do you have any concrete examples of optimizations done by C++ compilers that are not done by JITs because compile times would be unacceptable? Read More »Comment on Reader Q&A: When will better JITs save managed code? by Ben Voigt
Sure, many times there are complex expressions (perhaps including loops) performing computations which are parameterized by the parameters are known at compile-time. Numeric integration of a function that has no closed-form algebraic integral, parameterized on the limits/bounds would be an example. In C++, meta-programming (formerly with templates, now with `constexpr`) can cause those to be precomputed at compile time. JITs won’t compute those at compile time, and in fact there would be no advantage to doing so, because the compile time cost is paid for every execution. In a JITted environment, you might as well just use memoization to ensure the computation is done at most once per execution. Read More » | ||||
| | ||||
| ||||
Sunday, October 13, 2013
FeedaMail: Comments for Sutter’s Mill
| ||||
| Comment on Reader Q&A: When will better JITs save managed code? by [转]为什么移动Web 应用程序很慢
[…] 下面这段话出自于Herb Sutter ，现代C++中最著名的人物之一： […] Read More » | ||||
| | ||||
| ||||
Wednesday, October 9, 2013
FeedaMail: Comments for Sutter’s Mill
| ||||
| Comment on Trip Report: Fall ISO C++ standards meeting by Kostas Dritsas
It is great to know that C++ is (undoubtedly) chaning for the better, my main concern is whether the programmers start using all these wonderful features and leave the past behind. it is very important to me to know when to use the right Comment on Bjarne and I are speaking in Chicago on Tuesday night by Vipul S. Chawathe
@everyone thnx :))) Read More » | ||||
| | ||||
| ||||
Tuesday, October 8, 2013
FeedaMail: Comments for Sutter’s Mill
| ||||
| Comment on Trip Report: Fall ISO C++ standards meeting by Herb Sutter
You can follow the graphics discussion group listed at isocpp.org/forums. Read More »Comment on Trip Report: Fall ISO C++ standards meeting by Michael Marcin
Is there any way to get involved in the Graphics study group? Read More »Comment on Bjarne and I are speaking in Chicago on Tuesday night by GregM
VC++ 2010 /W4 warns you that you’re going to shoot yourself in the foot, and if you are good and use warnings as errors, it won’t even compile: warning C4172: returning address of local variable or temporary Read More »Comment on Bjarne and I are speaking in Chicago on Tuesday night by Herb Sutter
@GregM: Right. I don’t see why this would be a ‘ticking time bomb’ any more than similar code in C#, where lambdas *always* capture by reference and if you capture a Disposable object you get the same use-after-Dispose issue — only silently without saying “ref” or similar in the code. In this code, C++ actually forced him to write “&” everywhere to explicitly spell “capture by reference,” and he got exactly what he asked for. Read More »Comment on Bjarne and I are speaking in Chicago on Tuesday night by Philipp Lenk
I am very sorry for asking again despite it being off-topic, yet my rather limited understandig has left my quite confused. Was my observation of the codes behaviour wrong or is it simply no real problem because it has to be spelled out explicitly and would be hard to do without actually wanting to cause undefined behaviour? Read More » | ||||
| | ||||
| ||||