- Use `value_type` when the returned type is not a reference
- Enforce `reference = value_type` if the returned type is not
a reference (to avoid `typename PM::reference r = get(m, k)`,
which will take a ref to a temporary if the `reference`
typedef is an actualy reference)
- Do not use `put_get_helper` if the property map is not a `lvalue`
**mutable** property map: the `put()` is `map[k] = v`, which
is broken if `operator[]` does not return a reference
- The concept `boost::lvalue_property_map_tag` requires `operator[](key)`,
not a reference in `get(map, key)`. You can have a readable property map
returning a reference through its `get(map, key)`, but if there is
no `operator[]`, it's just a `boost::readable_property_map_tag`
- Some const correctness to avoid copying maps with state
or heavy keys in `get(map, key)` / `put(map, key, value)`
- Base the category of a wrapping pmap on what it offers instead
of just forwarding the base property map's category
- Tried to do something like mutable lvalue pmap:
* `value_type& operator[](key&)`
* `ref get(map, const key&)`
* `put(map, const key&, const value_type&)`
and non-mutable lvalue pmap:
* `const value_type& operator[](const key&)`
* `ref get(map, const key&)`
but not everything fits properly...
Example of such a warning:
```
.../test/Jet_fitting_3_Examples/PolyhedralSurf.h:148:19: warning: anonymous non-C-compatible type given name for linkage purposes by typedef declaration; add a tag name here [-Wnon-c-typedef-for-linkage]
typedef struct {
^
FGeomTraits
.../test/Jet_fitting_3_Examples/PolyhedralSurf.h:149:5: note: type is not C-compatible due to this member declaration
public:
^~~~~~~
.../test/Jet_fitting_3_Examples/PolyhedralSurf.h:151:7: note: type is given name FGeomTraits for linkage purposes by this typedef declaration
} FGeomTraits;
^
```
right after the merge of the 5.0 release branch
+ manual fix of the files (indentation was changed in the meantime):
* Spatial_sorting/include/CGAL/Multiscale_sort.h
* Spatial_sorting/test/Spatial_sorting/test_multiscale.cpp
right after the merge of 4.14 release branch
+ manual fix on one line in:
* Arrangement_on_surface_2/include/CGAL/IO/Arr_text_formatter.h
* .travis/generate_travis.sh
That is a followup-to my commit last year:
| ------------------------------------------------------------------------
| r63198 | lrineau | 2011-04-28 19:45:22 +0200 (Thu, 28 Apr 2011) | 5 lines
|
| Try to fix my last revision about cmake_policy, with CMake-2.6.x
|
| CMake gives an error if one tries to use cmake_policy(VERSION x.y.z) if
| x.y.z is greater than the current CMake version.
|
| ------------------------------------------------------------------------
The following check:
if("${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}" VERSION_GREATER 2.6)
is useless just after a call to:
cmake_minimum_required(VERSION 2.6.2)
The script used to fix that was:
#!/usr/bin/env perl
$replacement=<<'END';
if("${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION}" VERSION_GREATER 2.8.3)
cmake_policy(VERSION 2.8.4)
else()
cmake_policy(VERSION 2.6)
endif()
END
while(<>) {
if(/if\("\${CMAKE_MAJOR_VERSION}.\${CMAKE_MINOR_VERSION}" VERSION_GREATER 2.6\)/) {
while(<>) {
if(/^endif\(\)/) {
print "$replacement";
while(<>) {
print;
}
exit 0
}
}
}
print;
}
removed almost all occurenced (missing UseFiles). While
doing so, some CMakeLists.txt could also be simplified. In fact
many more CMakeLists.txt can be simplified, in one of two ways:
1) add external libs to CGAL_3RD_PARTY_LIBRARIES and
2) call cgal_create_single_source_program
*Add non-sparse matrix class (thus renamimg of the existing one)
*specialisation of the matrix class in Eigen_solver_traits according
whether this is a symmetric or asymmetric matrix
*update use-files of lapack and Taucs to get definitions
We declare
cmake_minimum_required(VERSION 2.6.2)
but we also use
cmake_policy(VERSION 2.8.4)
to declare that our CMake scripts are OK with all the defaults of CMake policies
as of CMake-2.8.4. That shuts down the warnings of CMake-2.8.4.
That way, we no longer need any declaration of specific policies.
Those two lines must be present and maintained in all our CMakeLists.txt
files (the one for the libraries, and also the one for examples and demos,
and maybe tests).
Sébastien Loriot
Mael Rouxel-Labbé
Maxime Gimeno
Laurent Rineau
Simon Giraudot
Andreas Fabri
Guillaume Damiand
Laurent Rineau
Eric Berberich
Sébastien Loriot