I am trying to use the 2d meshing library for a code. I copied the syntax and the include files from the following example on the documentation
mesh_global.cpp
But when I add the following line
CGAL::refine_Delaunay_mesh_2(cdt, Criteria(0.015625, sq3*a));
I get a compilation error pointing to the line
#include <CGAL/Delaunay_mesher_2.h>
The thing is the code compiles well without calling the meshing function.
The complete error is to big to post here but I found this line in between
/home/sameer/cgal/gap cvt/gap_cvt.cpp:1505:62: required from here
/usr/include/CGAL/Delaunay_mesher_2.h:166:11: error: ‘class CGAL::Constrained_triangulation_face_base_2<CGAL::Epick, CGAL::Triangulation_face_base_2<CGAL::Epick, CGAL::Triangulation_ds_face_base_2<CGAL::Triangulation_data_structure_2<CGAL::Triangulation_vertex_base_2<CGAL::Epick, CGAL::Triangulation_ds_vertex_base_2<void> >, CGAL::Constrained_triangulation_face_base_2<CGAL::Epick, CGAL::Triangulation_face_base_2<CGAL::Epick, CGAL::Triangulation_ds_face_base_2<void> > > > > > >’ has no member named ‘set_in_domain’
it->set_in_domain(!mark);
I don't see what I am missing apart from the parameters the code has been taken almost as it is from the example.
The 2D mesher class Delaunay_mesher_2 expect the CDT template parameter to have a face type model of DelaunayMeshFaceBase_2. You cannot use the default Triangulation data structure.
In the example you point out, the CDT type is declared as follow:
typedef CGAL::Exact_predicates_inexact_constructions_kernel K;
typedef CGAL::Triangulation_vertex_base_2<K> Vb;
typedef CGAL::Delaunay_mesh_face_base_2<K> Fb;
typedef CGAL::Triangulation_data_structure_2<Vb, Fb> Tds;
typedef CGAL::Constrained_Delaunay_triangulation_2<K, Tds> CDT;
Related
I have updated a project using CGAL 4.13 to CGAL 5.5. It uses the kernel:
typedef CGAL::Exact_predicates_exact_constructions_kernel K;
typedef K::FT dbl;
and some functions do not compile now anymore. For example the one below:
inline void decouple(const dbl& val,dbl& decoupled)
{
...
decoupled=CGAL::Gmpq(val.exact().mpq());
}
../geometricTools.h:476:50: error: 'const ET' {aka 'const class
boost::multiprecision::numberboost::multiprecision::backends::gmp_rational'}
has no member named 'mpq' 476 |
decoupled=CGAL::Gmpq(val.exact().mpq());
A second problem is a line wher e a string ("123/456") is converted to a number:
dbl AlgorithmHdf5::getDbl(int n, int d)
{
...
dbl ret(m_vDbl[ind]); // argument is a std::string
return ret;
}
AlgorithmHdf5.cpp:71:36: error: no matching function for call to
'CGAL::Lazy_exact_ntboost::multiprecision::number<boost::multiprecision::backends::gmp_rational
::Lazy_exact_nt(__gnu_cxx::__alloc_traitsstd::allocator<std::__cxx11::basic_string<char
, std::__cxx11::basic_string >::value_type&)' 71 | dbl ret(m_vDbl[ind]);
these lines used to work with CGAL 4.13 but do not with CGAL 5.5. I'd appreciate any help on this. Compiler: g++ (Ubuntu 11.2.0-19ubuntu1) 11.2.0
Epeck::FT is a wrapper around some rational type that depends on what is available. If you have GMPXX or LEDA, it may use that. In your case you have GMP and a recent enough Boost, so it uses Boost.Multiprecision. If you disable that with -DCGAL_DO_NOT_USE_BOOST_MP, you may get back to the Gmpq your old code was apparently expecting.
Boost.Multiprecision does not use reference counting, so decoupled=val.exact() should be sufficient for that type. To construct from std::string, it may help to first construct a FT::Exact_type (or CGAL::Exact_rational) and then convert that to FT. You may want to file an issue on github about this direct construction from a string, it looks like something that CGAL could support.
I am getting the following compiler error with a class I am trying to compile with is almost identical to another class that compiles fine.
Here is the compiler error:
spell.cpp: In function ‘std::ostream& muddify::character::operator<<(std::ostream&, const muddify::character::spell&)’:
spell.cpp:11:9: error: no match for ‘operator<<’ (operand types are ‘std::ostream {aka std::basic_ostream}’ and ‘const id_t {aka const unsigned int}’)
out <
This seems strange to me as id_t is just a typedef of unsigned int and also I have other operator overloads that are compiling fine with pretty much the same syntax. I am compiling this code under g++ version 4.9.2 on fedora 21 using the c++11 standard.
Below is my function:
std::ostream& muddify::character::operator<<(std::ostream & out,
const muddify::character::spell& s)
{
out <<s.id << "," << s.name << "," << s.desc
<< attribute_strings[unsigned(s.attribute)];
return out;
}
I am experimenting with this project with using fully qualified namespaces for improved project management so I suspect that would be part of the issue.
If you need further code or explanations I am happy to provide that.
Thanks
Paul
The namespace experiments you mentioned sound like the issue.
The error message is complaining of a missing operator in the 'muddify' namespace, not 'std'. In other words, you need to define that operator (or somehow point it at the one in namespace std).
I'm working on integrating objective-git into my project, but when I include their headers in my sources, I get these errors on several of their enum declarations:
objective-git/Classes/GTRepository.h:57:16: Non-integral type 'git_reset_t' is an invalid underlying type
Here's the code in question:
typedef enum : git_reset_t {
GTRepositoryResetTypeSoft = GIT_RESET_SOFT,
GTRepositoryResetTypeMixed = GIT_RESET_MIXED,
GTRepositoryResetTypeHard = GIT_RESET_HARD
} GTRepositoryResetType;
I changed git_reset_t to NSUInteger (typedef'd to unsigned long), and that got it to compile, but of course I'd rather not have to change the library files.
Objective-git compiles just fine in its own project, and I can't find any significant difference in the compiler settings between that project and mine. What could I be missing?
This is with Xcode 4.5, compiling with Apple llvm 4.1.
Update: The clue I missed was that the error only happened on a .mm file, and .m files were fine, so somehow the underlying enum type doesn't work in C++ (even if I enable C++11). As a workaround I put a fake minimal #interface declaration for the one objective-git class I use in that file so I don't have to include the headers, but I'd still like to find a cleaner solution.
Google turns up this file containing this:
typedef enum {
GIT_RESET_SOFT = 1, /** Move the head to the given commit */
GIT_RESET_MIXED = 2, /** SOFT plus reset index to the commit */
GIT_RESET_HARD = 3, /** MIXED plus changes in working tree discarded */
} git_reset_t;
This is an old-style enumeration with int being the underlying type. But it's not an int, it's a distinct type. And it's not integral and it can't be an underlying type for a new-style enumeration.
The fix is to use typedef enum : int or if you can use C++ and want to be extra expository,
typedef enum : std::underlying_type< git_reset_t >::type
I haven't tried, but you could also try this in ObjC without C++:
typedef enum : __underlying_type( git_reset_t )
Hi all I have an enum type that holds my error codes.
The problem is that they are not sequential i.e.
enum{
ErrorCode1 = 1,
ErrorCode2 = 4,
ErrorCode3 = 74
}; typedef NSInteger MyErroCodes;
Also there are maybe 50 codes + so I really wouldn't want to have to duplicate the data or do it manually, which is what I've seen so far in my searches. Any help would be greatly appreciated.
The enum construct only exists at compile time. At run time, your MyErrorCodes instances are plain integers, and the ErrorCodeN values are just plain integer constants. There is no way to extract metadata from your enum in runtime (well, maybe there is in the debug info etc, but you don't want to go there...).
I suggest:
Create a small script (Python, Perl or whatnot) to generate functions that map the numeric code to string values. In XCode, you can even run code generators during the compilation phase if you really want.
Use metaprogramming or preprocessor macros to generate these functions during compilation. This requires some thought, but it can be done.
this is often accomplished using an include of a file which contains all the values within some body and sometimes using macros:
ErrorCode_enum.h
MON_ENUM_VALUE(ErrorCode1, 1)
MON_ENUM_VALUE(ErrorCode2, 4)
MON_ENUM_VALUE(ErrorCode3, 74)
where MON_ENUM_VALUE would be a variable macro expansion.
and your enum declaration might take this form:
enum {
#include "mon_enum_value_begin.h" // defines MON_ENUM_VALUE and such
#include "ErrorCode_enum.h"
#include "mon_enum_value_end.h" // undefines MON_ENUM_VALUE and everything else defined in mon_enum_value_begin.h
};
typedef NSInteger MyErroCodes;
then later you might write:
#include "mon_enum_NSNumber_begin.h" // defines MON_ENUM_VALUE and such
#include "ErrorCode_enum.h"
#include "mon_enum_NSNumber_end.h" // undefines MON_ENUM_VALUE and…
or
#include "mon_enum_NSError_begin.h" // defines MON_ENUM_VALUE and such
#include "ErrorCode_enum.h"
#include "mon_enum_NSError_end.h" // undefines MON_ENUM_VALUE and…
which may add or stringize those tags and values to other types.
Personally, I think the macros are gross, and just take alternate approaches (which, admittedly, may be more tedious to write).
The following simple program can't be compiled with gcc 4.4.3
#include "rapidxml.hpp"
#include "rapidxml_utils.hpp"
#include "rapidxml_print.hpp"
#include "rapidxml_iterators.hpp"
int main()
{
return 0;
}
Compile produces following errors:
rapidxml_iterators.hpp:21: error: expected nested-name-specifier
rapidxml_iterators.hpp:21: error: invalid declarator before ‘value_type’
rapidxml_iterators.hpp:22: error: expected nested-name-specifier
rapidxml_iterators.hpp:22: error: invalid declarator before ‘&’ token
..........
What I am doing wrong?
These errors are caused by the rapidxml_iterators.hpp header. It seems including this header is not necessary for regular xml parsing. Apparently, the iterators defined in there are not really usable anyway. It might be something still under development. See also here.
The rapidxml_iterators.hpp have some problem with it. You have to change it to this:
typedef xml_node<Ch> value_type;
typedef xml_node<Ch> &reference;
typedef xml_node<Ch> *pointer;
typedef typename std::ptrdiff_t difference_type;
typedef typename std::bidirectional_iterator_tag iterator_category;
Simple solution for simple case
You don't actually need rapidxml_iterators.hpp but were doing a sanity check, right ?
Solution: only #include the headers you actually need.
It's a general rule. #include'ing everything is like eating too much : it turns the situation fat and slow.
By contrast, including only what you need:
keeps you aware of your actual code dependency,
helps keeping you safe from namespace pollution and the occasional name clashes and sometimes even portability issues,
alerts you when you are starting to mess together things that should be kept separated.
If you really need rapidxml_iterators.hpp
At this point, the problem is probably solved. If you really need rapidxml_iterators.hpp, it's indeed buggy (looks like this particular error is a Microsoftism). This problem and others were reported on February 2010 on http://sourceforge.net/p/rapidxml/bugs/10/ with suggested solutions different from #user437634's, still open and present in current release as of July 2013.