[C++] Function pointers problem

[venomous]

Looks like my first post on those forums will be a help topic.
So, I've got that problem a while back, but I took a break from programming and now I'm trying to get it working.
Now I'll try to explain what I'm trying to do:
What I'm trying to do is to send a function pointer through a class (schedule) method argument. Okay, got that working. Next I want to send the object, containing the pointer I sent before, to method of second class (scheduler), so that it can copy those pointers into a function pointers array. This gives me no errors. Next I call a method of the second class (scheduler) which executes every function pointer from the array of the second class(scheduler). And that's where the problem is. I mean it compiles fine, but the linker gives me an error like that:

Code: Select all

out/kernel.o:(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'

What I want is:
1. Does the problem lie within the source code?
2. Is this a linker bug?
3. Is the function pointer execution a part of standard library?

Here's the header containing both classes:

Code: Select all

#ifndef SCHEDULER
#define SCHEDULER

class schedule{
     public:
      void (*schedulep)();
      void constructschedule(void (*schedulepa)()){
           schedulep=schedulepa;
      }
};

class scheduler{
      int sitem;
      void (*schedulesp[10])();
     public:
      scheduler(){
           sitem=0;
      }
      void scheduleradd(schedule s){
           if(sitem!=10){
           schedulesp[sitem]=s.schedulep;
           sitem++;
           }
      }
      void schedulerexecute(){
           int i=0;
           while(i<sitem){  
               (*schedulesp[i])();  
                i++;     
           }
      }
};

#endif

[JamesM]

Hi,

Code: Select all

out/kernel.o:(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'

This is a known issue. __gxx_persoinality_v0 normally lies in libstdc++, but as you don't (and can't) have it in a kernel, you have to define it yourself.

Code: Select all

void *__gxx_personality_v0;

Just put that somewhere global and the problem should dissappear!

Cheers,

James

[venomous]

That worked, thanks!

[skyking]

Try disabling exception handling instead.

If a exception happens to be thrown (which can't happen by mistake if exceptions are disabled) the exception handling will be broken by defining a dummy symbol. Besides exception handling increases the exe-image size for no good use.

[Solar]

Besides exception handling increases the exe-image size for no good use.

Disabling exception handling is a viable alternative.

But:

1) Keep in mind that, by default, new() is expected to throw a bad_alloc when running out of memory, and

2) claiming that exception handling has "no good use" is... no, I won't.

[CodeCat]

But you don't have new in your kernel either, so any implementation of it that you write wouldn't need to throw an exception anyway.

[Solar]

But you don't have new in your kernel either...

How do you know? Actually I don't have a kernel to show, but there isn't any reason why a kernel shouldn't have new(), or exceptions, other than "complex to implement".

[CodeCat]

No, but what I meant is that you can't really use a standard implementation of new because it's part of the (platform specific) C++ runtime. So you have to write your own, but when you do, then the exception-throwing is no longer an issue because it's your choice how you implement it.

[Colonel Kernel]

I was curious about what exactly __gxx_personality_v0 does, so I put the question to a bigger community. Here is what they came up with:

http://stackoverflow.com/questions/3290 ... lityv0-for

[skyking]

Besides exception handling increases the exe-image size for no good use.

Disabling exception handling is a viable alternative.

But:

1) Keep in mind that, by default, new() is expected to throw a bad_alloc when running out of memory, and

2) claiming that exception handling has "no good use" is... no, I won't.

#2 wasn't what I meant, exception handling has no good use if it doesn't work which is the case if you just stub out functions needed for the exception handling. It's better to disable it if the alternative is to break it.

[Owen]

I'm one of the - rare it seems - people of the opinion that C++ and .net style (ignorable) exceptions are a bad idea. The reason? In C, you know that pretty much after every function call you should be checking for errors, and so bad code (which doesn't) looks, well, bad.

Meanwhile, when you start using C++ or .net exceptions, this changes. An exception gets thrown and you forget to handle it? Your code just vectored away to the innermost applicable catch block. In .net it might - might - come back if you were thoughtful enough to include a finally block. In C++, it's gone forever. The only thing which gets called after that are scope destructors.

Take the following code:

Code: Select all

SomeClass* a = new SomeClass();
a.b = new SomeOtherClass(); // exception thrown here
return a;

You just leaked a. If this wasn't exception based code, then the incorrect code would look similar. The correct code would check errors incessently.

Return codes are evil, inelegant, messy, and double the size of your code. Exceptions are elegant, cleaner, still double the size of your code if done right. And go wrong subtly.

Java exceptions work by bludgening you into acknowledging them - even if you write the atrocity that is try { ... } catch(Exception ex) {} - handling them wrong looks very wrong. Ignorable exceptions are best reserved for exceptional circumstances, where the error is unrecoverable and you are going to die once you've generated a crash report.

The best C(++) error handling system I've seen is that used by ICU. Your code looks like this (this is just me paraphrasing - I haven't used ICU in a while):

Code: Select all

ICUError ex = NULL;
icu_strcpy(a, b, &ex);
icu_strcpy(c, d, &ex);
if(ex) { /* an error occured */ }

It makes error handling code like with exceptions - divided into logical blocks, because a function where the passed error variable is not NULL will return doing nothing. You can run a set of functions then check for errors, while it maintains the error code system's padagrim of bad code looks bad.

[Colonel Kernel]

Code: Select all

SomeClass* a = new SomeClass();
a.b = new SomeOtherClass(); // exception thrown here
return a;

You just leaked a.

Any experienced C++ developer would say that the above code looks "bad", just like C code that doesn't check return values. It really should use smart pointers -- that's what they're for.

"Bad" code only looks "bad" because you were trained to see it that way.

The correct code would check errors incessently.

Nope, because that checking can be encapsulated using RAII.

Also, this problem isn't nearly as bad in garbage-collected languages. However, I will say that exceptions and mutable state in general are a tricky combination. What we really need are transactional semantics integrated into the language. This problem is not unique to exceptions, however (e.g. -- forgetting "cleanup" activities in C code).

Java exceptions work by bludgening you into acknowledging them - even if you write the atrocity that is try { ... } catch(Exception ex) {} - handling them wrong looks very wrong.

Checked exceptions are a bad idea for this reason. That's why they're not in .NET.