On 10.01.22 11:22, Stephan Bergmann wrote:
On 09/01/2022 09:41, Julien Nabet wrote:
So it means we could at least use of compbase.hxx internally, then put
compbase.hxx in deprecated.
We can deprecate/discourage its internal use, but IMO should not
deprecate it for external use (where we offer
On 09/01/2022 09:41, Julien Nabet wrote:
So it means we could at least use of compbase.hxx internally, then put
compbase.hxx in deprecated.
We can deprecate/discourage its internal use, but IMO should not
deprecate it for external use (where we offer no alternative solution).
I don't think w
On 09/01/2022 18:12, Thorsten Behrens wrote:
Julien Nabet wrote:
So it means we could at least use of compbase.hxx internally, then put
compbase.hxx in deprecated.
Yep.
...
Ok now I saw for example compbase11.hxx wasn't used (or it seemed so
considering the only results of the git grep):
Julien Nabet wrote:
> So it means we could at least use of compbase.hxx internally, then put
> compbase.hxx in deprecated.
>
Yep.
Cheers,
-- Thorsten
signature.asc
Description: PGP signature
On 09/01/2022 07:27, Noel Grandin wrote:
Those are from the days before we had reliable
variable-parameters-templates.
We can't remove them because they are part of the published API.
Thank you for your feedback.
So it means we could at least use of compbase.hxx internally, then put
compb
Those are from the days before we had reliable
variable-parameters-templates.
We can't remove them because they are part of the published API.
Hello,
I noticed include/cppuhelper had files like:
compbase1.hxx
compbase2.hxx
...
compbase12.hxx
It seems the only diff is the number of parameters.
But there's also compbase.hxx which can take any number of parameters.
May we replace all the use of compabase.hxx by compbase.hxx or
is t
