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.
