if function definition is not available and only the function prototype is externed in header files, then g++ compiler wont give any errors. but during linking, g++ linker will identify the error and says "undefined reference" to corresponding fn. i don't care abt fn definition. i just want to get the binary image and whenever corresponding fn called from that image, then that time only i want to crash. may i know the linker flags to suppress this "undefined reference" linker error?. In VC++, there is a options called /FORCE. is there any similar flags?
It's completely undefined behaviour, but if you want a crash ...
If you have an undefined symbol such as a function void h() then its mangled name will be _Z1hv, so if you define a symbol that name and external linkage it will be found, even if the type is wrong:
int _Z1hv = 0;
void h();
int main()
{
h();
}
This will link, but crash at run-time because the call to h() will try to "run" a function at the address of the integer variable.
Doing this is wrong and disgusting and kills kittens.
Related
I have some simple C++ code which won't be compiled by the Clang based C++11 compiler bccaarm of C++ Builder 10.1 Berlin.
This is the code:
TComponent* Comp = new TComponent(this);
std::vector<TComponent*> Comps;
Comps.push_back(Comp);
And this is the error:
[bccaarm error] stl_iterator.h(963): rvalue reference to type
'value_type' (aka 'System: classes::TComponent * __strong') can not be
bound to lvalue of type '__borland_class * isTObj __strong' (aka
'System::Classes::TComponent * __strong')
The compiler stops at line 963 in the file stl_iterator.h:
The other C++ compilers bcc32 and bcc32c(also Clang based) have no problems with this code.
When Compis not from type TComponent or another descendant from TObject the code compiles without any problem.
I have no idea what is wrong with this code and why there is a problem with R and L values...
Does anybody know what to do here?
To get the above code compiled the vector type has to be defined as an unsafe pointer.
TComponent* Comp = new TComponent(this);
std::vector<__unsafe TComponent*> Comps;
Comps.push_back(Comp);
I openened a support case for an other problem I had. The embarcadero support gave me the following information which I applied to this problem and it seems to work:
__unsafe tells the compiler that object lifetimes will be handled and no ARC code is generated for the objects
More about this topic:
http://docwiki.embarcadero.com/RADStudio/Berlin/en/Automatic_Reference_Counting_in_C%2B%2B#weak_and_unsafe_pointers
Can I call a block from the XCode debugger? I just tried:
po zoomCurve(0)
Which has the type:
typedef CGFloat (^STAnimationCurveBlock)(CGFloat t);
And the debugger says:
error: called object type 'STAnimationCurveBlock' (aka '__block_literal_generic *') is not a function or function pointer
error: 1 errors parsing expression
As described in this answer, the debugger doesn't seem to know the type of the block. You need to cast the block to its type. In the specific case you have there:
po ((CGFloat(^)(CGFloat))zoomCurve)(0.9)
For some reason, casting to the typdef type also doesn't work, and gives the same error. Specifically, this will give the same error:
po ((STAnimationCurveBlock)zoomCurve)(0.9)
I have the following std::begin wrappers around Eigen3 matrices:
namespace std {
template<class T, int nd> auto begin(Eigen::Matrix<T,nd,1>& v)
-> decltype(v.data()) { return v.data(); }
}
Substitution fails, and I get a compiler error (error: no matching function for call to 'begin'). For this overload, clang outputs the following:
.../file:line:char note: candidate template ignored:
substitution failure [with T = double, nd = 4]
template<class T, int nd> auto begin(Eigen::Matrix<T,nd,1>& v)
^
I want this overload to be selected. I am expecting the types to be double and int, i.e. they are deduced as I want them to be deduced (and hopefully correctly). By looking at the function, I don't see anything that can actually fail.
Every now and then I get similar errors. Here, clang tells me: substitution failure, I'm not putting this function into the overload resolution set. However, this does not help me debugging at all. Why did substitution failed? What exactly couldn't be substituted where? The only thing obvious to me is that the compiler knows, but it is deliberately not telling me :(
Is it possible to force clang to tell me what did exactly fail here?
This function is trivial and I'm having problems. In more complex functions, I guess things can only get worse. How do you go about debugging these kind of errors?
You can debug substitution failures by doing the substitution yourself into a cut'n'paste of the original template and seeing what errors the compiler spews for the fully specialized code. In this case:
namespace std {
auto begin(Eigen::Matrix<double,4,1>& v)
-> decltype(v.data()) {
typedef double T; // Not necessary in this example,
const int nd = 4; // but define the parameters in general.
return v.data();
}
}
Well this has been reported as a bug in clang. Unfortunately, the clang devs still don't know the best way to fix it. Until then, you can use gcc which will report the backtrace, or you can apply this patch to clang 3.4. The patch is a quick hack that will turn substitution failures into errors.
I encounter an error in the code below.
recursive_mutex m_RecurMutex;
condition_variable cond;
unique_lock<recursive_mutex> lock(m_RecurMutex);
cond.wait(lock); // Error Here.
What is the reason causing this error?
You should use condition_variable_any instead, the semantics of this version is the same, but it allows all kinds of lock types. The regular condition_variable is however said to be potentially faster.
I assume the error is
mutex.cc: In function ‘int main()’:
mutex.cc:9: error: no matching function for call to ‘boost::condition_variable::wait(boost::unique_lock<boost::recursive_mutex>&)’
/opt/local/include/boost/thread/pthread/condition_variable.hpp:17: note: candidates are: void boost::condition_variable::wait(boost::unique_lock<boost::mutex>&)
i
if not, please correct me. The documentation shows boost::condition_variable::lock takes a boost::unique_lock<boost::mutex> as an argument, not a boost::unique_lock<boost::recursive_mutex> as in your example.
I am debugging a Cocoa application using xcode-gdb. I am at a break point and I want view the value of some Cocoa constants (ie NSControlKeyMask) and to do some test with the values in the current stackframe. Specifically I am in - (void) keyDown:(NSEvent *) e , and I have done set $mf = (int)[e modifierFlags] on the gdb prompt. Now I want to do p $mf & NSControlKeyMask and gdb is telling me 'No symbol "NSControlKeyMask" in current context.'
UPDATE:
Xcode has the "Fix and Continue text" feature. So I used Dan M. and n8gray solution with this feature so I don't have to make a proxy of every constant.
If no variables are actually instantiated with a given type, then the debug information for the corresponding symbols doesn't wind up getting generated by gcc. Then, if you ask gdb about such a type, it doesn't know what you are talking about because there is no debug information for that type, and it will give you the "No symbol in current context" error.
A workaround to this problem would normally be to explicitly add a dummy variable, of the type in question, somewhere in the code. Here is a simple example that you can test to see what I'm talking about:
enum an_enum_type {
foo,
bar,
baz
};
int main (int argc, char *argv [])
{
return baz;
}
Save that program to a file named test.cpp and compile it with this command:
g++ -o test -g -O0 test.cpp
Then run it under gdb and type "p /x baz". You will get the "No symbol baz in current context" error.
Now try it with this modified version that has added a dummy variable, of the enum type:
enum an_enum_type {
foo,
bar,
baz
};
an_enum_type dummy;
int main (int argc, char *argv [])
{
return baz;
}
Compile with the same command as before and run under gdb. This time when you type "p /x baz" you'll get "0x2" as the answer, which I think is what you are shooting for in your question.
I've looked into it, and the problem is that the NSEvent.h header file doesn't give a name to the enum that contains NSControlKeyMask -- it's an anonymous enum. So there is no way to create a variable of that type (dummy or otherwise). So, I don't see any way of getting the compiler to generate the debug information for that type. I think you're just going to have to rely on the definition of NSControlKeyMask from the header file.
If you compile with gcc you can use the -g3 switch to get the highest level of debug info. Quoting from the section on -g in the gcc manual:
-glevel
Request debugging information and also use level to specify how much information. The default level is 2.
Level 0 produces no debug information at all. Thus, -g0 negates -g.
Level 1 produces minimal information, enough for making backtraces in parts
of the program that you don't plan to debug. This includes descriptions
of functions and external variables, but no information about local
variables and no line numbers.
Level 3 includes extra information, such as all the macro definitions present
in the program. Some debuggers support macro expansion when you use
-g3.
So if you compile with -g3 you should be able to expand constants and macros in gdb.
As Dan M. discovered, you probably can't get this to work in a straightforward way. Instead, what you could do is put something like this in one of your files:
int myNSControlKeyMask = NSControlKeyMask;
int myNSOptionKeyMask = NSOptionKeyMask;
...
Then at least you can use symbolic names in gdb without having to look up the corresponding values in the .h file.
NSControlKeyMask is most likely a macro and invisible to the debugger. You need to look in the appropriate .h file. Place the cursor over the text NSControlKeyMask in the editor and try command+double-click to jump to its definition.
I seem to be getting the same problem in a bunch of C++ code that is being called from Obj-C in an iPhone app. It's giving me the
No symbol "a" in current context.
error, where a is an int. I tried the -g3 compiler flag with no success. I find it hard to believe gdb doesn't know the type of an int. SDK 3.0, but then again, gdb was printing completely erroneous values when it could find variable in the program.