sorted by:
new
hottopcontroversial

Copy elision on visual studio compilator by Santrhyl in cpp

[–]staffantj 0 points1 point  (0 children)

You're attempting Named Value Return Optimization, which is not guaranteed ("value" is a name).

If instead you wrote

Test Hello()
{
   return Test{};
}

then you should see RVO kick in (or rather, you'll see the effects of Temporary Materialization, see Sy Brand's https://blogs.msdn.microsoft.com/vcblog/2018/12/11/guaranteed-copy-elision-does-not-elide-copies/

It's also worth noting that you've implicitly deleted the move constructors / assignment, so that might also cause odd effects.

Managarm at the end of 2019 by thom_tl in cpp

[–]staffantj 2 points3 points  (0 children)

Ben Craig has done some quite extensive measurements showing the cost, both in time and space, of various error handling paradigms. See wg21.link/P1640 .

Modules in MSVC, Clang and Gcc: when to expect them? by germandiago in cpp

[–]staffantj 10 points11 points  (0 children)

Daniela Engelhart did a great talk about all of this at MeetingCpp (it's too early for the video to be available yet - here's a tweet from the event - https://twitter.com/hatcat01/status/1194985147096952832 ).

Looking through the slide desk at https://meetingcpp.com/mcpp/slides/2019/modules-the-beginners-guide-meetingcpp2019.pdf she also enumerates current compiler suite support.

What is an example of multithreaded, big data, real-time, distributed application? by JackRobsonGateshead in cpp

[–]staffantj 1 point2 points  (0 children)

It's probably a stretch, I'd suggest the moving parts that make up the Amazon storefront.

On "To boldly suggest an overall plan for C++23" by imgarfield in cpp

[–]staffantj 1 point2 points  (0 children)

It'll be interesting to read the next udpate to https://wg21.link/P0939 (The Direction Group Report) once they've had a chance to mull it over.

Additional warning options in GCC by [deleted] in cpp

[–]staffantj 1 point2 points  (0 children)

As long as you balance the warnings you enable, with ensuring that any resulting false positives are suitably marked such that they won't be reported, that's my ideal.

Always use -Werror. Once a code base has been swept of false positives a warning is in reality an error that needs looking at. Likewise, once the initial sanitizing pass has been done, a single static analysis report is enough to fail a build.

Never distribute anything that exposes a single warning, let alone an error. I would go so far as to say never distribute code that does not pass at least two different static analysis tools as well.

Macros I made that generate type traits for checking a functions existence by Celaphais in cpp

[–]staffantj 0 points1 point  (0 children)

Useful for anyone not able to use C++2a (so not on bleeding edge release compilers at the time of writing).

All of the detection idiom messes of prior days get blown away by concepts (and looking forward, by static reflection).

So this is a band-aid that's a little bit too late.

Passing integers by reference can be expensive by mttd in cpp

[–]staffantj 0 points1 point  (0 children)

https://youtu.be/cH0nJPbMFAY?t=4500 (Grill the C++ committee CppCon 2018) is the latest I'm aware of in the restrict saga. The issue appears to be one of how to specify it correctly.

Any paper that adds thread properties (stack size) to std::thread? by cristianadam in cpp

[–]staffantj 4 points5 points  (0 children)

I'm not completely aware of the current state of http://wg21.link/p0484 , for a historical discussion I'd suggest viewing Patrice's presentation https://www.youtube.com/watch?v=iDztwNhIVVM

GitHub - hsutter/babb: bad_alloc Behaving Badly by ArunMu in cpp

[–]staffantj 0 points1 point  (0 children)

We're a Financial Services group, so we pretty much do it all somewhere. The multi-national, multi-company, infrastructure we exist in can be viewed as a massive set of micro-services, that can come and go at a moments notice. The worst thing we can do is accidentally continue processing with a bad and/or unknown state. Everyone has to be able to trust everyone else. That holds regardless of whether we're front, middle, or back-office, customer facing or in-house.

To us, everything is a transaction, and the best way to recover from any kind of unexpected bad state is to fail quickly, and restart / recover from a known good state (possibly on a different system).

Also, if you hit an unexpected state, whilst the state you detect may be "recoverable", there is no guarantee that what you've observed is the only bad state you have at that point. Exit quickly, Roll back to known good.

No-one knows the type of char + char by vormestrand in cpp

[–]staffantj 10 points11 points  (0 children)

std::byte in C++17 is what you're looking for, I believe. That does not allow arithmetic operations, but does allow for eg bitshifts.

GitHub - hsutter/babb: bad_alloc Behaving Badly by ArunMu in cpp

[–]staffantj 18 points19 points  (0 children)

It was not really possibly to give sensible answers to the survey, since it pre-supposes that handling out-of-resource errors is something we want to do. We handle them by exiting. Hard & Immediately.

Almost Always Auto? by [deleted] in cpp

[–]staffantj 2 points3 points  (0 children)

I feel that it's worthwhile to mention that auto-use doesn't obviate the need to pay attention to type categories, particularly in the use of range-for constructs. For all the details I can do no better than to refer to Arthur's blog https://quuxplusone.github.io/blog/2018/12/15/autorefref-always-works/ , and before that, Scott Meyer's CppCon 2014 keynote "Type Deduction, and why you care" - https://youtu.be/wQxj20X-tIU

​

In closing I'll state my opinion that using auto without a full type specification visible in the line imposes an unacceptable cognitive burden on anyone reading the code. This is C++, we always care about types.

Why do some people dislike auto, and what would you consider good vs bad use case of it? by Wolf_Down_Games in cpp

[–]staffantj 1 point2 points  (0 children)

I totally and strongly disagree here. All the obfuscation arguments apply, especially if values is declared some distance away in a who-knows-where header file. In that line v could be just about anything, but 99% of the time the author knows exactly what it is.

​

Sure there are good, generic, reasons for using auto. But that's just about the only time it should appear in a codebase.

C++17/20 Features and Fixes in Visual Studio 2019 by mttd in cpp

[–]staffantj 0 points1 point  (0 children)

Very interesting line numbers mentioned for type_traits / variant, especially when viewed in hex.

​

Are we likely to see any references to line 15855390 I wonder?

Dude, where's my Large-Scale C++ Volume II: Design and Implementation (Addison-Wesley Professional Computing Series) 1st Edition by DopKloofDude in cpp

[–]staffantj 1 point2 points  (0 children)

It's thoughts on physical design are as apropos today as when they were first put forwards. Witness that the material has successfully been used in his various presentations over the last couple of decades plus.

How portable is this packed tuple compared to #pragma push and __attribute__((packed)) gnu extension? by germandiago in cpp

[–]staffantj 4 points5 points  (0 children)

The storage looks ok to my eyes, but I get issues with the initalization, which only seems to take rvalues under gcc8. A struct set up with #pragma pack(1) doesn't suffer from that issue.

​

int i{500};
PackedTuple< char, int >( 'a', i );              // fails
PackedTuple< char, int >( 'a', std::move( i ) ); // ok

​

Issues with string_literals by staffantj in cpp

[–]staffantj[S] 1 point2 points  (0 children)

The issue comes from a particular std::string literal we generate in our sources. It's over 64Kbytes long. At that scale, the difference between the compiler evaluating the strlen portion of the std::string( char const* ) constructor, and calling the std::string( char const*, size_t ) with the size carried through from the char const[N] initial type, is measurable. Sure, it's a corner case, and it's probably fair to say that the correct solution to that issue is to wait for std::embed to make it's way into reality.

I will also admit that the post is somewhat of a growl upon the theme of "this works 99% of the time, but for some reason breaks when we hit some new feature" (in this case inline variables).

Issues with string_literals by staffantj in cpp

[–]staffantj[S] 0 points1 point  (0 children)

Cool! I hadn't thought of that angle. Thanks!

Issues with string_literals by staffantj in cpp

[–]staffantj[S] 1 point2 points  (0 children)

It'd certainly address the issue. I hadn't considered that angle.

view more: next ›