Re: [ft-devel] [GSoC] ftinspect

[Werner LEMBERG]

>> 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.

At least for the time being I would like to be still able to compile
ftinspect with Qt4 also.  As soon as this is no longer feasible (for
whatever reasons), C++11 will become the default.

>> 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.

OK, then please don't use `auto' yet.  If we are going to use it, I
guess there are much more places where it makes sense, and it should
be straightforward to convert all such places with a separate commit.


    Werner