+1 for typing out the first definition.
In functions, I'd be in favor of using 'auto' and 'decltype' when
declaring local variables that need to match the class variable.
Best-
Seth
On 2019-08-08 02:43, Jeff Young wrote:
When I worked at Frame a colleague advised me not to create Framegol.
Tom,
On 8/7/19 6:18 PM, Tomasz Wlostowski wrote:
> Hi Fellow Devs,
>
> I'm fixing some memory management issues in the P by introducing smart
> pointers here and there. Do we have any coding policy on typedefing
> shared_ptrs/unique_ptrs?
>
> Should I:
> - always use std::shared_ptr explicitly?
Hi Tom,
> - always use std::shared_ptr explicitly?
I'd vote for explicit smart pointers in function signatures and member
definitions, and "auto" in places where it can be deduced.
MSVC's /ANALYZE also has some helpful diagnostics like C26418[1] "Shared
pointer parameter X is not copied or
When I worked at Frame a colleague advised me not to create Framegol. (That
was back in the day when Pascal and C were considered Algol family languages.)
I’ve always taken that to heart and so prefer std::shared_ptr, ugly as it
is.
Cheers,
Jeff.
> On 7 Aug 2019, at 23:18, Tomasz Wlostowski
Hi Fellow Devs,
I'm fixing some memory management issues in the P by introducing smart
pointers here and there. Do we have any coding policy on typedefing
shared_ptrs/unique_ptrs?
Should I:
- always use std::shared_ptr explicitly?
- or am I allowed to typedef std::shared_ptr TYPE_SP (or
5 matches
Mail list logo
