search for: emplacement

...tfields, NULL, static member. Using emplace can also lead to memory leak in case of smart ptrs " auto *ptr = new int(1);v.push_back(std::unique_ptr<int>(ptr)); This is because replacing it with emplace_back could cause a leak of this pointer if emplace_back would throw exception before emplacement (e.g. not enough memory to add new element).". In the case of push_back/emplace_back for the same type, there should be no performance changes, however emplace_back might generate more template instantiations slowing down compilation. There is also topic of using insert/emplace for maps show...

...ng emplace can also lead to > memory leak in case of smart ptrs > " > > auto *ptr = new int(1);v.push_back(std::unique_ptr<int>(ptr)); > > This is because replacing it with emplace_back could cause a leak of this > pointer if emplace_back would throw exception before emplacement (e.g. > not enough memory to add new element).". > > In the case of push_back/emplace_back for the same type, there should be > no performance changes, however emplace_back might generate more template > instantiations slowing down compilation. > > There is also topic of u...

...ng emplace can also lead to > memory leak in case of smart ptrs > " > > auto *ptr = new int(1);v.push_back(std::unique_ptr<int>(ptr)); > > This is because replacing it with emplace_back could cause a leak of this > pointer if emplace_back would throw exception before emplacement (e.g. > not enough memory to add new element).". > This seems, IMHO, not a useful argument for LLVM since it does not try to use exception based error handling to recover. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail...

...anager http_access allow localnet http_access allow localhost http_access deny all # Ports du proxy http_port 3130 http_port 3128 intercept https_port 3129 intercept ssl-bump \ cert=/etc/squid/ssl_cert/nestor.microlinux.lan.pem \ generate-host-certificates=on dynamic_cert_mem_cache_size=4MB # Emplacement de ssl_crtd et du cache des certificats TLS sslcrtd_program /usr/lib64/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB sslcrtd_children 8 startup=1 idle=1 # SSL-Bump acl step1 at_step SslBump1 ssl_bump peek step1 ssl_bump bump all # Taille du cache dans la RAM cache_mem 2048 MB # Emplacement et taille...

...emplace can also lead to memory leak in case of smart ptrs >> " >> auto *ptr = new int(1); >> v.push_back(std::unique_ptr<int>(ptr)); >> This is because replacing it with emplace_back could cause a leak of this pointer if emplace_back would throw exception before emplacement (e.g. not enough memory to add new element).". >> >> >> This seems, IMHO, not a useful argument for LLVM since it does not try to use exception based error handling to recover. > > > This, and also we should not write code like that (naked pointers, calling new),...

...ng emplace can also lead to > memory leak in case of smart ptrs > " > > auto *ptr = new int(1);v.push_back(std::unique_ptr<int>(ptr)); > > This is because replacing it with emplace_back could cause a leak of this > pointer if emplace_back would throw exception before emplacement (e.g. > not enough memory to add new element).". > > > This seems, IMHO, not a useful argument for LLVM since it does not try to > use exception based error handling to recover. > > > This, and also we should not write code like that (naked pointers, calling > new),...

...ic member. Using emplace can also lead to memory leak in case of smart ptrs > " > auto *ptr = new int(1); > v.push_back(std::unique_ptr<int>(ptr)); > This is because replacing it with emplace_back could cause a leak of this pointer if emplace_back would throw exception before emplacement (e.g. not enough memory to add new element).". > > > This seems, IMHO, not a useful argument for LLVM since it does not try to use exception based error handling to recover. This, and also we should not write code like that (naked pointers, calling new), using make_unique<> f...

According to the documentation at http://llvm.org/docs/GettingStarted.html#software, compiling LLVM with GCC requires at least version 4.7.0. However, there are apparently several problems building current LLVM/Clang with gcc 4.7.X. This proposal is to increase the minimum required GCC to 4.8. This is split off of the thread started here:

...ng emplace can also lead to > memory leak in case of smart ptrs > " > > auto *ptr = new int(1);v.push_back(std::unique_ptr<int>(ptr)); > > This is because replacing it with emplace_back could cause a leak of this > pointer if emplace_back would throw exception before emplacement (e.g. > not enough memory to add new element).". > > > This seems, IMHO, not a useful argument for LLVM since it does not try to > use exception based error handling to recover. > > > This, and also we should not write code like that (naked pointers, calling > new),...

Hey Ben, This change broke some clangd code (no failing test, mea culpa), because it changed the move semantics. Previously: a moved-from llvm::Optional was None (for all types). Now: a moved-from llvm::Optional is None (for non-trivial types), and has the old value (for trivial types). FWIW, a moved-from std::optional is *not* nullopt, and contains the moved-from value. This seems sad to me,

That's an unintentional change. However, the reason for this change was to make optional of trivially copyable types trivially copyable, adding a user-provided move ctor would break that again :( I'm leaning towards making the non-trivial version of llvm::Optional more like std::optional. In the long term std::optional is going to replace llvm::Optional. How bad would that be for your use

The upcoming C++1z (probably C++17) standard will not contain several things - most notably auto_ptr. Soon, libc++ will not be providing auto_ptr by default when building in C++1z mode. You'll be able to get it back with a "-D_LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR" on your command line, or "#define _LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR" before including any libc++ header

On Wed, Jan 24, 2018 at 11:47 PM, Benjamin Kramer <benny.kra at gmail.com> wrote: > That's an unintentional change. However, the reason for this change > was to make optional of trivially copyable types trivially copyable, > adding a user-provided move ctor would break that again :( > > I'm leaning towards making the non-trivial version of llvm::Optional > more

...?MOIN !**](http://r.email.demande-informations.com/mk/cl/f/sh/SMK1E8tHeFuBncRiJvdin0HLJMa9/MHCUwnOda2Lscontact/) ------------------------------------------------------------------------------- Les 5 bonnes raisons -------------------- 1 - Une **destination exceptionnelle** tr?s pris?e 2 - Un emplacement de choix dans le sud de l??le **? quelques minutes des plages** 3 - Des lodges? **de grande qualit?**? r?alis?s avec des mat?riaux nobles et une d?coration soign?e 4 - Des services **premium** ? disposition toute l?ann?e ? Piscine chauff?e, Flotarium, Sauna, Hammam, Conciergerie, Epicerie f...

...library() > .libPaths() [1] "C:/R/library" > library(DBI) > library(RMySQL) Error in dyn.load(x, as.logical(local), as.logical(now)) : impossible de charger la biblioth?que partag?e 'C:/R/library/RMySQL/libs/RMySQL.dll': LoadLibrary failure: L'acc?s ? cet emplacement de la m?moire n'est pas valide. Erreur : le chargement du package / espace de noms a ?chou? pour 'RMySQL' > ------------------------------------ -- View this message in context: http://www.nabble.com/I-can%27t-do-it-again-on-an-other-PC-%3A-R%2BRMySQL--%3Eerror-loading-dll-tf4414...

2017-01-26 3:28 GMT+01:00 Richard Smith <richard at metafoo.co.uk>: > On 25 January 2017 at 15:03, Hal Finkel via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> Hi Piotr, >> >> I think makes sense. Modulo bitcasts, the invariant is identified by a >> particular pointer SSA value. Given that you can't sensibly have two >> nonequivalent

LLVM Weekly - #130, Jun 27th 2016 ================================= If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/130>. Welcome to the one hundred and thirtieth issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex

Dear Community, The patch for Interprocedural Register Allocation has been committed now , thanks to Mehdi Amini for that. We would like you to play with it and let us know your views and more importantly ideas to improve it. The test-suite run has indicated some non trivial issue that results in run time failure of the programs, we will be investigating it more. Here are some stats :

2017-01-26 15:41 GMT+01:00 Hal Finkel <hfinkel at anl.gov>: > > On 01/26/2017 06:44 AM, Piotr Padlewski wrote: > > > > 2017-01-26 3:28 GMT+01:00 Richard Smith <richard at metafoo.co.uk>: > >> On 25 January 2017 at 15:03, Hal Finkel via cfe-dev < >> cfe-dev at lists.llvm.org> wrote: >> >>> Hi Piotr, >>> >>> I think

On Wed, Jun 15, 2016 at 6:16 AM, Quentin Colombet <qcolombet at apple.com> wrote: > Hi Vivek, > > How much of the slow down on runtime comes from the different layout of > the function in the asm file? (I.e., because of the dummy scc pass.) > > Hello Quentin, Please do not consider previous results as there was a major bug in RegMask calculation due to not considering