search for: raii

...t is helpful > don?t use C++ to interface with R There are now more than 1,600 packages on CRAN using C++, the time is long past when that type of warning is going to be useful to the R community. These same issues will also occur with any newer language (such as Rust or Julia[1]) which uses RAII to manage resources and tries to interface with R. It doesn't seem a productive way forward for R to say it can't interface with these languages without first doing expensive copies into an intermediate heap. The advice to avoid C++ is also antithetical to John Chambers vision of first S a...

...understand it, all of the problems raised are solvable: either through a well-defined C++ interface, or through better education. I'll add my own opinion: writing correct C code is an incredibly difficult task. C++, while obviously not perfect, makes things substantially easier with tools like RAII, the STL, smart pointers, and so on. And I strongly believe that C++ (with Rcpp) is still a better choice than C for new users who want to interface with R from compiled code. tl;dr: I (and I think most others) just wish the summary had a more positive outlook for the future of C++ with R. Best,...

On Oct 13, 2008, at 1:07 PM, Chris Lattner wrote: > > Exceptions have a high cost in terms of code size, binary size, and > even a bit of execution time. Also, they don't magically make the > code safe from any error: code has to be designed specifically to use > RAII and other techniques to handle exceptions properly. Reading a C+ > + trade magazines/books about EH topics will give you an idea of the > complexity involved in doing it right. Further, as I mentioned up- > thread, turning aborts into exception throws won't save you from null > po...

...like rchk and improved documentation such as Tomas?s post. That?s a start, but it appears that there still is a lot of knowledge that would deserve to be promoted to actual documentation of best practices. I think it is important to not equate C++ as a language, and Rcpp. Also, C++ is not just RAII. RAII is an important part of how Rcpp was conceived for sure, but it?s not the only thing C++ can bring as a language. Templates, lambdas, the stl are examples of things that can be used for expressiveness when just accessing data without interfering with R, calling R api functions ... It woul...

...her recovery > strategies), but not just report a failure to the external world? Exceptions have a high cost in terms of code size, binary size, and even a bit of execution time. Also, they don't magically make the code safe from any error: code has to be designed specifically to use RAII and other techniques to handle exceptions properly. Reading a C+ + trade magazines/books about EH topics will give you an idea of the complexity involved in doing it right. Further, as I mentioned up- thread, turning aborts into exception throws won't save you from null pointer or garba...

On Oct 13, 2008, at 12:42 PM, Chris Lattner wrote: >> >> Currently there no way to recover if the IR contains some >> construct that codegen can't handle. This is unfortunate for some >> applications. > > I completely agree, but these should not be fixed with exceptions: > this should be fixed by adding a direct failure reporting mechanism. > > -Chris

...ct 13, 2008, at 1:07 PM, Chris Lattner wrote: >> >> Exceptions have a high cost in terms of code size, binary size, and >> even a bit of execution time. Also, they don't magically make the >> code safe from any error: code has to be designed specifically to use >> RAII and other techniques to handle exceptions properly. Reading a >> C+ >> + trade magazines/books about EH topics will give you an idea of the >> complexity involved in doing it right. Further, as I mentioned up- >> thread, turning aborts into exception throws won't sav...

...because if this leads to some solution, the recommendation in the future may change to "use C++ using tools XYZ". > I'll add my own opinion: writing correct C code is an incredibly difficult task. C++, while obviously not perfect, makes things substantially easier with tools like RAII, the STL, smart pointers, and so on. And I strongly believe that C++ (with Rcpp) is still a better choice than C for new users who want to interface with R from compiled code. > My take is that Rcpp makes the interface *look* easier, but you still have to understand more about the R API that y...

