Cpluzplus: November 2013

Saturday, November 30, 2013

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

C++11. Note that in the roadmap update C++14 generalized constexpr is a separate box on the right.

Comment on Visual C++ Compiler November 2013 CTP by rhalbersma

But inside those free functions, is the full C++14 relaxed constexpr syntax available (i.e for-loop and switch-statement) or only the single-return C++11 subset (i.e. recursion and ternary operator)?

(Sponsor this newsletter)

Delievered to you by Feedamail.
Unsubscribe

Friday, November 29, 2013

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

@tomasu82: You should be able to use constexpr on variable declarations and free functions, but not on member functions yet. That will be implemented eventually but did not make it into this CTP.

Comment on Visual C++ Compiler November 2013 CTP by tomasu82

With the new constexpr support, what exactly /is/ supported? I have some code that uses constexpr on some static class methods and const static member variables. Would that be supported? And if so, is there a way I can check that it is supported? say with a macro #if VER > ??

Thanks.

Comment on Visual C++ Compiler November 2013 CTP by Devid

Great that we have 2013 CPT already.
It would be even better if http://rise4fun.com/Vcpp will support VS 2013 RTM and CTP them too.

(Sponsor this newsletter)

Delievered to you by Feedamail.
Unsubscribe

Thursday, November 28, 2013

FeedaMail: Comments for Sutterâ€™s Mill

Comments for Sutter's Mill

(Sponsor this newsletter)

Comment on Visual Studio 2013 RC is now available by mathlasse

This constexpr code does not compiled in Visual Studio 2013 version 12.0.21005.1 REL

#include

constexpr int factorial(int n)
{
return n <= 1 ? 1 : (n * factorial(n – 1));
}

int main(void)
{
const int fact_three = factorial(3);
std::cout << fact_three << std::endl;
return 0;
}

Comment on Visual Studio 2013 RC is now available by Herb Sutter

@Mathlasse: VS 2013 doesn’t have constexpr. However, the November 2013 CTP does support constexpr on nonmember functions and this code compiles fine with the CTP.

(Sponsor this newsletter)

Delievered to you by Feedamail.
Unsubscribe

Monday, November 25, 2013

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.

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

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 :)

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?

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

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);     }

(Sponsor this newsletter)

Delievered to you by Feedamail.
Unsubscribe

Wednesday, November 20, 2013

FeedaMail: Comments for Sutterâ€™s Mill

Comments for Sutter's Mill

(Sponsor this newsletter)

Comment on Visual C++ Compiler November 2013 CTP by Source-based distros are awful (tipsy blog post)

