wolof@freemail.hu ("White Wolf") wrote in message news:<b1bsb3$e10$1@phys-news1.kolumbus.fi>...
> <danielgutson@hotmail.com> wrote:
> [SNIP]
> > A real life example would implement a real MSC, with branches,
> > conditions, and message bodies, and more than two instances, as for
> > example a project about GPRS I was involved last year.
>
> Well, I do messaging at work all day, but I still do not see what you mean.
> :-(  Our architecture is pretty clean and uses MT quite efficiently to
> deliver messages between the many state machines.  And of course, you can
> find out where the message came from - but this must only be done if it
> must be done... :-)

Of course when you have a messaging subsystem you include the sender
and the target.
But I don't want to go there! :)

I'm talking simple function calls, when you don't have 'entry points'
in your components, just synchronous functions to call :)

Ok, I think I can see the confusion.
Maybe I misused the word 'message'. Forget about autonomous and
communicating processes, forget about concurrency, forget about SDL.
Just think in simple sequencial calls.
What I'm talking is about instances of objects [ -in a single exec.
thread, just for clarifying- ] that inter-calls between them.
Those calls are not statically predefined, are no hierarchyc, and are
not layered.
(I'm posting restrictions just for didactic purposes, my English
doesn't help here :(   ).
Even more, suppose they are all instances of the same class (i.e. ZERO
layering).

So, let's arrive to this:
 - they are calls where the 'this' is passed
 - it's a 'small talk' (...) They are chatting.
 - calling sequences are not large enough to fill the stack.

I feel a bit ridiculous saying so many things for a simple concept :)
But I don't know how to describe it!

Ok, I don't pretend to continue this thread, I got what I wanted:
feedback. Two things happened: my explanation is dark, and/or indeed
this is not a common situation for many programmers (that was what I
originally wanted to know).

The only thing I was wanted to state was:
* when you <must> pass 'this' as parameter in a calling chain
(because of ...[cases]...)
how would help providing a standard way of accepting 'this' as an
<implicit parameter> (that is, the compiler passes it for you -as the
caller-, instead of passing it as parameter, but explicitly receiving
it in the callee prototype) as far as the caller information is
already in the stack. So I <additionally> tried to imagine some
advantages apart from 'performance'. Failed.

According to your feedback and the silence of the rest of the readers,
this seems to be useless.

Thanks anyway.

  Daniel.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

<danielgutson@hotmail.com> wrote:
[SNIP]
> The only thing I was wanted to state was:
> * when you <must> pass 'this' as parameter in a calling chain
> (because of ...[cases]...)
> how would help providing a standard way of accepting 'this' as an
> <implicit parameter> (that is, the compiler passes it for you -as the
> caller-, instead of passing it as parameter, but explicitly receiving
> it in the callee prototype) as far as the caller information is
> already in the stack. So I <additionally> tried to imagine some
> advantages apart from 'performance'. Failed.

Hey, listen to yourself, your subcons-IdunnoHowToSpellIt told you
already: make messages!  Make them visitors or something similar.  You
yourself (see your OP) see that those are really messages.  And what
does messages do?  They bounce inside your application (whether with
function calls or real message delivery mechanism it does not matter)
between those "posts", which handle them.  Try to make a mental picture
of that, and you will be able to simplify the task.  Handling posts,
messages, communication channels (who knows about whom) etc.

WW aka Attila


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

wolof@freemail.hu ("White Wolf") wrote in message news:<b1k99m$et5$1@phys-news1.kolumbus.fi>...
> <danielgutson@hotmail.com> wrote:
> [SNIP]
> > The only thing I was wanted to state was:
> > * when you <must> pass 'this' as parameter in a calling chain
> > (because of ...[cases]...)
> > how would help providing a standard way of accepting 'this' as an
> > <implicit parameter> (that is, the compiler passes it for you -as the
> > caller-, instead of passing it as parameter, but explicitly receiving
> > it in the callee prototype) as far as the caller information is
> > already in the stack. So I <additionally> tried to imagine some
> > advantages apart from 'performance'. Failed.
>
> Hey, listen to yourself, your subcons-IdunnoHowToSpellIt told you
> already: make messages!  Make them visitors or something similar.  You

Ok, give up   :)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

