Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index



On Mon, 2011-11-28 at 11:42 +0100, Stephan Bergmann wrote:
On 11/28/2011 11:25 AM, Michael Meeks wrote:
    On the other hand; I'd (personally) prefer to use some defines to
create the 'override' and 'final' keywords (as they will be in future).
Defining them to 'virtual' or even empty would do, if they are not
present in the compiler. cf. glib's provision of a stock 'inline'.
...
One nitpick:  While it would keep the code surely more readable, it 
would make it less standard.  For one, override and final are 
technically not keywords in C++11, so a correct program that used them 
as identifiers would be broken if we defined them to be empty (for a 
compiler not yet supporting them).

        Sure - but I suspect the instance count of that is really low in our
nFinal aOverride world; a quick:

git grep final | grep \.[ch]xx
git grep override | grep \.[ch]xx

        Shows almost no problems here. 

  For another, if override and final /were/ keywords, defining them in
any way would result in undefined behaviour.

        Sure - which is why we'd do that for old compiler versions only; that
is what glib does for 'inline' - quite successfully. The main downside
to this might be the odd error messages when someone does:

        bool final = false;

        ;-) but - apparently people don't do that. Either way, I know which I
prefer:

        final    bool methodFoo();
        virtual  char methodBaz();
        override int  methodBaa();
vs.
        SAL_FINAL    bool methodFoo()
        virtual      char methodBaz();
        SAL_OVERRIDE int  methodBaa()

        But, since there is (as yet) no patch, it's hardly worth discussing.

        ;-)

                Michael.

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.