[…] up pretty good. The current release (CTP) is going to cover roughly 70% of C++11/14 (source: Visual C++ Compiler November 2013 CTP | Sutter's Mill). C++ is accelerating. There is no doubt about […]

Comment on Visual C++ Compiler November 2013 CTP by Herb Sutter

@Christian: In the CTP, =default should now work for move special member functions, and generate what the compiler would have generated implicitly had the implicit generation not been suppressed (for example by declaring a copy operation or a destructor). In VS2013 RTM we didn’t yet allow =default for move ctor/op= because that compiler didn’t have the compiler-generated ones yet, so there was nothing for =default to do — now that the CTP has the compiler-generated ones, this also let us finish =default for move ctor/op=.

Comment on Visual C++ Compiler November 2013 CTP by Christian

This demonstrated the issue. Works with e.g. GCC 4.8.0, but not CTP.

  #include <vector>    int main()  {     class Y     {     public:        Y() {};          Y(const Y&) {};        Y& operator=(const Y&)         {           return *this;        };     };       class X     {     public:        Y y;          X() {};          // Not copyable        X(const X&) = delete;        X& operator=(const X&) = delete;    #if 1        // Doesn't compile        X(X&&) = default;        X& operator=(X&& rhs) = default;  #else        // Compiles        X(X&& rhs)        {           y = std::move(rhs.y);        };        X& operator=(X&& rhs)        {           y = std::move(rhs.y);           return *this;        };

Tuesday, November 19, 2013

FeedaMail: Comments for Sutterâ€™s Mill

Comments for Sutter's Mill

(Sponsor this newsletter)

Comment on Visual C++ Compiler November 2013 CTP by anonymous

clang has had “some” generic lambdas support for a while but since a couple of weeks it seems like really robust. They are awesome, in particular when combined with boost fusion:

  auto tuple = std::make_tuple(1, 2.0, "hello!");  boost::fusion::for_each(tuple, [](auto i) { std::out << i << ", "; });  // 1, 2.0, hello! :)

Comment on Visual C++ Compiler November 2013 CTP by Herb Sutter

@anon: Thanks for the pointer!

@Sometime: This is a compiler-only CTP to give a preview of new compiler features, it does not include library updates. Of course, when these features hit the full product in a future release, they’ll be complete including library support (among other library updates).

Comment on Visual C++ Compiler November 2013 CTP by SometimeSomewhere

@Herb: Thats excellent news and it’s nice to see a more rapid release schedule from the C++ visual studio team.

That said will there be any library updates along with the CTP, my understanding/experience is that there are a number areas that need tending to with regards to the most recent VS2013 release.

Comment on Visual C++ Compiler November 2013 CTP by Herb Sutter

@JC_Yang: Bug fixes will go into Updates as they are available. The CTP is a separate stream.

Comment on Visual C++ Compiler November 2013 CTP by JC_Yang

Are there any bugfixes for the VS2013 RTM compiler included in this CTP or they will be only available in the coming VS2013 supported-updates? There’re 6 bugs I know of(I’m tracking 5 of them, 1 is reported by me which is about wrong template instantiation point).

Comment on Visual C++ Compiler November 2013 CTP by Ricardo Costa

Great news, Herb.

Does operator new return memory aligned in accordance to the alignas specification? The MSDN documentation for __declspec(align()) explicitly states that it doesn’t, but __declspec(align()) is not a real language feature, unlike alignas, so I’m wondering if that restriction has changed. Thanks.

Comment on (V)C++ recorded talks at VS 2013 Launch by nosenseetal

I was thinking about more of a small LRU cache, if you want to have flexible size you cant use contiguous “array” buffer because linear search will kill your perf.
and for delete this i kind of dislike it because it means ppl containing this class need to be aware of its suicidal :P aspirations. :)

BTW regarding that code:
auto * context = static_cast(response._get_server_context());

I have never before seen auto * before.(ignoring const I have seen only auto, auto&, auto&&)
Do you have any comment on using auto*?

Comment on Visual C++ Compiler November 2013 CTP by Herb Sutter

@Pal: It is a separate stream, think of it as (usually) an early preview of the next major release that’s worked on in a different branch from the current release’s servicing branch. Then it’s the usual decision for each bug fix as to whether to apply it to the current release via Updates, to the next release which would appear in CTP, or both branches. HTH

Comment on (V)C++ recorded talks at VS 2013 Launch by Herb Sutter

@nosenseetal: Using auto or auto* deduces the same type, just I guess auto* is mostly useful to explicitly say you want a raw pointer. Non-owning raw pointers are okay to observe an object that will outlive them, such as a tree node owned by its parent (via a unique_ptr(node), say) and observing its parent via a node*. I don’t have any more guidance than to say my impression is that it’s a style point whether you prefer code like “auto p = my_parent();” or “auto* p = my_parent();” — the type is the same in either case.

Comment on GotW #94 Solution: AAA Style (Almost Always Auto) by Yongwei Wu

People already mentioned searchability, but that is only part of tool support. There are others. For example, ctags is a popular tool used with editors like Vim: I bet it does not support the new syntax well. Even compilers like VC 2012, which I currently use, do not support all the needed language features.

Comment on Visual C++ Compiler November 2013 CTP by Balog Pal

Please clarify the update thing. I get it’s a separate stream, but that leaves the update policy open. If the RTM gets a service pack released fixing bugs will the relevant changes merged over to the CTP stream creating an update of that too within some reasonable time? Or we can consider it isolated from mainstream fixes?

Comment on Visual C++ Compiler November 2013 CTP by Petter

Congratulations! It is great to see rapid progress!

Comment on Visual C++ Compiler November 2013 CTP by Fabio

Is there any ETA on a SP for the RTM? It contains a bunch of reproduceble ICEs (8 that I am aware of at connect) This really hinders us moving on to 2013

(Sponsor this newsletter)

Delievered to you by Feedamail.
Unsubscribe