> I'd say that moving GDAL to GCC 5 and C++11 would be possible but tricky
> on RHEL.
> A developer still on RHEL 6 can do it and would be able to
> put up with the effort considering that they are using such an old system
> However a *user* on RHEL 7 has the latest and greatest system available
>
See also for googletest on travis-ci:
https://github.com/google/googletest/blob/master/.travis.yml
And there is libgtest-dev on ubuntu, but the project stopped doing point
releases a long time ago (~2005).
https://github.com/easylogging/easyloggingpp/blob/master/.travis.yml
https://amodernstory.
Agreed on the 11 v 14 issues.
On Mon, May 9, 2016 at 11:17 AM, Even Rouault
wrote:
> Le lundi 09 mai 2016 19:28:48, vous avez écrit :
> > Here is my current take on language standards
> >
> > - I am working on a C++11/14 C99/11 proposal. I despirately want to be
> > able to use C++11 to make GD
Le lundi 09 mai 2016 19:28:48, vous avez écrit :
> Here is my current take on language standards
>
> - I am working on a C++11/14 C99/11 proposal. I despirately want to be
> able to use C++11 to make GDAL more robust
C++11 is probably OK, but C++14 support is really "new". For Linux distros, we
Here is my current take on language standards
- I am working on a C++11/14 C99/11 proposal. I despirately want to be
able to use C++11 to make GDAL more robust
- As it stands I will vote >>>against<<< my proposal any time soon - until
with have a bunch of proposals for changes to GDAL that requir
On 7 May 2016 at 19:10, Kurt Schwehr wrote:
>>
>> If we move to a later C++ standard, or even use features of C++98 we
>> currently
>> don't use, I'd advocate for using things that are obviously making the
>> code
>> better / more readable. Honestly who finds that
>> "std::unique_ptr> Vals(CPLCall
07.05.2016, 20:10, Kurt Schwehr kirjoitti:
This is cart before the horse but... as fast as I can so expect
typos. Now just think of a ~1K long function or method with tons of
instances and lots of places to bailout successfully or as failures.
We have > 9K free/CPLFree/CPLdelete/CPLDestroys
On Sat, May 7, 2016 at 2:00 PM, David Strip wrote:
> On 5/7/2016 11:10 AM, Kurt Schwehr wrote:
>
> This is cart before the horse but... as fast as I can so expect typos.
> Now just think of a ~1K long function or method with tons of instances and
> lots of places to bailout successfully or as f
On 5/7/2016 11:10 AM, Kurt Schwehr
wrote:
This is why starting with zero features and working
our way up with a white list gives examples of correct usage. It
looks like a lot of GDAL development happens by copy-paste-tweak,
so good examples are key. An
This is example demonstrates that we are in-general fighting hard against
C++... up-hill both ways in a blizzard. :) This is why starting with zero
features and working our way up with a white list gives examples of correct
usage. It looks like a lot of GDAL development happens by
copy-paste-twe
Even raises an important point about adopting the latest C++
standards. This point actually applies to C++ in general as well. In
particular, C++ can be used to write some very powerful but
tremendously opaque code. This problem is amplified by the
inscrutable error messa
Le vendredi 06 mai 2016 23:07:26, Kurt Schwehr a écrit :
> There has been lively discussion on if/when GDAL moves to require compilers
> with newer C and C++ standard versions. This email is meant to fork the
> this discussion away from the local stack + memset -> std::vector
> discussion. I'm tr
There has been lively discussion on if/when GDAL moves to require compilers
with newer C and C++ standard versions. This email is meant to fork the
this discussion away from the local stack + memset -> std::vector
discussion. I'm trying to draft a proposal based on the discussion, but it
is a lot
13 matches
Mail list logo
