Moving KDots to KDE Review

[Minh Ngo]

Hi,

> Q1. Is it really necessary to use the std library directly in KDots?
It was just a historical reason. I tried to write a core part independently
from Qt and KDE at the beginning. And
in addition some contrainers and structures in Qt4 didn't support C++11
properly.

> Q2. Why does not KDots use Qt classes for points, hashes, containers,
etc? Using Qt is the usual way to make
> KDE Games portable.
If all things that I use in the code is in the standard too, then
theoretically it also should be portable :)

>Q3. Is there any C++11 source code in KDots?
Yes, auto, lambdas, initialization_list, std::shared_ptr, std::unique_ptr
etc. - they are in the new standard.

> Q4. Is KDE Community code beginning to use C++11 and versions of std lib
that
> have C++11 as a dependency?  What is the KDE Policy on this?
As I understand Qt5 has already supported C++11, why don't we use these
features then? :)

Kind Regards,
Minh

Minh

On 10 April 2015 at 09:47, Ian Wadham <iandw.au at gmail.com> wrote:

> Hi Minh,
>
> On 09/04/2015, at 9:11 PM, Minh Ngo wrote:
> > Possibly it's because of the different stdlib (clang in Linux requires
> gcc, but on Mac maybe it uses other stdlib
> > implementation), but I'm not sure about Mac. Is it possible to treat
> these errors as warnings?
> >
> > In the point.hpp the thing I did is just implemented a class Point that
> consists from two coordinates and a hash function to store it in
> std::unordered_*. Therefore please be free to change and don't fear about
> breaking logic :).
>
> I suspect now that I am not getting a C++11 version of std lib in my build,
> as is required for templated hash and std::unordered_set.  At least, when
> I do make -k, to go past the errors regarding std::hash, at some point I
> get:
>
> In file included from
> /kdedev/kde4m/kdesrc/kde/kdegames/kdots/polygonfinder.cpp:26:
> /kdedev/kde4m/kdesrc/kde/kdegames/kdots/polygonfinder.hpp:29:10: fatal
> error:
>       'unordered_set' file not found
> #include <unordered_set>
>
> Something like this came up on the MacPorts Developers' list about 3 weeks
> ago.  It appears that there is no uniform way to configure a C++11 compiler
> and corresponding std lib across the various Apple OS X platforms supported
> by MacPorts (e.g. 4.6 through to 4.10, spanning about 7 years of OS X
> releases).
> The discussion was mostly way over my head, re Apple and MacPorts
> technology,
> so I hope I did not misunderstand the main issue.
>
> Before I dive in at the deep end on the Mac lists and perhaps give rise to
> another long
> thread, may I ask some questions about KDots' coding and KDE Policy re
> C++11?.
>
> Q1. Is it really necessary to use the std library directly in KDots?
>
> Q2. Why does not KDots use Qt classes for points, hashes, containers, etc?
>        Using Qt is the usual way to make KDE Games portable.
>
> Q3. Is there any C++11 source code in KDots?
>
> And for KF5 developers in general:
>
> Q4. Is KDE Community code beginning to use C++11 and versions of std lib
> that
>        have C++11 as a dependency?  What is the KDE Policy on this?
>
> Cheers, Ian W.
>
> > On 9 April 2015 at 12:25, Ian Wadham <iandw.au at gmail.com> wrote:
> > Possibly the Clang compiler is picking up the wrong stdlib from
> somewhere or
> > maybe Clang does not like the mix of namespace and template features in
> this
> > particular code.  Can it be paraphrased and simplified in some way?
> >
> > It is similar to the final coding example in
> http://en.cppreference.com/w/cpp/utility/hash,
> > so it ought to compile OK, but it is not exactly the same.  I might try
> modifying point.hpp
> > to be textually and syntactically more like the example, without
> changing semantics.
> >
> > Another possibility is for me to try MacPorts' (Open Source) Clang,
> rather than Apple's,
> > but I use Apple's Clang successfully for all other code.  Or I might be
> able to revert to
> > MacPorts' gcc.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150410/6bd6bed1/attachment.htm>