The compiler error I'm getting from g++ is
./Debug_gcc_lin64_5610_ST/tom.o: In function `process_P2T_CUST(IPC*)':
/mxhome/charrison/git/libs/tom.cpp:512: undefined reference to `memorize_block(boost::unordered_map< ... >&, Block const&)'
(Ellipsis mine).
The source code snippet containing the undefined reference is:
void
process_P2T_CUST(IPC *client_ipc) {
// Get list of record types in block
Block& block = client_ipc->get_block();
block.get_record_types(input_record_set);
// Reset associative memory
memory.clear();
// Add all field=value pairs from P2T_CUST into memory
memorize_block(memory, block);
And the header definition of memorize_block is:
void memorize_block(MemoryBank&, Block&);
Now: here's how I interpret the error message - the linker (or actually the compiler) has somehow inferred that the required signature of memorize_block() must have parm1 = unordered_map&, and parm2 = Block const&.
But why does it think that the Block should be const?
If I haven't provided enough source code, please comment and I'll amend this question accordingly.
UPDATE 1
Here is the code for memorize_block, which is in the same compilation unit as the reference.
There is no other definition anywhere.
void
memorize_block(MemoryBank& memory, Block &block) {
D_RecordType_Vector record_types;
block.get_record_types(record_types);
BOOST_FOREACH(const D_RecordType_Set::value_type& rec_type, record_types) {
block.traverse_record(rec_type, add_to_memory(memory));
}
}
The problem is not whit the compiler, if you reach that line of error, the compilation is done. Don't worry about the constness of the signature. The problem here is that your linker is not able to find the "definition" of the function, he only knows the "declaration", it's means, you only have the ignature of the function, but not the implementation. If the implementation is in a cpp that is not provided to the compiler, then you need to add it
Related
I'm using C++14 with protobuf to code.
In my proto file, I designed a nested message as below:
message Object {
// something
};
message Response {
repeated Object list = 1;
};
In my C++ project, I try to insert an element:
Object obj;
Response res;
// res.mutable_list()->Add(obj); // ERROR!
res.mutable_list()->Add()->CopyFrom(obj);
I really don't why but Add(obj) will cause a compile error:
cannot bind 'Object' lvalue to 'Object&&'
res.mutable_info()->Add(obj);
I really couldn't understand why because in the header file, I did find the definitions of the funcitons inline void RepeatedPtrField<Element>::Add(Element&& value) and inline void RepeatedPtrField<Element>::Add(const Element& value). But both res.mutable_list()->Add(std::move(obj)); and res.mutable_list()->Add(obj); will cause some compile errors. Another error is as below, which I totally can't understand what it is:
no matching function for call to 'google::protobuf::RepeatedPtrField::TypeHandler::New(Google::protobuf::Area*&, std::remove_reference<Object&>::type)' TypeHandler::New(arena_, std::move(value));
res.mutable_list()->Add()->CopyFrom(obj); works but why can't I simply call Add(obj)?
Add(Object &&object) function requires object argument to be rvalue reference. You can cast to rvalue reference with std::move.
Object obj;
Response res;
res.mutable_list()->Add(std::move(obj)); // This should work.
However after using std::move, you can not access to obj variable anymore, if you try to acces it you will be greeted with segmentation fault. This is why with protobuf, it is much better to create your child message objects from your parent object.
I'm a bit confused about isLandingPad on BasicBlocks in LLVM. I have the following code, where I create an empty BasicBlock and then call isLandingPad on it:
#include "llvm/IR/IRBuilder.h"
#include <assert.h>
using namespace llvm;
int main(void)
{
// Start with a LLVM context.
LLVMContext TheContext;
// Make a module.
Module *TheModule = new Module("mymod", TheContext);
// Make a function
std::vector<Type*> NoArgs = {};
Type *u32 = Type::getInt32Ty(TheContext);
FunctionType *FT = FunctionType::get(u32, NoArgs, false);
Function *F = Function::Create(FT, Function::ExternalLinkage, "main", TheModule);
// Make an empty block
IRBuilder<> Builder(TheContext);
BasicBlock *BB = BasicBlock::Create(TheContext, "entry", F);
Builder.SetInsertPoint(BB);
auto fnp = BB->getFirstNonPHI();
assert(fnp == nullptr);
// I think this should crash.
auto islp = BB->isLandingPad();
printf("isLP = %d\n", islp);
// If we inline the implementation of the above call, we have the following
// (which *does* crash).
auto islp2 = isa<LandingPadInst>(BB->getFirstNonPHI());
printf("isLP2 = %d\n", islp2);
return 0;
}
which outputs:
isLP = 0
codegen: /usr/lib/llvm-7/include/llvm/Support/Casting.h:106: static bool llvm::isa_impl_cl<llvm::LandingPadInst, const llvm::Instruction *>::doit(const From *) [To = llvm::LandingPadInst, From = const llvm::Instruction *]: Assertion `Val && "isa<> used on a null pointer"' failed.
According to the LLVM source of isLandingPad (https://llvm.org/doxygen/BasicBlock_8cpp_source.html#l00470) this should segfault when the BasicBlock is empty (since we are calling isa on a nullptr). However, when I run this program the call to isLandingPad succeeds and returns false. Interestingly, when I inline the function definition of isLandingPad (as seen further below), it crashes as expected.
I'm clearly doing something wrong here, but I don't see in what way the BB->isLandingPad() call is different to the inlined version, and why isLandingPad doesn't crash, when it should according to the source.
LLVM itself is (at least on my system) compiled with assertions disabled, so the assertion doesn't trigger. When you inline it in your code, you are compiling with assertions enabled, so it does trigger.
Note that since isa<...> is a template, it will be compiled into the compilation unit it is instantiated as part of. In this case, there's at least two: one in LLVM and one that comprises your program. Strictly speaking they should both be identical (the "one definition rule") or you have UB anyway. The practical upshot in a case like this one is that calls to isa<...>() from either compilation unit might end up calling the version instantiated in the other one. However, it's likely that in the case of isa<...>() the calls are being inlined, i.e. you end up with a version of isa<...>() specific to each compilation unit that instantiates it.
If the code "should segfault", that seems to imply that the code is invoking undefined behavior (UB) at runtime. It is a possibility that the compiler is doing optimizations based on the false assumption that UB does not occur in your program and this false assumption leads to the false result isLP == false that you observe.
You should never invoke undefined behavior and restructure your code to never call functions with parameters that can call UB. (E.g., check the result of getFirstNonPHI before calling isa<LandingPadInst> or isLandingPad.
Specifically you should not assume that UB (such as dereferencing nullptr or an address near it) has a well-defined effect such as "it will segfault" because the compiler may reorganize your code (assuming UB never happens) in ways that will eliminate the effect you expect (e.g., it will generate code that doesn't attempt to load from nullptr).
Inlining and optimization levels have great effect on the generated code and this is why you see different results (invalid return value vs. segfault) in different cases.
More info on undefined behavior:
Undefined, unspecified and implementation-defined behavior
What Every C Programmer Should Know About Undefined Behavior
https://en.cppreference.com/w/cpp/language/ub (See the links at the bottom of the page for further references)
Consider the following code:
file_1.hpp:
typedef void (*func_ptr)(void);
func_ptr file1_get_function(void);
file1.cpp:
// file_1.cpp
#include "file_1.hpp"
static void some_func(void)
{
do_stuff();
}
func_ptr file1_get_function(void)
{
return some_func;
}
file2.cpp
#include "file1.hpp"
void file2_func(void)
{
func_ptr function_pointer_to_file1 = file1_get_function();
function_pointer_to_file1();
}
While I believe the above example is technically possible - to call a function with internal linkage only via a function pointer, is it bad practice to do so? Could there be some funky compiler optimizations that take place (auto inline, for instance) that would make this situation problematic?
There's no problem, this is fine. In fact , IMHO, it is a good practice which lets your function be called without polluting the space of externally visible symbols.
It would also be appropriate to use this technique in the context of a function lookup table, e.g. a calculator which passes in a string representing an operator name, and expects back a function pointer to the function for doing that operation.
The compiler/linker isn't allowed to make optimizations which break correct code and this is correct code.
Historical note: back in C89, externally visible symbols had to be unique on the first 6 characters; this was relaxed in C99 and also commonly by compiler extension.
In order for this to work, you have to expose some portion of it as external and that's the clue most compilers will need.
Is there a chance that there's a broken compiler out there that will make mincemeat of this strange practice because they didn't foresee someone doing it? I can't answer that.
I can only think of false reasons to want to do this though: Finger print hiding, which fails because you have to expose it in the function pointer decl, unless you are planning to cast your way around things, in which case the question is "how badly is this going to hurt".
The other reason would be facading callbacks - you have some super-sensitive static local function in module m and you now want to expose the functionality in another module for callback purposes, but you want to audit that so you want a facade:
static void voodoo_function() {
}
fnptr get_voodoo_function(const char* file, int line) {
// you tagged the question as C++, so C++ io it is.
std::cout << "requested voodoo function from " << file << ":" << line << "\n";
return voodoo_function;
}
...
// question tagged as c++, so I'm using c++ syntax
auto* fn = get_voodoo_function(__FILE__, __LINE__);
but that's not really helping much, you really want a wrapper around execution of the function.
At the end of the day, there is a much simpler way to expose a function pointer. Provide an accessor function.
static void voodoo_function() {}
void do_voodoo_function() {
// provide external access to voodoo
voodoo_function();
}
Because here you provide the compiler with an optimization opportunity - when you link, if you specify whole program optimization, it can detect that this is a facade that it can eliminate, because you let it worry about function pointers.
But is there a really compelling reason not just to remove the static from infront of voodoo_function other than not exposing the internal name for it? And if so, why is the internal name so precious that you would go to these lengths to hide that?
static void ban_account_if_user_is_ugly() {
...;
}
fnptr do_that_thing() {
ban_account_if_user_is_ugly();
}
vs
void do_that_thing() { // ban account if user is ugly
...
}
--- EDIT ---
Conversion. Your function pointer is int(*)(int) but your static function is unsigned int(*)(unsigned int) and you don't want to have to cast it.
Again: Just providing a facade function would solve the problem, and it will transform into a function pointer later. Converting it to a function pointer by hand can only be a stumbling block for the compiler's whole program optimization.
But if you're casting, lets consider this:
// v1
fnptr get_fn_ptr() {
// brute force cast because otherwise it's 'hassle'
return (fnptr)(static_fn);
}
int facade_fn(int i) {
auto ui = static_cast<unsigned int>(i);
auto result = static_fn(ui);
return static_cast<int>(result);
}
Ok unsigned to signed, not a big deal. And then someone comes along and changes what fnptr needs to be to void(int, float);. One of the above becomes a weird runtime crash and one becomes a compile error.
I have a very simple class that looks as follows:
class CHeader
{
public:
CHeader();
~CHeader();
void SetCommand( const unsigned char cmd );
void SetFlag( const unsigned char flag );
public:
unsigned char iHeader[32];
};
void CHeader::SetCommand( const unsigned char cmd )
{
iHeader[0] = cmd;
}
void CHeader::SetFlag( const unsigned char flag )
{
iHeader[1] = flag;
}
Then, I have a method which takes a pointer to CHeader as input and looks
as follows:
void updateHeader(CHeader *Hdr)
{
unsigned char cmd = 'A';
unsigned char flag = 'B';
Hdr->SetCommand(cmd);
Hdr->SetFlag(flag);
...
}
Basically, this method simply sets some array values to a certain value.
Afterwards, I create then a pointer to an object of class CHeader and pass it to
the updateHeader function:
CHeader* hdr = new CHeader();
updateHeader(hdr);
In doing this, the program crashes as soon as it executes the Hdr->SetCommand(cmd)
line. Anyone sees the problem, any input would be really appreciated
When you run into a crash, act like a crime investigator: investigate the crime scene.
what is the information you get from your environment (access violation? any debug messages? what does the memory at *Hdr look like? ...)
Is the passed-in Hdr pointer valid?
Then use logical deduction, e.g.:
the dereferencing of Hdr causes an access violation
=> passed in Hdr points to invalid memory
=> either memory wasn't valid to start with (wrong pointer passed in), or memory was invalidated (object was deleted before passing in the pointer, or someone painted over the memory)
...
It's probably SEGFAULTing. Check the pointers.
After
your adding some source code
your comment that the thing runs on another machine
the fact that you use the term 'flag' and 'cmd' and some very small datatypes
making me assume the target machine is quite limited in capacity, I suggest testing the result of the new CHeader for validity: if the system runs out of resources, the resulting pointer will not refer to valid memory.
There is nothing wrong with the code you've provided.
Are you sure the pointer you've created is the same same address once you enter the 'updateHeader' function? Just to be sure, after new() note the address, fill the memory, sizeof(CHeader), with something you know is unique like 0XDEAD, then trace into the updateHeader function, making sure everything is equal.
Other than that, I wonder if it is an alignment issues. I know you're using 8 bit values, but try changing your array to unsigned ints or longs and see if you get the same issue. What architecture are you running this on?
Your code looks fine. The only potential issue I can see is that you have declared a CHeader constructor and destructor in your class, but do not show the implementation of either. I guess you have just omitted to show these, else the linker should have complained (if I duplicate this project in VC++6 it comes up with an 'unresolved external' error for the constructor. It should also have shown the same error for the destructor if you had a... delete hdr; ...statement in your code).
But it is actually not necessary to have an implementation for every method declared in a class unless the methods are actually going to get called (any unimplemented methods are simply ignored by the compiler/linker if never called). Of course, in the case of an object one of the constructor(s) has to be called when the object is instantiated - which is the reason the compiler will create a default constructor for you if you omit to add any constructors to your class. But it will be a serious error for your compiler to compile/link the above code without the implementation of your declared constructor, so I will really be surprised if this is the reason for your problem.
But the symptoms you describe definitely sounds like the 'hdr' pointer you are passing to the updateHeader function is invalid. The reason being that the 1st time you are dereferencing this pointer after the updateHeader function call is in the... Hdr->SetCommand(cmd); ...call (which you say crashes).
I can only think of 2 possible scenarios for this invalid pointer:
a.) You have some problem with your heap and the allocation of memory with the 'new' operator failed on creation of the 'hdr' object. Maybe you have insufficient heap space. On some embedded environments you may also need to provide 'custom' versions of the 'new' and 'delete' operator. The easiest way to check this (and you should always do) is to check the validity of the pointer after the allocation:
CHeader* hdr = new CHeader();
if(hdr) {
updateHeader(hdr);
}
else
//handle or throw exception...
The normal behaviour when 'new' fails should actually be to throw an exception - so the following code will cater for that as well:
try{
CHeader* hdr = new CHeader();
} catch(...) {
//handle or throw specific exception i.e. AfxThrowMemoryException() for MFC
}
if(hdr) {
updateHeader(hdr);
}
else
//handle or throw exception...
}
b.) You are using some older (possibly 16 bit and/or embedded) environment, where you may need to use a FAR pointer (which includes the SEGMENT address) for objects created on the heap.
I suspect that you will need to provide more details of your environment plus compiler to get any useful feedback on this problem.
i am using encrypt function of cryptography api(fun declared as virtual)
//fun declaration
TBool EncryptL(const TDesC8 &aInput, TDes8 &aOutput);
//function calling
TBuf8<10> text;
TBuf8<10> cipher;
text.Copy(_L("Hello"));
iEncryptor.EncryptL(text,cipher); it shows error expression syntax error
//fun definition
TBool CRSAAlgo::EncryptL(const TDesC8 &aInput,TDes8 &aOutput)
{
if(iEncryptor)
{
TInt len = iEncryptor->MaxInputLength();
}
}
i want to know what is exact problem
The main issue here, the reason your compiler complains is that you are using iEncryptor as an object or a reference, while it probably is a C++ pointer.
To move to the next stage, try using:
iEncryptor->EncryptL(text,cipher);
As you did not post the exact error message you get from the compiler I have to guess.
I assume the problem is that the EncryptL function you show expects to get arguments of type TDesC8 and you pass a TBuf8<10> to it. Unless TDesC8 were a typedef to TBuf8<10> these are different and therefore for the compiler incompatible types.
Ypou are also using iEncryptor once as a pointer: iEncryptor->MaxInputLength(); and at the location where you see the error as an object: iEncryptor.EncryptL(text,cipher);. Only one form can be correct. As we don't have more code from you I don't know which, but given the fact that the latter has the error I suspect the latter.