kicad-developers team mailing list archive

[Ian McInerney <Ian.S.McInerney@xxxxxxxx>]

Smart pointers would definitely have been nicer to use, but the issue we
have with the board objects is they are passed out through SWIG to Python
currently, and SWIG doesn't seem to support unique_ptr, so I am not sure
how it would react if we gave it a deque of unique_ptrs. Anyone know if
that would break anything?

-Ian

On Tue, Aug 13, 2019 at 5:20 PM Simon Richter <Simon.Richter@xxxxxxxxxx>
wrote:

> Hi,
>
> On Tue, Aug 13, 2019 at 10:50:10AM -0400, Wayne Stambaugh wrote:
>
> > Maybe we should have used boost::ptr_deque instead.  You get heap
> > allocation cleanup for free.
>
> Or a deque of smart pointers. Without range-based for, that was annoying to
> use because you needed the double dereference
>
>     for(std::deque<std::auto_ptr<OBJECT> >::const_iterator i =
> objects.begin;
>             i != object.end(); ++i)
>         (*i)->function();
>
> which was the main reason boost::ptr_container exists. Today, we can just
>
>     for(auto const &p : objects)
>         p->function();
>
> which is not perfect, but probably good enough.
>
> I'm not entirely convinced we need lists of polymorphic objects that much.
> The construct where VIA is a subclass of TRACK (which is also used
> directly) could possibly be changed into abstract TRACK as a base, TRACE
> and VIA as (final) most derived classes, and objects stored in deque<TRACE>
> and deque<VIA> without fear of slicing. That should cut down on the number
> of allocations required, and also allow introducing a pool allocator into
> the deque type as a further optimization.
>
>    Simon
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>