BudVVeezer's comments

BudVVeezer | 8 years ago | on: C++17 is formally approved

It's consistent with for (init; condition;) {} and solves a problem like:

if (std::vector<int> v = f(); !v.empty()) { // Use v }

without requiring an extra compound statement to limit the scope and lifetime of v.

BudVVeezer | 8 years ago | on: Trip report: Summer ISO C++ standards meeting in Toronto

Not quite.

It was submitted for PDTS (proposed draft technical standard), which means it goes out for balloting to ISO national bodies. That balloting either succeeds (at which point you have a Techincal Specification) or it comes back to the committee with comments that the committee then has to respond to (and then another round of balloting happens). Once it's accepted as a Technical Specification, it's still not part of the C++ International Standard. That's a decision the committee comes to at their own pace, much like what happened at this meeting where the Concepts TS was accepted (as amended) into the IS.

Think of a TS somewhat like a beta. There's no assurance that the contents of the TS will go into the IS at all or in the exact form it was originally specified in, but that's certainly the hope when the TS is published.

BudVVeezer | 9 years ago | on: Software Engineering Institute Makes CERT C++ Coding Standard Freely Available

What's considered critical or difficult to discover is a bit subjective, but:

It's easy to forget that alignment is important on some architectures (other than for performance reasons), so be careful when using placement new: https://www.securecoding.cert.org/confluence/display/cpluspl...

This may seem obvious, but even the C++ committee got this one wrong when they created auto_ptr (which has since been removed from the standard): https://www.securecoding.cert.org/confluence/display/cpluspl...

This one is totally obvious but has a stunning number of ways you can fail to adhere to it, some of which look reasonable at first blush: https://www.securecoding.cert.org/confluence/display/cpluspl...

BudVVeezer | 9 years ago | on: Notes on Programming in C – Rob Pike (1989)

Yes and no. Many compilers support #pragma once, but whether your build environment handles it is another matter. Having your headers on network drives, or having symlinks to your headers, etc can cause issues with #pragma once handling (depending on the implementation) that can often be hard to track down, especially if building with multiple compilers. Include header guards do not have these issues.

BudVVeezer | 10 years ago | on: C++ Status at the end of 2015

The author may be a bit confused as to what C++17 will be. Modules will be in a TS, most likely. Transactional memory, concepts, ranges, and filesystem are already in published TSes (not planned for the IS in this round). Out of the list presented, only fold expressions and __has_include are actually already voted in for C++17 itself. The rest are in various stages of standardization (mostly TSes) and are not guaranteed to ever become part of the IS (though hopefully many will).

BudVVeezer | 10 years ago | on: Atria: A toolkit for modern C++ development from Ableton

Boost is a very large project with varying degrees of API quality, and so when you say it depends on boost, I wonder "the good parts (any, variant, stuff that usually gets looked at for standardization)" or "the bad parts (Spirit, etc)". Also, as others have said, it's a huge dependency that generally raise a red flag (for performance and compile time).

BudVVeezer | 10 years ago | on: Unicode skin-tone modifiers

I think this is a good step in the right direction, but still falls short. For instance, it's heavily gender binary, and has odd cultural mismatches such as "man with turban" but no "woman with hijab." However, major kudos to the Unicode consortium for their work on this -- it's a very challenging set of subjects to get into!

BudVVeezer | 11 years ago | on: How to implement a constant-expression counter in C++

This topic was discussed in Lenexa at last week's C++ standards meeting, and the direction the core working group was thinking was that this should be ill-formed, but is currently under specified. I would not rely on this ADL constexpr trick working for long (at least until CWG has had the chance to really pick apart the issue and change the wording to explicitly allow it).

BudVVeezer | 11 years ago | on: C99 tricks

One of the two values (a or b) gets evaluated twice. Eg)

  min(a++, b++);
a or b would really be incremented twice.
page 1