Thread: Function-pointer scope problem.

  1. #1
    Registered User
    Join Date
    Jul 2006
    Posts
    19

    Function-pointer scope problem.

    I would like to define a function pointer;
    Code:
    typedef long (*EventCallback)(Widget*,int);
    However the Widget class contains a member variable function pointer of type EventCallback (or at least I would like it to).

    Any ideas how I could make it work without having to use the bare syntax? (eg; long(*callback)(Widget*,int); as member)...

    Probably not possible, I would sort of hope not because as far as my understanding of things goes it shouldn't be possible. But to keep updating and modifications easy (eg, changing a single typedef instead of lots of classes out of scope) I wouldn't mind an easier solution to this problem.

    Thanks peeps

  2. #2
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,661
    Like this?
    Code:
    class Widget;
    
    typedef long (*EventCallback)(Widget*,int);
    
    class Widget {
      EventCallback	func;
    };
    The first class is just a forward declaration for the class. It's all you need to create a pointer to it, since there is no need to work out the size simply to have a pointer to it.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  3. #3
    Registered User
    Join Date
    Jul 2006
    Posts
    19
    But isn't forward declaration *bad* practice? I for some reason always try to steer away from it and ignore that it is at all possible. I think I read it somewhere a long time ago when I was beginning to prorgam.

    I guess just because things become complicated doesn't indeed mean they're messy.

  4. #4
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Think of it as a function prototype. That's pretty much all it is, except it's for an object.


    Quzah.
    Hope is the first step on the road to disappointment.

  5. #5
    Registered User Osaou's Avatar
    Join Date
    Nov 2004
    Location
    Stockholm, Sweden
    Posts
    69
    It's definitely Not bad practice...
    That doesn't mean you should use it when it isn't necessary, however. I mean, it doesn't hurt, but it can lead to code clogging etc...

  6. #6
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,057
    Actually, in the case of function prototypes, it's bad practice to leave them out.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  7. #7
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,661
    So long as you only use them where necessary (in which case, you have no choice), there shouldn't be a problem.
    You only need them where you have some sort of mutual recursion going on like this example, that you need a forward declaration just to break the cycle.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  8. #8
    Registered User
    Join Date
    Jul 2006
    Posts
    19
    Yeah I see your point. Thanks for the input.

  9. #9
    Registered User
    Join Date
    May 2003
    Posts
    1,619
    Actually, forward declarations can be very good in many cases; they can help to greatly reduce compile time.

    For example, say you have this:

    Code:
    // B.h
    #include "A.h"
    
    class B{
       public:
          ...
       private:
          A* theA;
    };
    You'd be better off removing #include "A.h", and replacing it with "class A;". You then move the #include "A.h" into B.cpp instead of B.h.

    The reason for this is to improve compile time. If you make a change to A.h and you are using the first scenario, every cpp file that includes A.h OR B.h needs to be recompiled. If you use the second way, only files that directly include A.h need recompilation.

    It's quite possible on large projects with many, many .cpp and .h files, that a single change in a .h file could force a full recompile on every single source file, and typically those large projects are the ones with the 20 minute or longer compile times.

    In general, the best practice is to only use a full #include when you cannot get away with just a forward declaration. Especially when the file you're including may change; it's not such a big deal with things like <string> or <iostream> where you can be quite sure they're not changing.

    If you're interested, you can check out this URL, and look at the example. Note that even though class A uses a C* within the class, neither the header file nor the .cpp file actually require a full definition of class C, and so c.h is never included in either.
    Last edited by Cat; 09-10-2006 at 02:47 AM.
    You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. sorting number
    By Leslie in forum C Programming
    Replies: 8
    Last Post: 05-20-2009, 04:23 AM
  2. Screwy Linker Error - VC2005
    By Tonto in forum C++ Programming
    Replies: 5
    Last Post: 06-19-2007, 02:39 PM
  3. We Got _DEBUG Errors
    By Tonto in forum Windows Programming
    Replies: 5
    Last Post: 12-22-2006, 05:45 PM
  4. problem about static Lib and function pointer
    By wu7up in forum C Programming
    Replies: 3
    Last Post: 02-24-2003, 09:34 AM
  5. Contest Results - May 27, 2002
    By ygfperson in forum A Brief History of Cprogramming.com
    Replies: 18
    Last Post: 06-18-2002, 01:27 PM