Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Visual C++ 2008 - class definition with "this" as an argument (not a register)
52 views
Skip to first unread message
R.Wieser
Aug 10, 2017, 3:21:00 AM8/10/17
to
Hello All,
-- First question:
I've created, in Visual C++ 2008, a class like the below (to communicate
with a non-VC++, dynamically loaded object).
class ExternalObject {
public:
ExternalObject();
~ExternalObject(){};
virtual void Destructor(ExternalObject* TheObject) = 0;
virtual int Message(ExternalObject* TheObject, int* type, void* data) = 0;
};
As you can see each virtual method currently contains a manually provided
"this" argument (TheObject), and needs to be called like this:
MyObject->Message(MyObject, 0, "Hello World");
My question is, how can I change the class in such a way that the "MyObject"
'this' argument is automatically added ?
Or to be more precise, how can tell Visual C++ 2008 to transfer the 'this'
*by argument* instead of by the ECX register.
-- Second question:
How do I do the reverse -- When an external object calls an object within
the Visual C++ 2008 program have it accept a provided 'this' *argument* and
make it available inside the called method by way of the 'this' keyword.
Remark: The code, using the described class, already works. I just want to
know if I can create a "cleaner" implementation of the above.
Regards,
Rudy Wieser
-- First question:
I've created, in Visual C++ 2008, a class like the below (to communicate
with a non-VC++, dynamically loaded object).
class ExternalObject {
public:
ExternalObject();
~ExternalObject(){};
virtual void Destructor(ExternalObject* TheObject) = 0;
virtual int Message(ExternalObject* TheObject, int* type, void* data) = 0;
};
As you can see each virtual method currently contains a manually provided
"this" argument (TheObject), and needs to be called like this:
MyObject->Message(MyObject, 0, "Hello World");
My question is, how can I change the class in such a way that the "MyObject"
'this' argument is automatically added ?
Or to be more precise, how can tell Visual C++ 2008 to transfer the 'this'
*by argument* instead of by the ECX register.
-- Second question:
How do I do the reverse -- When an external object calls an object within
the Visual C++ 2008 program have it accept a provided 'this' *argument* and
make it available inside the called method by way of the 'this' keyword.
Remark: The code, using the described class, already works. I just want to
know if I can create a "cleaner" implementation of the above.
Regards,
Rudy Wieser
Alf P. Steinbach
Aug 10, 2017, 3:27:58 AM8/10/17
to
On 10.08.2017 09:20, R.Wieser wrote:
> Hello All,
>
> -- First question:
>
> I've created, in Visual C++ 2008, a class like the below (to communicate
> with a non-VC++, dynamically loaded object).
>
> class ExternalObject {
> public:
> ExternalObject();
> ~ExternalObject(){};
> virtual void Destructor(ExternalObject* TheObject) = 0;
> virtual int Message(ExternalObject* TheObject, int* type, void* data) = 0;
> };
>
> As you can see each virtual method currently contains a manually provided
> "this" argument (TheObject), and needs to be called like this:
>
> MyObject->Message(MyObject, 0, "Hello World");
>
> My question is, how can I change the class in such a way that the "MyObject"
> 'this' argument is automatically added ?
Possibly you can modify the `ExternalObject` class directly, but
> Hello All,
>
> -- First question:
>
> I've created, in Visual C++ 2008, a class like the below (to communicate
> with a non-VC++, dynamically loaded object).
>
> class ExternalObject {
> public:
> ExternalObject();
> ~ExternalObject(){};
> virtual void Destructor(ExternalObject* TheObject) = 0;
> virtual int Message(ExternalObject* TheObject, int* type, void* data) = 0;
> };
>
> As you can see each virtual method currently contains a manually provided
> "this" argument (TheObject), and needs to be called like this:
>
> MyObject->Message(MyObject, 0, "Hello World");
>
> My question is, how can I change the class in such a way that the "MyObject"
> 'this' argument is automatically added ?
depending on what it does, maybe not. If so a general solution is create
a wrapper class W where each W instance holds a `this` pointer for the
external object.
> Or to be more precise, how can tell Visual C++ 2008 to transfer the 'this'
> *by argument* instead of by the ECX register.
> -- Second question:
>
> How do I do the reverse -- When an external object calls an object within
> the Visual C++ 2008 program have it accept a provided 'this' *argument* and
> make it available inside the called method by way of the 'this' keyword.
C++ object's member functions.
> Remark: The code, using the described class, already works. I just want to
> know if I can create a "cleaner" implementation of the above.
That's what almost every GUI framework does.
Cheers & hth.,
- Alf
Kalle Olavi Niemitalo
Aug 10, 2017, 3:53:35 AM8/10/17
to
"R.Wieser" <add...@not.available> writes:
> Or to be more precise, how can tell Visual C++ 2008 to transfer the 'this'
> *by argument* instead of by the ECX register.
I would try the __stdcall keyword.
> Or to be more precise, how can tell Visual C++ 2008 to transfer the 'this'
> *by argument* instead of by the ECX register.
https://msdn.microsoft.com/en-us/library/zxk0tw93(v=vs.90).aspx
R.Wieser
Aug 10, 2017, 4:58:53 AM8/10/17
to
Kalle,
> I would try the __stdcall keyword.
I've taken a peek at that MSDN page, but I do not see any reference
(directly or indirectly) to the 'this' argument ...
Regards,
Rudy Wieser
-- Origional message:
Kalle Olavi Niemitalo <k...@iki.fi> schreef in berichtnieuws
87lgmrr...@Niukka.kon.iki.fi...
> I would try the __stdcall keyword.
(directly or indirectly) to the 'this' argument ...
Regards,
Rudy Wieser
-- Origional message:
Kalle Olavi Niemitalo <k...@iki.fi> schreef in berichtnieuws
87lgmrr...@Niukka.kon.iki.fi...
R.Wieser
Aug 10, 2017, 4:58:53 AM8/10/17
to
Alf,
> If so a general solution is create a wrapper class W where each
> W instance holds a `this` pointer for the external object.
I don't think so, as that would make the mess bigger, not smaller. Also,
the 'this' argument is just a copy of the object-reference left of the "->".
In other words: *its already there*.
And yes, I could do it that way. Defining a number of static public
callable methods which than in turn call the, declared as private, actual
external methods.
But thats not what I'm currently looking for ...
> > Or to be more precise, how can tell Visual C++ 2008 to transfer
> > the 'this' *by argument* instead of by the ECX register.
>
> Don't.
Why ? I'm prepared to listen to a good reason for not doing it. Is there
one ?
Mind you, that class is there to define what the external object looks like
(and needs!), nothing else.
> Yes, you can.
>
> That's what almost every GUI framework does.
I do not quite understand. What has a *GUI* framework to do with what I
described ?
But if I understand you correctly, what I'm asking for is *not possible* in
Visual C++ 2008 ?
Heck, I thought it would be a simple request.
Regards,
Rudy Wieser
-- Origional message:
Alf P. Steinbach <alf.p.stein...@gmail.com> schreef in berichtnieuws
omh1lj$khf$1...@dont-email.me...
> If so a general solution is create a wrapper class W where each
> W instance holds a `this` pointer for the external object.
the 'this' argument is just a copy of the object-reference left of the "->".
In other words: *its already there*.
And yes, I could do it that way. Defining a number of static public
callable methods which than in turn call the, declared as private, actual
external methods.
But thats not what I'm currently looking for ...
> > Or to be more precise, how can tell Visual C++ 2008 to transfer
> > the 'this' *by argument* instead of by the ECX register.
>
> Don't.
one ?
Mind you, that class is there to define what the external object looks like
(and needs!), nothing else.
> Yes, you can.
>
> That's what almost every GUI framework does.
described ?
But if I understand you correctly, what I'm asking for is *not possible* in
Visual C++ 2008 ?
Heck, I thought it would be a simple request.
Regards,
Rudy Wieser
-- Origional message:
omh1lj$khf$1...@dont-email.me...
Kalle Olavi Niemitalo
Aug 10, 2017, 6:39:16 AM8/10/17
to
"R.Wieser" <add...@not.available> writes:
> I've taken a peek at that MSDN page, but I do not see any reference
> (directly or indirectly) to the 'this' argument ...
The MSDN page says __stdcall can be used for "non-static class
> I've taken a peek at that MSDN page, but I do not see any reference
> (directly or indirectly) to the 'this' argument ...
functions", so the 'this' argument has to be passed somewhere;
and __stdcall has no special rule for 'this', so 'this' will go
on the stack, which I understand is what you wanted. I don't
know whether 'this' will become the first or last argument,
though.
Compare __stdcall to the default __thiscall, which passes 'this'
in ECX and the rest on the stack.
Alf P. Steinbach
Aug 10, 2017, 6:46:55 AM8/10/17
to
Please don't top-post. Thank you.
Öö Tiib
Aug 10, 2017, 6:58:23 AM8/10/17
to
On Thursday, 10 August 2017 13:46:55 UTC+3, Alf P. Steinbach wrote:
> Please don't top-post. Thank you.
Is it some sort of joke? Can you elaborate, hopefully I'm not the only one
> Please don't top-post. Thank you.
who missed it. For me he clearly did not top-post.
Öö Tiib
Aug 10, 2017, 7:48:56 AM8/10/17
to
On Thursday, 10 August 2017 11:58:53 UTC+3, R.Wieser wrote:
> Alf,
asking how to make it bigger mess (more wrappers). We can make bigger
mess by doing a bigger mess.
> And yes, I could do it that way. Defining a number of static public
> callable methods which than in turn call the, declared as private, actual
> external methods.
>
> But thats not what I'm currently looking for ...
May be you need to provide real minimum example of what you want
together with example of what you have tried to achieve that. C++
is so anarchistic language that something close to any piece of text
is possible to make compile as C++. Especially C++2014 However your
example does not compile into any motivating examples.
>
> > > Or to be more precise, how can tell Visual C++ 2008 to transfer
> > > the 'this' *by argument* instead of by the ECX register.
> >
> > Don't.
>
> Why ? I'm prepared to listen to a good reason for not doing it. Is there
> one ?
>
> Mind you, that class is there to define what the external object looks like
> (and needs!), nothing else.
Since using __stdcall for every non-static member function can also make
the mess conceivably bigger not smaller.
>
> > Yes, you can.
> >
> > That's what almost every GUI framework does.
>
> I do not quite understand. What has a *GUI* framework to do with what I
> described ?
Every GUI framework tries (and usually quite successfully) to make itself
extendable being not too intrusive and requiring minimal boilerplate code.
Yes those also use macros, templates and wrappers but hide that in
library.
> But if I understand you correctly, what I'm asking for is *not possible* in
> Visual C++ 2008 ?
>
> Heck, I thought it would be a simple request.
How can be request about C++98 compiler simple today? For example I
start to forget its constraints and limitations and don't have it installed
anywhere to try either.
> Alf,
>
> Alf P. Steinbach <alf.p.stein...@gmail.com> schreef in berichtnieuws
> omh1lj$khf$1...@dont-email.me...
> Alf P. Steinbach <alf.p.stein...@gmail.com> schreef in berichtnieuws
> omh1lj$khf$1...@dont-email.me...
> > If so a general solution is create a wrapper class W where each
> > W instance holds a `this` pointer for the external object.
>
> I don't think so, as that would make the mess bigger, not smaller. Also,
> the 'this' argument is just a copy of the object-reference left of the "->".
> In other words: *its already there*.
It is because what you are trying looks like mess (wrappers) and you are
> > W instance holds a `this` pointer for the external object.
>
> I don't think so, as that would make the mess bigger, not smaller. Also,
> the 'this' argument is just a copy of the object-reference left of the "->".
> In other words: *its already there*.
asking how to make it bigger mess (more wrappers). We can make bigger
mess by doing a bigger mess.
> And yes, I could do it that way. Defining a number of static public
> callable methods which than in turn call the, declared as private, actual
> external methods.
>
> But thats not what I'm currently looking for ...
together with example of what you have tried to achieve that. C++
is so anarchistic language that something close to any piece of text
is possible to make compile as C++. Especially C++2014 However your
example does not compile into any motivating examples.
>
> > > Or to be more precise, how can tell Visual C++ 2008 to transfer
> > > the 'this' *by argument* instead of by the ECX register.
> >
> > Don't.
>
> Why ? I'm prepared to listen to a good reason for not doing it. Is there
> one ?
>
> Mind you, that class is there to define what the external object looks like
> (and needs!), nothing else.
the mess conceivably bigger not smaller.
>
> > Yes, you can.
> >
> > That's what almost every GUI framework does.
>
> I do not quite understand. What has a *GUI* framework to do with what I
> described ?
extendable being not too intrusive and requiring minimal boilerplate code.
Yes those also use macros, templates and wrappers but hide that in
library.
> But if I understand you correctly, what I'm asking for is *not possible* in
> Visual C++ 2008 ?
>
> Heck, I thought it would be a simple request.
start to forget its constraints and limitations and don't have it installed
anywhere to try either.
R.Wieser
Aug 10, 2017, 8:03:23 AM8/10/17
to
Kalle,
> so the 'this' argument has to be passed somewhere;
> and __stdcall has no special rule for 'this', so 'this' will
> go on the stack
I have no idea how you came to that "must go on the stack" conclusion. Why
would __stdcall even *know* of the existance of the "this" object-reference
? (and why isn't it mentioned <grumble>)
But! I just tried/tested it and it looks you're right. So, my thanks. :-)
One thing though: as far as I know stdcall differs from a c-calling
mechanism in that the former expects the called method to remove the
arguments from the stack, while the latter expects the caller to do it. Do
you know if there is a "the caller is responsible for the stack" version of
__stdcall (so nothing changes but for the 'this' handling) ?
Regards,
Rudy Wieser
-- Origional message:
Kalle Olavi Niemitalo <k...@iki.fi> schreef in berichtnieuws
87d183r...@Niukka.kon.iki.fi...
> so the 'this' argument has to be passed somewhere;
> and __stdcall has no special rule for 'this', so 'this' will
> go on the stack
would __stdcall even *know* of the existance of the "this" object-reference
? (and why isn't it mentioned <grumble>)
But! I just tried/tested it and it looks you're right. So, my thanks. :-)
One thing though: as far as I know stdcall differs from a c-calling
mechanism in that the former expects the called method to remove the
arguments from the stack, while the latter expects the caller to do it. Do
you know if there is a "the caller is responsible for the stack" version of
__stdcall (so nothing changes but for the 'this' handling) ?
Regards,
Rudy Wieser
-- Origional message:
Kalle Olavi Niemitalo <k...@iki.fi> schreef in berichtnieuws
R.Wieser
Aug 10, 2017, 8:12:04 AM8/10/17
to
Alf,
> Please don't top-post. Thank you.
I'm not going to argue this with you, but I suggest you look again. At my
posting style as wel as what "top posting" means.
And for the record: you can stop reading when you encounter the "--
Origional message:" line. That is what its there for. :-)
Regards,
Rudy Wieser
P.s.
And as always funny to see someone complain about something his own post is
guilty of itself ...
omhdae$l2t$1...@dont-email.me...
> Please don't top-post. Thank you.
posting style as wel as what "top posting" means.
And for the record: you can stop reading when you encounter the "--
Origional message:" line. That is what its there for. :-)
Regards,
Rudy Wieser
P.s.
And as always funny to see someone complain about something his own post is
guilty of itself ...
omhdae$l2t$1...@dont-email.me...
R.Wieser
Aug 10, 2017, 8:36:02 AM8/10/17
to
Öö Tiib,
> It is because what you are trying looks like mess (wrappers)
You have to explain that one to me I'm afraid. As far as I can see the
method that I use to call the extenal object while providing it a manual
"this" reference can't be unwrapped at all. Can you provide an
unwrapped/less messy calling method ? If so, please do!
> May be you need to provide real minimum example of what you
> want together with example of what you have tried to achieve that.
You already got it.
And forgive me for not providing more, *non relevant to the question*, code.
The last times I did that the replies only side-tracked (and downright
evaded!) the question, leaving me without an answer and rather frustrated.
I have no desire to repeat it.
What I asked is what I want/need to know. No more, no less. After that I
will (most likely!) test the sh*t outof it, just to see how-and-when it
breaks when I abuse it -- and by it learn its limitations. :-)
> Since using __stdcall for every non-static member function can
> also make the mess conceivably bigger not smaller.
Yes ...? How ? Mentioning that there could be pitfalls without pointing
them out is rather cruel, especially as I'm already walking the path ...
> > Heck, I thought it would be a simple request.
>
> How can be request about C++98 compiler simple today?
I have no idea. But Kalle's suggestion to add the "__stdcall" keyword
seems simple enough. :-)
Regards,
Rudy Wieser
-- Origional message:
Öö Tiib <oot...@hot.ee> schreef in berichtnieuws
830e50da-184e-4154...@googlegroups.com...
> It is because what you are trying looks like mess (wrappers)
method that I use to call the extenal object while providing it a manual
"this" reference can't be unwrapped at all. Can you provide an
unwrapped/less messy calling method ? If so, please do!
> May be you need to provide real minimum example of what you
> want together with example of what you have tried to achieve that.
And forgive me for not providing more, *non relevant to the question*, code.
The last times I did that the replies only side-tracked (and downright
evaded!) the question, leaving me without an answer and rather frustrated.
I have no desire to repeat it.
What I asked is what I want/need to know. No more, no less. After that I
will (most likely!) test the sh*t outof it, just to see how-and-when it
breaks when I abuse it -- and by it learn its limitations. :-)
> Since using __stdcall for every non-static member function can
> also make the mess conceivably bigger not smaller.
them out is rather cruel, especially as I'm already walking the path ...
> > Heck, I thought it would be a simple request.
>
> How can be request about C++98 compiler simple today?
seems simple enough. :-)
Regards,
Rudy Wieser
-- Origional message:
830e50da-184e-4154...@googlegroups.com...
David Brown
Aug 10, 2017, 8:41:22 AM8/10/17
to
On 10/08/17 14:12, R.Wieser wrote:
> Alf,
>
>> Please don't top-post. Thank you.
>
> I'm not going to argue this with you, but I suggest you look again. At my
> posting style as wel as what "top posting" means.
Your posting style is not top-posting - but neither is it standard
> Alf,
>
>> Please don't top-post. Thank you.
>
> I'm not going to argue this with you, but I suggest you look again. At my
> posting style as wel as what "top posting" means.
Usenet style.
>
> And for the record: you can stop reading when you encounter the "--
> Origional message:" line. That is what its there for. :-)
part is important) starts a signature in Usenet and email. The
signature should be short - typically 4 lines maximum - and is used for
things like the sender's name, addresses, favourite quotation, etc. A
compliant Usenet client will skip the signature when replying to the post.
I don't know whether it is your Usenet client (Outlook Express? I don't
think I have seen that for a decade or so) that mangles your posts, or
whether you have set this up by default. But your posts /are/ mangled
in a non-standard format, and it is not surprising that some people
express a dislike for it.
Whether you continue to use your non-standard style, or choose to fix
it, is of course up to you. But you may cause people who would
otherwise help you, to ignore you.
(I have never used MSVC, and don't do any C++ programming on Windows, so
I can't offer any help for your problem.)
>
> Regards,
> Rudy Wieser
>
> P.s.
> And as always funny to see someone complain about something his own post is
> guilty of itself ...
>
>
> -- Origional message:
> Alf P. Steinbach <alf.p.stein...@gmail.com> schreef in berichtnieuws
> omhdae$l2t$1...@dont-email.me...
>> Please don't top-post. Thank you.
>>
R.Wieser
Aug 10, 2017, 9:00:57 AM8/10/17
to
Kalle,
[I wrote]
explanation, and should have googeled *before* having posted it. :-|
It seems that Visual C++ 2008 already uses a stdcall method, and all that
the by you suggested "__stdcall" does is to override the 'this' behaviour
(correct me if I'm wrong here please).
Regards,
Rudy Wieser
[I wrote]
> One thing though: as far as I know stdcall differs from a c-calling
> mechanism in that the former expects the called method to remove
> the arguments from the stack, while the latter expects the caller to
> do it. Do you know if there is a "the caller is responsible for the
> stack" version of __stdcall (so nothing changes but for the 'this'
> handling) ?
No need to answer that one anymore. I should have quenched my urge for an
> mechanism in that the former expects the called method to remove
> the arguments from the stack, while the latter expects the caller to
> do it. Do you know if there is a "the caller is responsible for the
> stack" version of __stdcall (so nothing changes but for the 'this'
> handling) ?
explanation, and should have googeled *before* having posted it. :-|
It seems that Visual C++ 2008 already uses a stdcall method, and all that
the by you suggested "__stdcall" does is to override the 'this' behaviour
(correct me if I'm wrong here please).
Regards,
Rudy Wieser
R.Wieser
Aug 10, 2017, 9:42:10 AM8/10/17
to
David,
I wrote a full reply to you, only to realize that it would be rather
fruitless.
The only thing it would lead to would be a "discussion" like between a
catholic and a protestant arguing their believes, with them fully ignoring
they both worship the same god.
So, let anyone do whatever he pleases and reject whomever he wants over some
minor "your way is not my way" gripe, and I will talk with the ones that are
than left.
Actually, those "left overs" are most likely less inclined to try to force
me to follow whatever programming approach they favour, so thats a big win
for me. :-)
Regards,
Rudy Wieser
-- Origional message:
David Brown <david...@hesbynett.no> schreef in berichtnieuws
omhk19$99u$1...@dont-email.me...
I wrote a full reply to you, only to realize that it would be rather
fruitless.
The only thing it would lead to would be a "discussion" like between a
catholic and a protestant arguing their believes, with them fully ignoring
they both worship the same god.
So, let anyone do whatever he pleases and reject whomever he wants over some
minor "your way is not my way" gripe, and I will talk with the ones that are
than left.
Actually, those "left overs" are most likely less inclined to try to force
me to follow whatever programming approach they favour, so thats a big win
for me. :-)
Regards,
Rudy Wieser
-- Origional message:
omhk19$99u$1...@dont-email.me...
Öö Tiib
Aug 10, 2017, 10:43:13 AM8/10/17
to
On Thursday, 10 August 2017 15:36:02 UTC+3, R.Wieser wrote:
> Öö Tiib,
>
> > It is because what you are trying looks like mess (wrappers)
>
> You have to explain that one to me I'm afraid. As far as I can see the
> method that I use to call the extenal object while providing it a manual
> "this" reference can't be unwrapped at all. Can you provide an
> unwrapped/less messy calling method ? If so, please do!
Non-virtual destructor and virtual member function called "Destructor"
> Öö Tiib,
>
> > It is because what you are trying looks like mess (wrappers)
>
> You have to explain that one to me I'm afraid. As far as I can see the
> method that I use to call the extenal object while providing it a manual
> "this" reference can't be unwrapped at all. Can you provide an
> unwrapped/less messy calling method ? If so, please do!
seem like pointless over-engineering with wrappers. Isn't that mess?
Why there can't be just virtual destructor?
>
> > May be you need to provide real minimum example of what you
> > want together with example of what you have tried to achieve that.
>
> You already got it.
>
> And forgive me for not providing more, *non relevant to the question*, code.
> The last times I did that the replies only side-tracked (and downright
> evaded!) the question, leaving me without an answer and rather frustrated.
> I have no desire to repeat it.
>
> What I asked is what I want/need to know. No more, no less. After that I
> will (most likely!) test the sh*t outof it, just to see how-and-when it
> breaks when I abuse it -- and by it learn its limitations. :-)
can not help me any to understand what you want. ;-)
>
> > Since using __stdcall for every non-static member function can
> > also make the mess conceivably bigger not smaller.
>
> Yes ...? How ? Mentioning that there could be pitfalls without pointing
> them out is rather cruel, especially as I'm already walking the path ...
function is ugly and makes the whole thing harder to read, replacing it with
some macro say "STC" is confusing and you won't still get some benefits
that you might want (like be able to cast member function pointers into
ordinary function pointers) without making it fragile.
>
> > > Heck, I thought it would be a simple request.
> >
> > How can be request about C++98 compiler simple today?
>
> I have no idea. But Kalle's suggestion to add the "__stdcall" keyword
> seems simple enough. :-)
David Brown
Aug 10, 2017, 11:30:48 AM8/10/17
to
On 10/08/17 15:42, R.Wieser wrote:
> David,
>
> I wrote a full reply to you, only to realize that it would be rather
> fruitless.
I am not looking for a discussion - I am just giving you a statement of
> David,
>
> I wrote a full reply to you, only to realize that it would be rather
> fruitless.
facts about Usenet and standard Usenet posting conventions. You can
choose to follow them or not. But be very clear on this - there /is/ a
convention, the majority of regulars in this group and other technical
groups follow the convention, and there are knowledgeable and helpful
people who are less inclined to reply to people who flout that
convention. And while your posting style is not strictly "top posting",
it is an unconventional style that some (including me) find unpleasant.
Those are /facts/ - not opinions, or personal preferences. Google Usnet
posting style articles until you understand, if you do not accept my
word for it.
Whether any given person chooses to respond to you or not is, of course,
personal preference of those posters.
Whether or not you think your posting style is better than the one used
by almost everyone else, is of course /your/ opinion. Whether you think
it is so much "better" that you are happy to alienate potential helpful
responders, is also /your/ choice.
As I say, I can't give you any help on the subject of the thread in this
case - it is simply something I know almost nothing about. (Indeed, I
don't make many posts in this particular group.) Would I respond
helpfully in the future if you asked something that I /could/ answer? I
can't say at the moment. I am not the fussiest of Usenet users, but I
do find non-standard posting styles somewhat annoying.
R.Wieser
Aug 10, 2017, 1:28:16 PM8/10/17
to
嘱 Tiib,
> Non-virtual destructor and virtual member function called
> "Destructor" seem like pointless over-engineering with
> wrappers. Isn't that mess?
Nope. You think you are seeing, nonwithstanding me *obviously* still
being busy with it, a finished product.
> Why there can't be just virtual destructor?
Good question, and one I had already lined up to ask after my current,
'this' argument related, question was answered.
Yes, it was/is my intention to have the "~ExternalObject" destructor replace
the "Destructor" function. That I have both is because of that.
Actually, I thought that both the constructor as well as destructor where
mandated. I didn't directly realize that that does not seem to be the case
for a pure virtual (never instanciated) object. I do now. :-)
But you can read all about it in my next question/thread.
> Note "may be". Lack of information what you want to achieve
> with all that can not help me any to understand what you want. ;-)
Just assume that what I'm asking is what I "want". No more, no less. That
should be much easier than to try to second-guess what I *really* want, no ?
:-)
As I mentioned, I've encountered to many responders which went off on
tangents and left me rather frustrated as a result to want to give anyone
that chance again.
Just take yourself: Instead of concentrating on answering the question I
put forward you instead thought it was a good idea to make some
unsubstanciated "wrappers" and "bigger mess" claims (which both have
fizzeled out).
> I thought it was obvious. Text like "__stdcall" to every non-static
> member function is ugly and makes the whole thing harder to read
You're not serious there, are you ? I could say the exact same about the
"virtual" keyword (or any other), and it would be as silly.
But, do you have a better solution ? If not, are you sure you're not
just complaining because you can ?
So no, adding a single directive (to each of my virtual methods) is not what
I consider "a bigger mess", *especially not* when it does exactly what I
requested.
> ...and you won't still get some benefits that you might want
second-guess my intentions (regarding the code) maybe ? That would not be a
good idea you know. :-|
> If it does what you want then it is good. It was unclear from your post.
Was *what* unclear please ? And knowing what you now know I asked for how
could I have done better ?
Also, Kalle understood my question well enough to answer it with a single
line, even a single (key)word ...
And for the record, do you realize that, apart from the "Is it some sort of
joke?" remark in a post to Alf (which I should thank you for), you have only
given me grief ? Why ?
Regards,
Rudy Wieser
-- Origional message:
嘱 Tiib <oot...@hot.ee> schreef in berichtnieuws
c05c1d5e-f3fd-4b92...@googlegroups.com...
> Non-virtual destructor and virtual member function called
> "Destructor" seem like pointless over-engineering with
> wrappers. Isn't that mess?
being busy with it, a finished product.
> Why there can't be just virtual destructor?
'this' argument related, question was answered.
Yes, it was/is my intention to have the "~ExternalObject" destructor replace
the "Destructor" function. That I have both is because of that.
Actually, I thought that both the constructor as well as destructor where
mandated. I didn't directly realize that that does not seem to be the case
for a pure virtual (never instanciated) object. I do now. :-)
But you can read all about it in my next question/thread.
> Note "may be". Lack of information what you want to achieve
> with all that can not help me any to understand what you want. ;-)
should be much easier than to try to second-guess what I *really* want, no ?
:-)
As I mentioned, I've encountered to many responders which went off on
tangents and left me rather frustrated as a result to want to give anyone
that chance again.
Just take yourself: Instead of concentrating on answering the question I
put forward you instead thought it was a good idea to make some
unsubstanciated "wrappers" and "bigger mess" claims (which both have
fizzeled out).
> I thought it was obvious. Text like "__stdcall" to every non-static
> member function is ugly and makes the whole thing harder to read
"virtual" keyword (or any other), and it would be as silly.
But, do you have a better solution ? If not, are you sure you're not
just complaining because you can ?
So no, adding a single directive (to each of my virtual methods) is not what
I consider "a bigger mess", *especially not* when it does exactly what I
requested.
> ...and you won't still get some benefits that you might want
> (like be able to cast member function pointers into ordinary
> function pointers) without making it fragile.
I have *no* idea what you are talking about there. Are you again trying to
> function pointers) without making it fragile.
second-guess my intentions (regarding the code) maybe ? That would not be a
good idea you know. :-|
> If it does what you want then it is good. It was unclear from your post.
could I have done better ?
Also, Kalle understood my question well enough to answer it with a single
line, even a single (key)word ...
And for the record, do you realize that, apart from the "Is it some sort of
joke?" remark in a post to Alf (which I should thank you for), you have only
given me grief ? Why ?
Regards,
Rudy Wieser
-- Origional message:
c05c1d5e-f3fd-4b92...@googlegroups.com...
On Thursday, 10 August 2017 15:36:02 UTC+3, R.Wieser wrote:
> 嘱 Tiib,
Scott Lurndal
Aug 10, 2017, 1:39:47 PM8/10/17
to
"R.Wieser" <add...@not.available> writes:
>
>As I mentioned, I've encountered to many responders which went off on
>tangents and left me rather frustrated as a result to want to give anyone
>that chance again.
Ask for free advice, and you get what you pay for.
>
>As I mentioned, I've encountered to many responders which went off on
>tangents and left me rather frustrated as a result to want to give anyone
>that chance again.
And please, please, use the canonical Usenet posting style with
correct attributions.
R.Wieser
Aug 10, 2017, 2:03:51 PM8/10/17
to
David,
> I am not looking for a discussion -
Good. Neither am I.
Regards,
Rudy Wieser
-- Origional message:
David Brown <david...@hesbynett.no> schreef in berichtnieuws
omhtun$9gk$1...@dont-email.me...
> I am not looking for a discussion -
Regards,
Rudy Wieser
-- Origional message:
David Brown <david...@hesbynett.no> schreef in berichtnieuws
R.Wieser
Aug 10, 2017, 2:28:57 PM8/10/17
to
Scott,
> Ask for free advice, and you get what you pay for.
If only!
I do not mind getting *no* answers, its the "you asked something, now we
have the right to reply with *anything*, no matter how unrelated" that
mostly gets to me.
> And please, please, use the canonical Usenet posting
> style with correct attributions.
Which one are you, the catholic or the protestant ? :-(
I'm here to talk shop about some (V)C++ programming, not to listen to a few
blown-up egos trying to assert themselves. Deal with other peoples
different interpretations of the Usenet "rules" (Yes, I've read them). Or
don't. Not really my problem.
Regards,
Rudy Wieser
-- Origional message:
Scott Lurndal <sc...@slp53.sl.home> schreef in berichtnieuws
jT0jB.352230$AG1.2...@fx42.iad...
> Ask for free advice, and you get what you pay for.
I do not mind getting *no* answers, its the "you asked something, now we
have the right to reply with *anything*, no matter how unrelated" that
mostly gets to me.
> And please, please, use the canonical Usenet posting
> style with correct attributions.
I'm here to talk shop about some (V)C++ programming, not to listen to a few
blown-up egos trying to assert themselves. Deal with other peoples
different interpretations of the Usenet "rules" (Yes, I've read them). Or
don't. Not really my problem.
Regards,
Rudy Wieser
-- Origional message:
jT0jB.352230$AG1.2...@fx42.iad...
Ian Collins
Aug 11, 2017, 4:42:29 AM8/11/17
to
On 08/11/17 12:12 AM, R.Wieser wrote:
> Alf,
>
>> Please don't top-post. Thank you.
>
> I'm not going to argue this with you, but I suggest you look again. At my
> posting style as wel as what "top posting" means.
Your "posting style" is a good shortcut to kill files...
> Alf,
>
>> Please don't top-post. Thank you.
>
> I'm not going to argue this with you, but I suggest you look again. At my
> posting style as wel as what "top posting" means.
If you come here looking for help, follow the rules.
--
Ian
R.Wieser
Aug 11, 2017, 7:30:47 AM8/11/17
to
Ian,
> Your "posting style" is a good shortcut to kill files...
Its your perogative to choose whom you want to answer to, for whatever
reason. I can only hope you use it and get outof my hair.
Regards,
Rudy Wieser
-- Origional message:
Ian Collins <ian-...@hotmail.com> schreef in berichtnieuws
ev58v4...@mid.individual.net...
> Your "posting style" is a good shortcut to kill files...
reason. I can only hope you use it and get outof my hair.
Regards,
Rudy Wieser
-- Origional message:
ev58v4...@mid.individual.net...
0 new messages