Arno Schoedl
@aschoedlSoftware developer, speaker, runner and hobby pilot. Looking for smart developers for my team.
Similar User
@cpponsea
@corecpp
@rainer_grimm
@Andreas__Fertig
@mateusz_pusz
@chandlerc1024
@code_report
@lefticus
@fenbf
@mattgodbolt
@mcypark
@__phantomderp
@mosquitoman81
@MartinMoene
@daminetreg
Just gave my talk Text Formatting For a Future Range-Based Standard Library at #usingstdcpp. For those of you interested, here are the details on how to do custom formatting with the new C++20 std::format: wgml.pl/blog/formattin… We really need an easier way...
But T const&& is actually fine. It is an rvalue, telling us that "a" is temporary, and at the same time it is const, so prevents moving out of "b". tc::common_reference in our library does it like that, as well as CONDITIONAL, our alternative to operator?:
Let's go through all reference types and see why they are bad. We cannot use T& or T const& because it turns the "a" rvalue into an lvalue. We lose the ability to reason about lifetime. We cannot use T&& because that would potentially move out of "b", which we did not std::move.
If a and b are both variables of type T, what is the type of (true ? a : b)? In current C++, it is T&. Fine. What is the type of (true ? std::move(a) : b)? It is T, which is an unfortunate pessimization because it copies T. Is there a better alternative? I believe yes, T const&&.
C++ needs "upward" copy elision, eliding copies when placing objects into members of other objects. It would require an ABI change, because constructors would need to publish if they want some of their arguments directly placed into memory, at some offset to "this".
We just added the string formatting with ranges to more of our code. When using them pervasively, through nesting, you get large trees of objects, objects aggregating sub-objects, in turn aggregating sub-sub-objects etc. There is no good solution for constructing these trees.
Thank you everyone for listening to my cppcon talk last week. The slides are now online: think-cell.com/en/career/talk… I let you know when the video is there, too.
If you are at #cppcon, here is the registration page for my talk. I will talk about how our Range library extends nicely to string processing and formatting: cppcon2018.sched.com/event/7f6b6620… Or simply try out the library and let me know how it goes.
Together with my talk at #cppcon, we will publish a new version of our think-cell library: github.com/think-cell/ran… We decided to change to the Boost license, so it can be used in commercial projects.
A good answer to a long-standing question: fluentcpp.com/2018/08/24/how…
I think there is a general lesson for API design here: If there is a well-established representation for some entity, support it. You can support more if you want, but not less.
Many HTTP query APIs take the headers as some sort of dictionary, for example MacOS, and do not offer passing the raw HTTP string representation. So in our MacOS abstraction layer, we must use a Spirit parser to take apart the string and pass it piece-meal to MacOS.
Short of flying non-stop, from Berlin to cppcon in Seattle, Icelandair with a layover in Keflavik is about as short as it gets, only 50 nm longer than the 4400 nm non-stop: gcmap.com/mapui?P=EDDT-B…. For comparison, London would add 280 nm to the journey, New York JFK 1150 nm.
Having to implement an OAuth2 client for Windows, I wonder when people say they are so much more productive in #Python or #Javascript than in C++, is that because the language in inherently more expressive, or are just the libraries more comprehensive?
My talk "Text Formatting For a Future Range-Based Standard Library" has been accepted to both @CppCon and @meetingcpp I will be talking about treating formatted numbers and other data as lazy text ranges, so they can be operated on with all the range tools we already have.
Brings some performance pessimization. Two possible solutions for the standard: allow operating on bitwise representations of types in constexpr context, even if the result is implementation-dependent, or allow overloading on constexpr.
Just changed the reference highwayhash implementation to be constexpr capable. Not difficult with C++17, just needed to replace all reinterpret_cast with bit-shifts.
In our use cases, the inefficiencies introduced by the simple work partitioning were more than compensated by savings in overhead for the work stealing, so the simpler parallel std::for_each is faster. Your mileage may vary.
We just checked out Visual Studio's parallel std::for_each implementation. Interestingly, it uses static work partitioning rather than the more complicated work stealing performed by Microsoft's older Concurrency Runtime.
So auto&& x=func() is fine, auto&& x=perfectforwarder(func()) is not. Very error-prone. Introduced a macro that creates some decay_if_necessary(decltype(expr)) x=expr that fixes the problem.
United States Trends
- 1. Southampton 63,8 B posts
- 2. Liverpool 157 B posts
- 3. Geraldo 6.416 posts
- 4. #AskFFT N/A
- 5. Rashford 13,2 B posts
- 6. Amorim 82,3 B posts
- 7. Mo Salah 20,3 B posts
- 8. #sundayvibes 10,2 B posts
- 9. #SOULIV 28,7 B posts
- 10. Good Sunday 73,9 B posts
- 11. #AskZB N/A
- 12. Xcretion N/A
- 13. #YNWA 3.985 posts
- 14. Amad 15 B posts
- 15. Robertson 14,1 B posts
- 16. Chuck Woolery 16,6 B posts
- 17. Michael Oliver 5.489 posts
- 18. Rachel Maddow 27,2 B posts
- 19. Jim Montgomery 2.072 posts
- 20. Defund NPR N/A
Who to follow
-
C++ on Sea
@cpponsea -
Core C++
@corecpp -
Rainer Grimm
@rainer_grimm -
Andreas Fertig
@Andreas__Fertig -
Mateusz Pusz
@mateusz_pusz -
Chandler Carruth
@chandlerc1024 -
Conor Hoekstra
@code_report -
Jason Turner
@lefticus -
Bartlomiej Filipek
@fenbf -
@[email protected]
@mattgodbolt -
Michael Park
@mcypark -
Björkus 'No time_t to Die' Dorkus
@__phantomderp -
Gianni Forlastro
@mosquitoman81 -
Martin Moene
@MartinMoene -
Damien Buhl
@daminetreg
Something went wrong.
Something went wrong.