FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	(Sponsor this newsletter) Comment on Visual C++ Compiler November 2013 CTP by Herb Sutter @HGH: Good questions, see http://channel9.msdn.com/Events/Build/2013/2-306. Summarizing: There are two streams, release and CTP, and by default you should expect new features to show up in the CTP stream and then in the next major release, not in Updates which are more about stability improvements. We do ship other kinds of features in Updates, such as IDE features that don’t break customers, but the compiler is widely depended upon and changes there can cause source breaking changes, so we normally do not ship compiler changes in Updates. This is especially true now as the source base is undergoing high rate of change both for new features and for AST and other rejuvenation; shipping constexpr would require shipping a major compiler source diff which is fine on a major release when people are expecting to tweak their sources in adopting a new compiler, but it would likely surprise a lot of people that they have to treat an Update that way. Re date: We have not announced a date by which we’ll be fully compliant, in part because we don’t know :), and because we think reporting actual progress regularly is probably better than promises. So we have published a roadmap and have been updating it (most recently on the linked post) to share what we know when we know it. This way, you can extrapolate speed and expectations yourself based on the rate at which we actually ship features. Read More » Comment on GotW #1 Solution: Variable Initialization – or Is It? by Kirill Prazdnikov Hi, I`m trying to understand this: widget w = x; // (f) You have commented that: >> If x is of some other type, …. Assuming that an implicit conversion is available, (f) means the same as widget w( widget(x) );. I do not understand why ? I wrote a test using VS 2013 and found that it invokes only one constructor (and it`s this pointed to the x) : struct widget { widget(int) { cout << "widget(int)\n"; } widget(const widget &) { cout << "widget(int)\n"; } }; widget x = 5; What am I doing wrong ? Thanks Read More » Comment on Recommended reading: Why mobile web apps are slow (Drew Crawford) by Sebastian Bohmann Basically, it boils down to this: In case you really absolutely have to use JavaScript with its high overall performance impact in an environment without massive headroom for memory, memory throughput, CPU power, &c., by all means do so, but: Keep things as simple and flat as possible. Do not use higher abstraction idioms and automation patterns that by definition generate lots of heap allocations. Refrain from following the otherwise great suggestion to use immutable instances for avoiding shared immutable state. Just reuse preallocated instances of what you need, i.e. do your own flat memory management, and learn to live with all kinds of coroutine safety issues due to shared mutable state (it doesn’t take threads for that becoming an issue at all), and just generally behave as if you were writing C code for a micro controller with harsh memory limits. And by all means refrain from heavy manipulation of the DOM tree – instead switch things to being visible / invisible, and just set basic numeric attributes for changing their appearance – may be tricky sometimes, but this way the tree’s structure isn’t modified, which would be way more heavyweight. Also, restrict use of hash maps (including objects, as they are implemented in JS using them) – it’s best to initialize all complex data on startup and leave their structure alone from then on. Just setting values for existing keys is not that much of a problem, of course – without being allowed to do that, mutating instances of objects wouldn’t be possible as well… Just forget about the idea that you’re dealing with a platform that supports OOP, except for data structures that can be set up once in the beginning and just used from that point without changing the object graphs. It really is just a question of selecting an appropriate architecture, and refraining from doing the kind of UI projects this way that need all the flexibility and performance you get by writing native code. Due to the inherently lower degree of abstraction that results from the flat approach I am proposing, it is often less work to just write the UI with the right degree of abstraction in Objective C and C++ (and / or maybe Java / C#) for the three predominant mobile platforms, plus maybe a shared core in C++, than to jump through all the hoops that become necessary if you give up most tools for achieving a higher level of abstraction as described. The time saved by being able to correctly model state with immutable value representations and not having to chase race conditions caused by mutation from different parts of the call stack alone will probably more than justify doing several things twice, or even thrice :) Read More » Comment on Visual C++ Compiler November 2013 CTP by HGH Interesting but.. Will all these features and the full C++11/14 support you’ve talked about be as a VS 2013 update or they will be released as VS2014/VS2015? Will complete support for the specifications (compiler and library support) happen in 2014 or the year after? Read More » Comment on GotW #7b: Minimizing Compile-Time Dependencies, Part 2 by A.J. Green Jersey Wholesale cheap NFL Iphone Case for sale with free shipping Read More » Comment on GotW #2 Solution: Temporary Objects by Kenneth Ho Hi Sutter, I failed to find a more appropriate article to post this question, so here it goes. Why doesn’t std::min/max take URefs? I imagine something along the lines of the following would be reasonable: template <typename T> T min(T&& v1, T&& v2) { return v1 < v2 ? std::forward<T>(v1) : std::forward<T>(v2); } Read More »
	(Sponsor this newsletter)
	Delievered to you by Feedamail. Unsubscribe