<danielgutson@hotmail.com>:
> Hello people. I've got a question, and I know that people here far
> more experienced than me would come with an answer.
>
> How useful/useless would be the ability of receiving in a function the
> pointer to the caller as a special parameter?
> This is NOT a proposal, just a question, perhaps an excersize.
>
> I neither thought a syntax, but suppose we could differentiate three
> situations:
>
> given a function, we could receive:
>
>   - a pointer to the function caller
>   - a pointer to the calling class (or its base class)
>   - a pointer to the calling class and the pointer to the calling
> member
[SNIP]

IMHO it is a Bad Idea.  A function (as well as a class) should be a closed
entity.  It should not decide what it does depending on who calls.  That is
the job of either overload resolution or template instantiation.  If you
wanna go dynamic, you (seem to) need some sort of visitor (acyclic
visitor).

The idea remind me of a 5Win base Window class and its function (that is
CA-Clipper, a dynamic (interpreted) language like Java) which said: if
myclass=="MDIChild"...

I think once you are inside a function you are better off not depend on
anything else than:

1. the arguments

2. the internal state

3. an external state

2 is not recommended for non-member functions.

3 is not recommended for any function but sometimes unavoidable, like if a
system is shutting down and does not allow you to do something

IMHO the "who is the caller" should be decided:

1. compile time
  1.a. by the overload resolution
  1.b. by templates

2. Runtime by double dispatch (visitor)

WW


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

wolof@freemail.hu ("White Wolf") wrote in message news:<b14r7v$86r$1@phys-news1.kolumbus.fi>...
> <danielgutson@hotmail.com>:
> > Hello people. I've got a question, and I know that people here far
> > more experienced than me would come with an answer.
> >
> > How useful/useless would be the ability of receiving in a function the
> > pointer to the caller as a special parameter?
> > This is NOT a proposal, just a question, perhaps an excersize.
> >
> > I neither thought a syntax, but suppose we could differentiate three
> > situations:
> >
> > given a function, we could receive:
> >
> >   - a pointer to the function caller
> >   - a pointer to the calling class (or its base class)
> >   - a pointer to the calling class and the pointer to the calling
> > member
> [SNIP]
>
> IMHO it is a Bad Idea.  A function (as well as a class) should be a closed
> entity.  It should not decide what it does depending on who calls.

I agree with you that this would look worse than global functions (in
terms of worst practices). I also agree that the function should only
be able to read information FROM parameters.

And THERE is where my question come from (I can see that my
explanation above wasn't enough).

First, I propose to differentiate two calling situations

1- FunctionA -> FunctionB
2- FunctionA <-> FunctionB

In the first case, there's a hierarchycal calling sequence, and
FunctionB is abstracted from its caller (as should be).

But, in the second case, both functions are 'at the same level', and
who initiated the call would be anecdotic in terms of sequence.

I'm talking, for example, when someone does:

class X
{
    ...
    void msg(Y& y)
    {
      y.msg(this);
    }
    ...
};

class Y
{
   ...
   void msg(X& x)
   {
     x.msg(this);
   }
};

This is a bizarre example of ping-pong messaging, but the idea is to
show when 'this' is passed. This is the example of same-level
functions.

What I'm asking above, is that: considering that the compiler already
passes the caller information [i.e. in the stack], would it be useful
to provide the ability of getting access to it (the caller)?

The difference here, from the programmer point of view, would be just
-caller: avoiding to pass the 'this' parameter (as far as it would be
automatic), and
-callee: same parameter declarations but a distinction for the
'caller' (in my initial message, adding the ()  )

Hey, I admit this is a 'dangerous' concept, when misused, but again,
for same-level messaging.

Anyway, I consider your answer very useful and absolutely valid.
Thanks.

 Daniel.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

<danielgutson@hotmail.com> wrote:
[SNIP]
> But, in the second case, both functions are 'at the same level', and
> who initiated the call would be anecdotic in terms of sequence.

This is called multithreading or multiprocessing (forking).  And there is a
3rd function calling those two.  If I understand you.  If not... then I
don't know. :-)

> I'm talking, for example, when someone does:
>
> class X
>     void msg(Y& y) { y.msg(this); }
> };

> class Y
> {
>    void msg(X& x) { x.msg(this); }
> };
>
> This is a bizarre example of ping-pong messaging, but the idea is to
> show when 'this' is passed. This is the example of same-level
> functions.

Hm.  Is it?  For me this is an example of an overcomplicated recursive
implementation of an endless loop - and it has two possible entry points.
It sorta' reminds me to discussions with my ex (when she lied, stole
something etc.): endless, repetitive, exhausts your resources and nothing
else whatsoever changes. :-)

