search for: createfoo

...about. > Apart from the complexity and visual clutter, it's pretty annoying to have > to decide whether to get(), release() or somehow else acquire the object > you just created. The result of using smart pointers as returns isn't > pretty -- you end up with awkward code like createFoo().get()->func() or > other.reset(createFoo().release()). > I think if you were ever writing createFoo()->func() before you were leaking memory. And actually you can now safely use the simpler syntax with std::unique_ptr: createFoo()->func() will work fine, there's no need for th...

There seems to be some uncertainty about the use of smart pointers (previously OwningPtr, now std::unique_ptr and std::shared_ptr predominantly) in the LLVM project as a whole, so here's a thread to discuss/clarify/etc the project preferences/direction with regard to smart pointer usage. For some context, see discussions in LLVM r212403 and Clang r213307. The basic question here seems to be

...w else acquire the object you > just created. That generally shouldn't be complicated unless the consumer has weird ownership semantics, in which case that's worth highlighting. >The result of using smart pointers as returns isn't pretty -- > you end up with awkward code like createFoo().get()->func() This isn't an expression you should need to write, it'd simply be "createFoo()->func()". > or> other.reset(createFoo().release()). This is also an expression you shouldn't need to write, it'd simply be "other = createFoo()". Indeed...

I''m on OS X Tiger, and just upgraded my gems. I also ran ''rake rails:update''. After that, I ran "rake freeze_gems", I recieve the following: ===================== Freezing to the gems for Rails 1.1.0 rm -rf vendor/rails mkdir -p vendor/rails cd vendor/rails Unpacked gem: ''activesupport-1.3.0'' mv activesupport-1.3.0 activesupport Unpacked