![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> Warp wrote:
> > Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Orchid XP v8 <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |