Orchid XP v8 wrote:
> OOC, what the hell is this "boost" I keep hearing about?
> 

A set of advanced C++ libraries with varying levels of sanity.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >> Warp wrote:
> >>>   Isn't this usually handled with callback interfaces (in OO languages)
> >>> rather than function pointers?
> > 
> >> Only in languages that don't support pointers to member functions.
> > 
> >   C++ supports pointers to member functions, yet using callback interfaces
> > is a rather common idiom.

> How do you declare a pointer to a member function, then?  I thought you 
> had to keep a pointer to the object and then somehow invoke the proper 
> member function, but I don't know the syntax for that latter part?

  Obviously you need an object if you want to call a member function,
be it directly or through a member function pointer. (Member functions
always require an object, as they take one as "hidden" parameter. You
can't call a member function without an object.)

  Member function pointer syntax is rather complicated. If you have,
for example:

class A
{
 public:
    void foo(int i) { std::cout << "foo: " << i << std::endl; }
    void bar(int i) { std::cout << "bar: " << i << std::endl; }
};

then you can create a member pointer named functionPointer, and make it
point to 'foo' like this:

    void (A::*functionPointer)(int) = &A::foo;

  (With the next C++ standard things will get easier, as you will be able
to write simply: "auto functionPointer = &A::foo;")

  You can call it like this:

    A a;
    (a.*functionPointer)(5);

    A* aPtr = &a;
    (aPtr->*functionPointer)(10);

  Note that this will work even if foo() is a virtual function overridden
in a class derived from A, and 'aPtr' (while still being of type A*) was
actually pointing to an object of this derived class.

  Also note that 'functionPointer' is in no way tied precisely to the
foo() function. You can make it point to another member function with
the same signature:

    functionPointer = &A::bar;
    (a.*functionPointer)(5); // Now A::bar() is called

  Curiously, you can even make pointers to member variables. That's
obscure if anything.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   (With the next C++ standard things will get easier, as you will be able
> to write simply: "auto functionPointer = &A::foo;")
> 
>   You can call it like this:
> 
>     A a;
>     (a.*functionPointer)(5);

Oh, I see. No, I was talking about one object/pointer/variable etc that 
pointed to one instance's member function.

For example, in C#, if you have
   class A {
     public float abc;
     public int xyz(int pdq) { return (int) abc; }
     public static mno(int pdq) { return pdq*pdq; }
   }
   int (*point)(int);
   A alpha = new A();
   alpha.abc = 23.75;

then you can do
   point = &(alpha.xyz);
   int x = (*point)(23);
   point = &(A.mno);
   int y = (*point)(75);

/* I might have the syntax mildly wrong, and I'm probably using
    too many parens, but ... */

So the member pointer actually carries around the reference to the 
object, if it needs to. Or it can point to a static (non-member) 
function. I think Python does the same thing.

>   Also note that 'functionPointer' is in no way tied precisely to the
> foo() function. You can make it point to another member function with
> the same signature:
> 
>     functionPointer = &A::bar;
>     (a.*functionPointer)(5); // Now A::bar() is called

Yeah, but invoking it requires both the object and the pointer. *Now* I 
remember what is going on there. It definitely makes it easier to make 
data structures that deal with function pointers if you only care about 
the types of arguments and results, and not which class of object is 
implementing it. It does, obviously, add some overhead, of course. This 
way, you can have (say) an array of pointers to member functions, all of 
which are implemented by unrelated classes. I guess in C++ you could use 
MI to deal with something like that, while C# wouldn't support it the 
same way.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

> You're Californian?
>
> Wow... suddenly a whole lot of POV-Ray stuff makes way more sense... ;-)

Huh? I'm not sure I get it. =) I am not on the POV-Ray development team.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

> Copy...constructor...? x_x
>
> Heh. And I thought figurating out the difference between a const pointer 
> and a pointer to a const was hard!

It seems like you're learning a lot of language features, one after another. 
If I were you I'd slow down a bit, take what you know already, and find 
something fun to do with it. Make a text based adventure game or something. 
The key is to find a hook that keeps you interested, so you start to use the 
language in a more real manner, and then you learn features as you find you 
need (or want) them.

On the other hand, if your motivation is to master the intricacies of the 
language, then do that. Just don't burn yourself out trying to learn one 
thing after another. It's a lot like math - they don't teach fractions to 
first graders because they need to spend time learning addition and 
subtraction to fully master the concepts.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Slime wrote:

> It seems like you're learning a lot of language features, one after another. 
> If I were you I'd slow down a bit, take what you know already, and find 
> something fun to do with it. Make a text based adventure game or something. 
> The key is to find a hook that keeps you interested, so you start to use the 
> language in a more real manner, and then you learn features as you find you 
> need (or want) them.

That was kind of my plan. And it went as far as me writing two simple 
C++ programs that actually work.

Now, however, all the programs I can think of that I'd like to write all 
involve constructing dynamic data structures - and the tutorial I'm 
following doesn't seem to cover that in much detail yet. In fact, it now 
seems to have degenerated into more of a categorical reference manual 
than a "tutorial"...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Slime wrote:
>> You're Californian?
>>
>> Wow... suddenly a whole lot of POV-Ray stuff makes way more sense... ;-)
> 
> Huh? I'm not sure I get it. =) I am not on the POV-Ray development team.

Californians have a reputation for being... uh... "unusual". Which would 
certainly explain... for example... your nick is "slime"? o_O And also 
some of the wacky things you've rendered over the years.

I'm jesting of course... just because the most interesting thing *I* 
ever rendered was a 3D section of the cubic Mandelbrot set... :-(

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> Now, however, all the programs I can think of that I'd like to write all 
> involve constructing dynamic data structures

  What kind of data structures? Are they something which you can't do with
the STL data containers? If you have any questions about using those
containers, just ask.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Orchid XP v8 <voi### [at] devnull> wrote:
>> Now, however, all the programs I can think of that I'd like to write all 
>> involve constructing dynamic data structures
> 
>   What kind of data structures? Are they something which you can't do with
> the STL data containers? If you have any questions about using those
> containers, just ask.

I was thinking maybe I'd try implementing a Huffman coder. I need a 
binary tree for that. Does STL happen to have one already? (That would 
obviously be the simplest thing...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> I was thinking maybe I'd try implementing a Huffman coder.

  That sounds like a bit advanced... :)

> I need a 
> binary tree for that. Does STL happen to have one already? (That would 
> obviously be the simplest thing...)

  std::set (as well as std::map) is internally implemented as a balanced
binary tree, but if I'm not mistaken, a Huffman coder requires an
unbalanced one, so it may be unusable for that purpose.

  But yeah, if you need to create your own dynamic data containers, it
inevitably means you will have to deal with pointers, 'new' and explicit
memory management. (Although using smart pointers may by possible in
this situation.)

-- 
                                                          - Warp

Post a reply to this message