Languages for servers (Go, D, and more)

[Sean Kelly via Digitalmars-d]

On Tuesday, 8 July 2014 at 15:23:30 UTC, Atila Neves wrote:
> On Tuesday, 8 July 2014 at 14:24:10 UTC, Sean Kelly wrote:
>> On Tuesday, 8 July 2014 at 02:31:50 UTC, Átila Neves wrote:
>>> On Monday, 7 July 2014 at 18:15:32 UTC, Sean Kelly wrote:
>>>>
>>>> With asynchronous event-driven code (ie. server code), I 
>>>> don't
>>>> see any way to avoid all use of new / delete.
>>>
>>> std::make_unique and std::make_shared are what you're 
>>> "supposed" to use. The new and delete operators are (usually) 
>>> for library writers.
>>> Even before C++11, using delete was frowned upon but 
>>> necessary with containers of pointers due to std::auto_ptr 
>>> not helping. Well, that and the lack of move semantics.
>>
>> But you're ultimately passing something as a void* to a 
>> library call and receiving it later as the context for a 
>> callback.  That value has to live on the heap.
>
> The point isn't that nothing lives on the heap in modern C++. 
> It's that whatever does is wrapped in a class that manages the 
> lifetime of the allocated memory for you.

Well sure, but you can't use a class instance living on the stack
as the context for a callback.  At that point, whatever smart
pointer you're using has to be discarded.  This is actually why I
find little use for std::shared_ptr--it has unique() and get()
but no release() (which makes me wonder why they even bothered to
offer unique()).  It's kind of sad that the intended goal of not
using raw pointers is actually forcing me to use raw pointers.
In practice, I either use auto_ptr (now unique_ptr) for exception
safety and release when passing to a function with a callback (in
keeping with modern C++ idioms), or in containers and such I use
my own shared_ptr that provides a release() function which fails
if unique() is false.