...projects are cppm (https://github.com/istenith/cppm) CSC19 (https://github.com/istenith/CSC19) I believe the reasons I am a fit for this project are: - Ability to write generic code - Knowledge of internal workings of *C++*, *compilers*, and the *platforms(hardware concepts)* (ex.TMP, constexpr, RAII, RVO, cache lines, move semantics, undefined behaviors, thread-safety, etc.) *Which I came to know about, by closely following C++ communities and events such as cpplang.slack.com <http://cpplang.slack.com/>, CPPcon, core guidelines <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuide...

...o interface with R > > There are now more than 1,600 packages on CRAN using C++, the time is > long past when that type of warning is going to be useful to the R > community. > > These same issues will also occur with any newer language (such as > Rust or Julia[1]) which uses RAII to manage resources and tries to > interface with R. It doesn't seem a productive way forward for R to > say it can't interface with these languages without first doing > expensive copies into an intermediate heap. > > The advice to avoid C++ is also antithetical to John Cha...

...ions out of a loop one at a time. The live ranges of the intermediate steps look completely different from the final result. So for a future automatic liveness API, I imagine something like: LIS.beginChanges(); .. Move multiple instructions around. .. LIS.endChanges(); [Or it could use RAII, that's not important] MachineFunction would provide observer hooks that LIS can use to collect a set of changed instructions. The call to LIS.endChanges() would then recompute the invalid live ranges. /jakob

Jakob, Seems like an easy solution for this case... But let me ask you a more general question. The reason I kept on hanging on to the MBB->splice was (probably outdated) assumption that it will one day properly update liveness for instructions it moves... That is a serious matter for what I am trying to do (global code motion in presence of bundles). What is the current thinking? Will

...of parts of the codebase that are working around VS2013's inability to generate move constructors. This is all over the new PM code and the passes ported to the new PM. It has caused me personally hours of lost time and generally penalizes good coding practices (exporting lifetime management to RAII is only so convenient if you can't have a move-only type like a unique_ptr without manually writing out move constructor/assign; and the diagnostics when this VS2013 deficiency raises its head are.... confusing). -- Sean Silva > --paulr > > > > *From:* llvm-dev [mailto:llvm-d...

...base that are > working around VS2013's inability to generate move constructors. > This is all over the new PM code and the passes ported to the new PM. > It has caused me personally hours of lost time and generally penalizes > good coding practices (exporting lifetime management to RAII is only so > convenient if you can't have a move-only type like a unique_ptr without > manually writing out move constructor/assign; and the diagnostics when this > VS2013 deficiency raises its head are.... confusing). > > -- Sean Silva > > > >> --paulr >> &g...

Thanks for pointing this out, Tim. Then maybe this approach is not the best choice for x86, though ideally measuring is needed, it is just that on ARM the current x86 approach is not applicable because ARM doesn't have a single return instruction (such as RETQ on x86_64), furthermore, the return instructions on ARM can be conditional. I have another question: what happens if the instrumented

...t;> working around VS2013's inability to generate move constructors. >> This is all over the new PM code and the passes ported to the new PM. >> It has caused me personally hours of lost time and generally penalizes >> good coding practices (exporting lifetime management to RAII is only so >> convenient if you can't have a move-only type like a unique_ptr without >> manually writing out move constructor/assign; and the diagnostics when this >> VS2013 deficiency raises its head are.... confusing). >> >> -- Sean Silva >> >> >&...

There are certainly enough people making commits that work with VS2015 but not VS2013 that the "would it be useful" question is pretty well answered. I've already brought up the idea on my team, as it's obviously coming and we need time to coordinate with internal consumers of the toolchain. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Zachary

...s from the community. I've pinged a couple community members already, and here is a sampler of ideas that have come up: * a "blame" that digs up as much info as it can: commit messages, relevant code review threads, etc. * a way to track trends in C++ usage (naked new/delete, pimpl, RAII, etc.) * using MC to dig around in machine code looking for performance bugs * astmatchers ?????? PROFIT I'd like to hear any interesting ideas in this general area. This is a larger idea which I think I might be able to get a first prototype of: "Clang Auto-Patcher": Look at textu...

...earlier, pretty much a line-for-line translation of the original example. The c++-style casts made the (already ugly) lines with casts even uglier by the way... The difference in the second version is that the metadata objects are no longer heap-allocated. This is more in line with the concept of RAII, and removes the need to keep setting and checking the 'ok' bool, which in the first version needs to be done from the moment the metadata[] is created. The only downside is that users following this example would need to remember to make sure the metadata objects are kept in scope for the...

Hi. I'm working on a very simple C++ wrapper for parts of libogg and libvorbis; I thought I would expose it for initial comments and the generally curious. No conveniences, no frills. No helpful higher-level abstractions. Just a translation from ogg_method_foo(ogg_method* data) to classes that hold the ogg_stream_state etc., so you may type mypage.bos() instead of