Summary:
I have a code snippet that compiles fine with g++ but not with clang.
Details:
I have a project that compiles fine with g++ but when compiling with clang I get an error about error: use of non-static data member. I tried to create a small test case that would demonstrate the problem, but for the small test case g++ gave the same error as clang.
I've posted a 236 line file to pastebin that demonstrates the problem:
http://pastebin.com/DGnfxmYe
When compiled with g++ 4.6.3 this works fine. But when compiled with clang 3.2 I get the following error messages:
myhashmap.hpp:169:29: error: use of non-static data member 'num_bins' of 'MyHashMap' from nested type 'iterator'
for (_index++; (_index < num_bins) && (bins[_index] == NULL); _index++)
^~~~~~~~
myhashmap.hpp:169:43: error: use of non-static data member 'bins' of 'MyHashMap' from nested type 'iterator'
for (_index++; (_index < num_bins) && (bins[_index] == NULL); _index++)
^~~~
myhashmap.hpp:171:17: error: use of non-static data member 'num_bins' of 'MyHashMap' from nested type 'iterator'
if (_index < num_bins) {
^~~~~~~~
myhashmap.hpp:172:17: error: use of non-static data member 'bins' of 'MyHashMap' from nested type 'iterator'
_theNode = bins[_index];
^~~~
Looking at the code, it makes sense to me why clang is giving these error messages. What I don't understand is why g++ compiled the code correctly in the first place. I did not write this code but I would like to get it to compile cleanly with clang. So I'm trying to understand exactly what it is doing. And I would be interested in understanding why it compiles with g++ but not with clang. Does g++ interpret the c++ standard differently, or is there some g++ extension that the code is taking advantage of?
It fails with GCC 4.8 (prerelease) so I assume it's a bug that's been fixed. I can't find a corresponding bug report though.
To fix the code I think you'll need add an int _num_bins member to the iterator and pass the cotnainer's num_bins to the iterator constructor in begin() and end(), so it's stored in each iterator object.
(Additionally, don't write (void) for a function taking no arguments, that's an abomination. In C++ a function taking no arguments is written ())
Related
I'm following Kate Gregory's C++ course on Pluralsight and understand that C++17 introduced a feature for compilers to deduce the type in a template, however the code below returns the error: missing template arguments before 'numbers'
#include <vector>
using std::vector;
int main()
{
vector numbers{ 0, 1, 2 };
return 0;
}
I'm using the MinGW gcc compiler (version 6.3.0) and using "g++ -std=c++1z *.cpp" in the command prompt, so I'm not sure what I'm doing wrong.
I know I can fix it by declaring the type but I wanted to check in case I miss out on other C++17 features through some basic error I'm making.
Your code is OK (but I suggest not to use using std::vector).
The problem is your compiler, g++ 6.3.0, that is too old to support the feature you're trying to use: class template argument deduction and deduction guides.
You need g++ 7 or newer.
I'm having an issue linking my shared library against an OpenDDS (v3.9) static library because I am unable to find where this method signature is located.
Here's the error.
[exec] libs/mylib/ABTypeSupportImpl.cpp:74: error: undefined reference to 'OpenDDS::DCPS::operator<<(OpenDDS::DCPS::Serializer&, short)'
[exec] collect2: error: ld returned 1 exit status
[exec] make: *** [/tmp/mybuild/lib_ab/obj/local/armeabi-v7a/lib_ab.so] Error 1
ABTypeSupportImpl.cpp is auto generated from compiling the IDL. More of the same errors follow. Because of the namespace (OpenDDS::DCPS), I would think this would be found within the library libOpenDDS_Dcps.a, but using nm on this lib and then grep'ing for "operator" or "<<", produces no results. Could it be that name mangling is a bit stranger for overloaded operators? I ran this on every library file within $DDS_ROOT/lib, but found nothing.
And if I recompile the IDL and remove member fields of structs with datatypes such as short or long, then there are no errors and everything links fine.
Anyone know what library this method signature might be located?
These operators are declared in 'dds/DCPS/Serializer.h' but implemented inline in Serializer.inl. Probably you compile OpenDDS with inlining enabled (its default) but when you compile your application you compile with inlining disabled.
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 need to recover method names dynamically, via reflection calls at runtime. But get strange results for some.
My TestClass contains a method like:
- (void)testMethod6_NSRect:(NSRect)a1 int:(int)a2 int:(int)a3 bool:(Boolean)a4 {
...
}
When enumerating the above classes methods using class_copyMethodList() and fetching the method selectors via method_getName(), I get:
"testMethod6_NSRect:int:int:_Bool:"
Thus, the selector was rewritten somehow (by gcc?) to make "_Bool" from "bool". As far as I tested yet, this seems to be done only for a "bool" selector-part - if I change it to int:(int), as in:
- (void)testMethod1_int:(int)a1 int:(int)a2 int:(int)a3 int:(int)a4 {
...
}
I get the expected:
"testMethod1_int:int:int:int:"
Q:
Does anyone know the rules or a pointer to where I could find them for this "selector rewriting", or am I missing something? Is this only done for "bool"?
I also need to know if this behavior is depending on the gcc-version, osx-version or runtime library version.
I am using (gcc --version):
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
on a (uname -a)
10.8.0 Darwin Kernel Version 10.8.0:
The problem lies in an ugly piece of preprocessor magic in the C99 standard header <stdbool.h>:
#define bool _Bool
C99 defines a type named _Bool which behaves like C++'s bool type. The define is there to be able to use it in C but with the C++ identifier.
Solution:
#undef bool
Try using BOOL instead of Boolean
i have a module 'gvars' defined for my global variable declarations. when i define
integer :: nthreads, max_threads, tid, omp_get_max_threads, omp_get_num_threads, omp_get_thread_num inside of my gvars module, the call maxthreads = omp_get_max_threads() in my main routine gives me the following error upon compilation:
maxthreads = omp_get_max_threads()
1
Error: Unclassifiable statement at (1)
but when i include the integer :: definitions above inside my main routine, it compiles just fine and gives me the desired results. if i even go as far as to define nthreads = -1 inside my gvars module, i am able to print out the correct value in my main routine so i know it is being included and defined correctly, it's just that for some reason i cannot have it as a return value from openmp functions.
why would this be?
is there any other way to keep these values as global variables and still define them in my main routine instead of a module?
if it matters, i am using gfortran to compile
The problem is not with the declaration of maxthreads, but with the declaration, on the same line, of omp_get_max_threads. As haraldkl showed, you need to use omp_lib instead, to automatically get access to the declarations of these functions.
(If for some reason you really don't want to do it that way, you can also add the statement external :: omp_get_max_threads, ... to the module.)
Not really an answer, but I do not know how else to put the code in here. Sorry...
module gvars
integer :: maxthreads
end module gvars
program test
use gvars
use omp_lib
implicit none
maxthreads = omp_get_max_threads()
end program test
compiled with:
gfortran -fopenmp test.f90
Where gfotran -v gives:
gcc version 4.4.5 (GCC)