freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] [GSoC] ftinspect


From: Philipp Kerling
Subject: Re: [ft-devel] [GSoC] ftinspect
Date: Sun, 07 May 2017 09:47:12 +0200

2017-05-06 (土) の 19:47 +0200 に Werner LEMBERG さんは書きました:
> > The commits were made starting at 1dd90ae. I can rebase if needed.
> 
> Please do so!
OK, I'll send it to the list again once I get around to do it.

> Some remarks.
> 
> . Is C++11 really necessary?  Or to ask differently, are the new
>   features that come with C++11 (`auto', `override', etc.) of real
>   importance?
> 
>   In general, I like a conservative approach so that C++ code can be
>   compiled even on older boxes.  Admittedly, I'm not a big fan of C++
>   (and not a big C++ coder either), but given that FreeType itself is
>   written in quite conservative code, `qtinspect' should probably use
>   a similar path.
Personally, I think that C++11 is a huge step forward for the language
(C++14 and C++17 are arguably less revolutionary) and support for
compilation on older boxes is pretty much the only valid reason not to
use it. I reckon that 'auto' and 'override' are not significant enough
to justify C++11. There are other features that the code does not use
(yet) - e.g. lambda expressions [1] and range-based for [2] - that are
probably of more practical importance for ftinspect, but honestly
speaking you can of course code just fine without them. 
That said, the reason I used them at all was that I assumed that since
you decided to use Qt5, a "modern" UI framework, and since ftinspect is
mostly a developer tool, introducing C++11 would not be an issue. And
if you do enable it, using auto and override obviously also becomes a
non-issue.

I think that it's best if you guys decide what the requirements for
ftinspect should be, both in compiler and Qt features. To give you some
input, C++11 is fully supported by gcc since gcc-4.8.1, released in May
2013 (and a bit longer even by clang I believe). Without it, you would
also be limited to Qt-5.6 since Qt-5.7 and later require a C++11-
capable compiler anyway [3]. The decision also depends on just how old
a box we are talking about :)

> . In patch 10 you are using the `auto' keyword.  My gut feeling says
>   that `auto' is fine for templates and the like but otherwise normal
>   types are preferable, especially if there is an explicit
>   `static_cast' (additionally, it's a C++11 feature, but this item is
>   unrelated).  What do you think?
For the combination of auto and a cast I see it as DRY feature. The
type is/should be completely determined by the cast expression anyway,
so the variable type specification does not add any information (i.e.
it is redundant) both for the compiler and the human reader. There's
also an auto in patch 14, which I used for inheriting the type (even if
it should change later). It clearly is a matter of taste though and I
wouldn't insist on using it.


Best regards
Philipp


[1] 
https://en.wikipedia.org/wiki/Anonymous_function#C.2B.2B_.28since_C.2B.2B11.29
[2] https://en.wikipedia.org/wiki/C%2B%2B11#Range-based_for_loop
[3] https://wiki.qt.io/New_Features_in_Qt_5.7



reply via email to

[Prev in Thread] Current Thread [Next in Thread]