Re: [lmi] Reference lifetime extension

[Greg Chicares]

On 10/11/18 11:58 PM, Vadim Zeitlin wrote:
> On Thu, 11 Oct 2018 23:29:12 +0000 Greg Chicares <address@hidden> wrote:
[...]
>  Also, there is a fact that the latest master doesn't work at all for me
> when building with MSVS, but this is only an easy to fix typo, could you
> please apply this patch to correct it?
[...]
> diff --git a/main_wx.cpp b/main_wx.cpp
[...]
>  LMI_FORCE_LINKING_EX_SITU(group_quote_pdf_generator_wx)
> -LMI_FORCE_LINKING_IN_SITU(pdf_command_wx)
> +LMI_FORCE_LINKING_EX_SITU(pdf_command_wx)
>  LMI_FORCE_LINKING_EX_SITU(progress_meter_wx)

Certainly. I'll also remove the similar defect in 'main_wx_test.cpp'.
Those changes are already committed, but I don't want to run the
entire battery of (more-frequent-than) nychthemeral tests tonight,
so I'll push them tomorrow.

Do you see any easy way to cause such defects to produce an error
with gcc, so that they'll be self-identifying in future?

>  I realize that chances of reverting this change are slim, but I really
> think it's a huge overreaction to the initial problem.

The actual motivation is that I couldn't easily understand what
create() did, or why we needed an object at all, or why a simple
static singleton wouldn't have sufficed: a whole series of
questions that led to my desire for drastic simplification.

> Getting rid of
> shared_ptr<> is a good thing (and I admit that I have absolutely no idea
> why had I used it here in the first place),

I suppose you copied the progress_meter callback mechanism for
group quotes, and then transitively for PDF illustrations.

> but I would have preferred just
> replacing it with unique_ptr<> instead of completely removing
> ledger_pdf_generator class.

Would unique_ptr<> work for progress_meter, and, similarly,
the "group_quote_pdf_gen" classes? Class progress_meter is so
old that perhaps the only smart pointers available at the time
were boost::shared_ptr and std::auto_ptr.

I'd much rather use no smart pointers at all, because pointers
can be null and it's tiresome to check that they aren't. Is it
even possible to write "smart reference" classes that can't
ever contain a null value?