The latest commit for keyword.cpp and keyword.h broke the builds on the Mac. 

[1] Adding #include <map> after #include "parse.h" fixes the compiler errors 
for keyword.h, but I don't know if this needs to be guarded by #ifdef __APPLE__ 
or if it is OK (and perhaps even necessary) to include it for all platforms, so 
I have not checked it in.

[2] After making that change in keyword.h, I get these compiler errors in 
keyword.cpp:
> ..../lib/keyword.cpp:47:9: error: cannot pass object of non-POD type 
> 'std::string' (aka 'basic_string<char>') through variadic method; call will 
> abort at runtime [-Wnon-pod-varargs]
>         name, description, parent, level, category
>         ^
> ..../lib/keyword.cpp:47:15: error: cannot pass object of non-POD type 
> 'std::string' (aka 'basic_string<char>') through variadic method; call will 
> abort at runtime [-Wnon-pod-varargs]
>         name, description, parent, level, category
>               ^

According to 
<https://stackoverflow.com/questions/146452/what-are-pod-types-in-c>:
> POD stands for Plain Old Data - that is, a class (whether defined with the 
> keyword struct or the keyword class) without constructors, destructors and 
> virtual members functions. Wikipedia's article on POD goes into a bit more 
> detail and defines it as:
> 
> A Plain Old Data Structure in C++ is an aggregate class that contains only 
> PODS as members, has no user-defined destructor, no user-defined copy 
> assignment operator, and no nonstatic members of pointer-to-member type.

<https://stackoverflow.com/questions/10440966/c-cannot-pass-objects-of-non-pod-type>
 explains it this way:
> The problem you have is that variable argument functions do not work on 
> non-POD types, including std::string. That is a limiation of the system and 
> cannot be modified. What you can, on the other hand, is change your code to 
> pass a POD type (in particular a pointer to a nul terminated character array):


And 
<https://stackoverflow.com/questions/18319619/c-snprintf-cannot-pass-objects-of-non-pod-type>
 explains a similar case this way:
> snprintf knows nothing about std::string. In this case, it expects 
> null-terminated C strings, that is, pointers to char which are the beginning 
> of a sequence of characters that ends in a null character. You can obtain the 
> underlying null terminated string held by a std::string object via its 
> c_str() method:

Cheers,
--Charlie

_______________________________________________
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Reply via email to