> What I'm asking above, is that: considering that the compiler already
> passes the caller information [i.e. in the stack], would it be useful
> to provide the ability of getting access to it (the caller)?

In my architecture there is no stack...  And in yours it would be exhausted
in milliseconds by the above code.  I don't know where do you want to get.
:-( I do not undertsand you.  Could you give a real life example?

WW aka Attila


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

wolof@freemail.hu ("White Wolf") wrote in message news:<b19779$t2h$1@phys-news1.kolumbus.fi>...
> <danielgutson@hotmail.com> wrote:
> [SNIP]
> > But, in the second case, both functions are 'at the same level', and
> > who initiated the call would be anecdotic in terms of sequence.
>
> This is called multithreading or multiprocessing (forking).  And there is a
> 3rd function calling those two.  If I understand you.  If not... then I
> don't know. :-)

Okokokok :)

By parts, as 'Jack' used to say.
First, of course my example finishes the stack; what I wanted to show
was the same-level methods, but it seemed I was too schematic :)
The second thing I want to clarify, is that this has nothing to do
with multithreading (despite multithreading usually presents behaviors
like this), but the concept, yes, let's say its similar.

Let me try again :)  (not with a real-life example, otherwise I should
come with a Message Sequence Chart!)

struct X
{
    void msg1(Y& y)
    { y.msg1(*this); }

    void msg2(Y& y)
    { y.msg2(*this); }

    void msg3(Y& y)
    {
      y.msg3(*this);
      delete this; //for the 'delete this' fans
    }
};

struct Y
{
    void msg1(X& x)
    { x.msg2(*this); }

    void msg2(X& x)
    { x.msg2(*this); }

    void msg3(X& x)
    {
      delete this;
    }
};

void f(void)
{
  X x = new X;  Y y = new Y;

  x->msg1(*y);
}

A real life example would implement a real MSC, with branches,
conditions, and message bodies, and more than two instances, as for
example a project about GPRS I was involved last year.

   Daniel.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

<danielgutson@hotmail.com> wrote:
[SNIP]
> A real life example would implement a real MSC, with branches,
> conditions, and message bodies, and more than two instances, as for
> example a project about GPRS I was involved last year.

Well, I do messaging at work all day, but I still do not see what you mean.
:-(  Our architecture is pretty clean and uses MT quite efficiently to
deliver messages between the many state machines.  And of course, you can
find out where the message came from - but this must only be done if it
must be done... :-)

WW aka Attila


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hello people. I've got a question, and I know that people here far
more experienced than me would come with an answer.

How useful/useless would be the ability of receiving in a function the
pointer to the caller as a special parameter?
This is NOT a proposal, just a question, perhaps an excersize.

I neither thought a syntax, but suppose we could differentiate three
situations:

given a function, we could receive:

  - a pointer to the function caller
  - a pointer to the calling class (or its base class)
  - a pointer to the calling class and the pointer to the calling
member

I thought some possible uses, but as I said above, maybe I'm wrong, or
maybe more benefits could exist.

- we could restrict callers (by specifying the type of the caller [in
the class case] or its signature [function case])
- we could overload the same function but differentiating it through
the caller
- Considering that the caller information is already passed, we could
get an efficiency improvement for upmessagin(*) as far as the caller
doesn't need to pass 'this' as a parameter
- debugging (more specifically, DebugPrints for kernel modes or real
time when debugger is not available and therefore there's no calling
stack information).

(*) I mean by upmessaging the ability of querying the caller during
the function excecution; this **could** alleviate the number of
parameters.

The only thing I'm asking for is your experience: in which situation
of your professional experience something like this would had helped
you. There were some situations I had that having this would became
useful (for example when many messages had to be sequentially
exchanged between two objects)

I picture an example just for helping my wording above:

struct ACaller
{
  void callFunction()
  {
    function(1);
  }

  virtual int getSomeData()=0;
};

class ACallerImp : public ACaller{ ... };

void function( ACaller()* pCaller, int something )
{
   switch(pCaller->getSomeData())
   { ...
   }
}

using the () next to the caller class type for denoting 'caller
class'.

By this, I just wanted to get advantage of two things:
- the caller information is already there (so formalizing this in a
standard way perhaps would bring some advantage)
- parameters: function overloading

Thanks for your help,

  Daniel.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]