Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Visual C++ 2008 - Using a pure virtual destructor. Any side effects I should be aware of ?
123 views
Skip to first unread message
R.Wieser
Aug 10, 2017, 2:03:00 PM8/10/17
to
Hello all,
This is sort of a of continuation of my previous question, as it regards the
same object.
I would like to use a virtual destructor for a pure virtual class (no code
in the vc++ program), but have no idea about the/its side-effects.
Like who is responsible for freeing the objects memory in case a virtual
destructor is executed.
The reason I'm asking is because in my case the external object releases its
own memory, and having the vc++ program try to do it again would probably
not end well ...
The same goes for the "delete(object)" command. I assume it its, apart
from zeroing-the object variable after the method call returns, fully
equivalent to "object->~object();", but am not at all sure of it.
I have googled, but I only seem to be able to find pages talking about
derived classes, which is most certainly not how I'm using it.
So, in the case of a virtual destructor, who is responsible for/does the
releasing of the objects allocated memory ? And are there other (side)
effects I should be aware of ?
Regards,
Rudy Wieser
This is sort of a of continuation of my previous question, as it regards the
same object.
I would like to use a virtual destructor for a pure virtual class (no code
in the vc++ program), but have no idea about the/its side-effects.
Like who is responsible for freeing the objects memory in case a virtual
destructor is executed.
The reason I'm asking is because in my case the external object releases its
own memory, and having the vc++ program try to do it again would probably
not end well ...
The same goes for the "delete(object)" command. I assume it its, apart
from zeroing-the object variable after the method call returns, fully
equivalent to "object->~object();", but am not at all sure of it.
I have googled, but I only seem to be able to find pages talking about
derived classes, which is most certainly not how I'm using it.
So, in the case of a virtual destructor, who is responsible for/does the
releasing of the objects allocated memory ? And are there other (side)
effects I should be aware of ?
Regards,
Rudy Wieser
Mr Flibble
Aug 10, 2017, 2:04:33 PM8/10/17
to
On 10/08/2017 19:02, R.Wieser wrote:
> Hello all,
>
> This is sort of a of continuation of my previous question, as it regards the
> same object.
Why are you using VC++2008? VS2015 is fine and it is free.
> Hello all,
>
> This is sort of a of continuation of my previous question, as it regards the
> same object.
/Flibble
Scott Lurndal
Aug 10, 2017, 2:14:50 PM8/10/17
to
"R.Wieser" <add...@not.available> writes:
>Hello all,
>
>This is sort of a of continuation of my previous question, as it regards the
>same object.
>
>I would like to use a virtual destructor for a pure virtual class (no code
>in the vc++ program), but have no idea about the/its side-effects.
>
>Like who is responsible for freeing the objects memory in case a virtual
>destructor is executed.
The 'delete' verb in C++ will (if not overloaded), first call any destructor(s)
>Hello all,
>
>This is sort of a of continuation of my previous question, as it regards the
>same object.
>
>I would like to use a virtual destructor for a pure virtual class (no code
>in the vc++ program), but have no idea about the/its side-effects.
>
>Like who is responsible for freeing the objects memory in case a virtual
>destructor is executed.
for the object, then release the storage of the object back to the storage
pool/heap.
One cannot delete an abstract class (since one cannot instantiate it), so
the destructor will never be called and no memory will be free'd.
R.Wieser
Aug 10, 2017, 3:51:37 PM8/10/17
to
Scott,
> The 'delete' verb in C++ will (if not overloaded), first call any
> destructor(s) for the object, then release the storage of the
> object back to the storage pool/heap.
That was what I was afraid of. Its going to try to delete some allocated
memory that doesn't exist anymore (already free'd by the external object).
And thats apart from the problem that it has no idea *how* that memory was
allocated, so its possible it handles it wrongly too ...
> One cannot delete an abstract class (since one cannot instantiate it),
> so the destructor will never be called and no memory will be free'd.
Phew! I guess I should count my blessings there. No chance of
(c|t)rashing the VC++ program.
On the other hand, you *can* have a purely virtual destructor, but it
*can't* be executed by means normally ment to call it ? Thats rather odd.
I mean, if defining default destructor virtually does not bring any
benefits, why even do so / allow it ?
Yes, I'm not nice. I really try to think about what people tell me. And
than I'm to much of a "need to know" person to let common curtesy stop me
from expressing my doubts. Sorry.
And by the way, you're mistaken. I just declared the standard destructor
as "virtual __stdcall ~ExternalObject();" and used "delete(TheObject)", and
lo and behold, the designated code in the external plugin was called.
Alas, *without* a 'this' reference (the value 0x1 appeared in its place) as
the first argument (contrary to what the "__stdcall" does on other virtual
methods mind you). ECX was loaded with the correct 'this' reference though.
On the other hand, calling "delete(object)" on an object which does *not*
have a (virtual) destructor crashes the VC++ program ...
And aint I nice here though: not only am I replying, I even feed back the
knowledge I've gained. :-)
Regards,
Rudy Wieser
-- Origional message:
Scott Lurndal <sc...@slp53.sl.home> schreef in berichtnieuws
do1jB.118956$114....@fx15.iad...
> The 'delete' verb in C++ will (if not overloaded), first call any
> destructor(s) for the object, then release the storage of the
> object back to the storage pool/heap.
memory that doesn't exist anymore (already free'd by the external object).
And thats apart from the problem that it has no idea *how* that memory was
allocated, so its possible it handles it wrongly too ...
> One cannot delete an abstract class (since one cannot instantiate it),
> so the destructor will never be called and no memory will be free'd.
(c|t)rashing the VC++ program.
On the other hand, you *can* have a purely virtual destructor, but it
*can't* be executed by means normally ment to call it ? Thats rather odd.
I mean, if defining default destructor virtually does not bring any
benefits, why even do so / allow it ?
Yes, I'm not nice. I really try to think about what people tell me. And
than I'm to much of a "need to know" person to let common curtesy stop me
from expressing my doubts. Sorry.
And by the way, you're mistaken. I just declared the standard destructor
as "virtual __stdcall ~ExternalObject();" and used "delete(TheObject)", and
lo and behold, the designated code in the external plugin was called.
Alas, *without* a 'this' reference (the value 0x1 appeared in its place) as
the first argument (contrary to what the "__stdcall" does on other virtual
methods mind you). ECX was loaded with the correct 'this' reference though.
On the other hand, calling "delete(object)" on an object which does *not*
have a (virtual) destructor crashes the VC++ program ...
And aint I nice here though: not only am I replying, I even feed back the
knowledge I've gained. :-)
Regards,
Rudy Wieser
-- Origional message:
Scott Lurndal <sc...@slp53.sl.home> schreef in berichtnieuws
do1jB.118956$114....@fx15.iad...
Kalle Olavi Niemitalo
Aug 11, 2017, 2:56:41 AM8/11/17
to
"R.Wieser" <add...@not.available> writes:
> Alas, *without* a 'this' reference (the value 0x1 appeared in its place) as
> the first argument (contrary to what the "__stdcall" does on other virtual
> methods mind you). ECX was loaded with the correct 'this' reference though.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0722r0.htm
> Alas, *without* a 'this' reference (the value 0x1 appeared in its place) as
> the first argument (contrary to what the "__stdcall" does on other virtual
> methods mind you). ECX was loaded with the correct 'this' reference though.
mentions that the Microsoft ABI gives destructors a hidden parameter
that indicates whether the destructor itself should free the memory.
I have not found any documentation in MSDN Library for that.
R.Wieser
Aug 11, 2017, 5:40:32 AM8/11/17
to
Kalle,
> [snip link] mentions that the Microsoft ABI gives destructors a hidden
Although I was already quite sure it was infact a parameter I had no (real,
as opposed to some guessed) idea what it was used for.
I do still have a question about it though: any idea why the "__stdcall"
applied to the virtual destructor doesn't cause the 'this' reference to
appear as the first argument, and (maybe) how to fix that ? As it now is
I can't use the virtual destructor at all.
Regards,
Rudy Wieser
-- Origional message:
Kalle Olavi Niemitalo <k...@iki.fi> schreef in berichtnieuws
878tiqr...@Niukka.kon.iki.fi...
> [snip link] mentions that the Microsoft ABI gives destructors a hidden
> parameter that indicates whether the destructor itself should free the
> memory.
Thank you very much for that. :-)
> memory.
Although I was already quite sure it was infact a parameter I had no (real,
as opposed to some guessed) idea what it was used for.
I do still have a question about it though: any idea why the "__stdcall"
applied to the virtual destructor doesn't cause the 'this' reference to
appear as the first argument, and (maybe) how to fix that ? As it now is
I can't use the virtual destructor at all.
Regards,
Rudy Wieser
-- Origional message:
878tiqr...@Niukka.kon.iki.fi...
Kalle Olavi Niemitalo
Aug 11, 2017, 8:28:21 AM8/11/17
to
"R.Wieser" <add...@not.available> writes:
> any idea why the "__stdcall" applied to the virtual destructor
> doesn't cause the 'this' reference to appear as the first
> argument,
I don't know, but it might be for the sake of exceptions. If you
> any idea why the "__stdcall" applied to the virtual destructor
> doesn't cause the 'this' reference to appear as the first
> argument,
throw an instance of that class and catch it using 'catch (...)'
without rethrowing, then the catch site has to call the
destructor but the compiler does not know which type of exception
it is, so the call has to be done via some kind of function
pointer. That could then require every destructor to use the
same calling convention, unless the compiler generates wrappers.
> and (maybe) how to fix that ?
If you describe why you are trying to change the calling
conventions, perhaps someone can suggest an alternative solution.
(If you are trying to modify vtables at run time, I think
it'd be OK to insert an asm wrapper to deal with ECX, because
the program won't be portable anyway.)
R.Wieser
Aug 11, 2017, 11:42:30 AM8/11/17
to
Kalle,
> If you describe why you are trying to change the calling
> conventions,
I'm calling an external (to the VC++ program) object (stored in a
dynamically loaded DLL) which methods are based on the COM model, meaning
that the first argument is supposed to be a 'this' reference.
The reason for that is that object might be written in a language other than
VC++, meaning that I can't even be certain it can access the processors
registers.
But don't worry. I would have been nice to use the build-in class
mechanisms (both the destructor as well as the constructor) as well as the
"delete(object)" command), but I can as easily do away with it and use the
shown "Destructor" method instead.
> because the program won't be portable anyway.
Because of the use of that "__stdcall" ? That would, even though it does
affect me personally, be unfortunate ...
And thanks for your help, I appreciate it.
Regards,
Rudy Wieser
-- Origional message:
Kalle Olavi Niemitalo <k...@iki.fi> schreef in berichtnieuws
874lteq...@Niukka.kon.iki.fi...
> If you describe why you are trying to change the calling
> conventions,
dynamically loaded DLL) which methods are based on the COM model, meaning
that the first argument is supposed to be a 'this' reference.
The reason for that is that object might be written in a language other than
VC++, meaning that I can't even be certain it can access the processors
registers.
But don't worry. I would have been nice to use the build-in class
mechanisms (both the destructor as well as the constructor) as well as the
"delete(object)" command), but I can as easily do away with it and use the
shown "Destructor" method instead.
> because the program won't be portable anyway.
affect me personally, be unfortunate ...
And thanks for your help, I appreciate it.
Regards,
Rudy Wieser
-- Origional message:
Kalle Olavi Niemitalo <k...@iki.fi> schreef in berichtnieuws
Richard Damon
Aug 11, 2017, 12:11:04 PM8/11/17
to
possible to use delete on a pointer to an abstract class, as that
pointer is allowed to point to an object of any class derived from that
abstract base class.
If that destructor is not virtual, then you have invoked undefined
behavior (if the destructor is not virtual, the apparent type must match
the actual run time type, and being abstract, that can't be).
The default code for a destructor is to invoke the destructors for all
objects declared in that class, and then invoke the destructors for the
base classes. If you implement code for the destructor, that code will
get run before that automatically generated code, there is no way to
suppress the destructors from being called (as far as I know).
Kalle Olavi Niemitalo
Aug 11, 2017, 3:46:25 PM8/11/17
to
"R.Wieser" <add...@not.available> writes:
>> because the program won't be portable anyway.
>
> Because of the use of that "__stdcall" ?
I meant, the C++ standard does not define the format or existence
>> because the program won't be portable anyway.
>
> Because of the use of that "__stdcall" ?
of vtables, so any manipulation of those cannot be portable.
Compilers that target Microsoft Windows pretty much have to match
the Microsoft ABI, though; otherwise they wouldn't be able to use
C++ class definitions generated by MIDL.
IIRC, neither __stdcall nor __cdecl will prevent arguments from
being passed in registers if you target AMD64 or IA64.
Manfred
Aug 11, 2017, 7:30:11 PM8/11/17
to
On 08/11/2017 05:42 PM, R.Wieser wrote:
> I'm calling an external (to the VC++ program) object (stored in a
> dynamically loaded DLL) which methods are based on the COM model, meaning
> that the first argument is supposed to be a 'this' reference.
I suspect that you are a bit misled about what you are trying to do -
> I'm calling an external (to the VC++ program) object (stored in a
> dynamically loaded DLL) which methods are based on the COM model, meaning
> that the first argument is supposed to be a 'this' reference.
just a suspect as you did not post any code sample.
I suggest you post some sample of both ends of the interface you are
trying to work with.
The COM model you mention has a number of layers, most of which are
Microsoft-specific, and your reference about the 'this' pointer (not
reference) looks like there is some misunderstanding going on here.
R.Wieser
Aug 12, 2017, 5:52:01 AM8/12/17
to
Kalle,
> I meant, the C++ standard does not define the format or
> existence of vtables,
Ah, yes. I found that rather odd: the mechanism by which virtual methods
interface with the actual class do not seem to be described/defined.
But even as that is so, the mechanism is proven to work on both windows as
well as Linux (where the programs external object is placed in an .so file),
and has been doing so for at least the last decade.
So the VTable mechanism (even if not named as such) is not quite as unstable
(prone to changes for whatever reason at whatever time) as it might appear
at first glance ... :-)
But yes, that concern is still lingering in the back of my mind. Thanks
for reminding me. :-( :-)
Regards,
Rudy Wieser
-- Origional message:
Kalle Olavi Niemitalo <k...@iki.fi> schreef in berichtnieuws
87zib5q...@Niukka.kon.iki.fi...
> I meant, the C++ standard does not define the format or
> existence of vtables,
interface with the actual class do not seem to be described/defined.
But even as that is so, the mechanism is proven to work on both windows as
well as Linux (where the programs external object is placed in an .so file),
and has been doing so for at least the last decade.
So the VTable mechanism (even if not named as such) is not quite as unstable
(prone to changes for whatever reason at whatever time) as it might appear
at first glance ... :-)
But yes, that concern is still lingering in the back of my mind. Thanks
for reminding me. :-( :-)
Regards,
Rudy Wieser
-- Origional message:
Kalle Olavi Niemitalo <k...@iki.fi> schreef in berichtnieuws
R.Wieser
Aug 12, 2017, 6:32:32 AM8/12/17
to
Manfred,
> I suspect that you are a bit misled about what you are trying
> to do.
I'm listening, please continue.
But I don't think you quite understood the situation here: The mechanism
*already works*. I'm just trying to "neat it up" a bit.
My current thread is about if I can use destructor declared as pure virtual
to call the destructor method in the external object. As it turns out, I
can't use "__stdcall" when declaring the classes virtual destructor *, as it
does not cause the "this" reference/pointer to be transferred as the first
argument.
No problem though, I'm just keep using what I already got. :-)
*actualy I can, it just doesn't do anything there. :-(
> I suggest you post some sample of both ends of the interface
> you are trying to work with.
You already got the vc++ end. Anything wrong with it ? How ?
> and your reference about the 'this' pointer (not reference) looks
> like there is some misunderstanding going on here.
Poteto, potato. I think you will be able to understand from the example I
posted in my initial message in the previous thread how I'm using it, and
thereby what I ment. If not ...
To be honest, I have no idea when you guys call it a reference, and when a
pointer. To me the two are the same.
https://stackoverflow.com/questions/57483/what-are-the-differences-between-a
-pointer-variable-and-a-reference-variable-in
Oh, nice. So in VC++ a reference is just a special, limited kind of
pointer. I guess I ment reference than.
Regards,
Rudy Wieser
-- Origional message:
Manfred <inv...@invalid.add> schreef in berichtnieuws
omlelm$g80$1...@gioia.aioe.org...
> I suspect that you are a bit misled about what you are trying
I'm listening, please continue.
But I don't think you quite understood the situation here: The mechanism
*already works*. I'm just trying to "neat it up" a bit.
My current thread is about if I can use destructor declared as pure virtual
to call the destructor method in the external object. As it turns out, I
can't use "__stdcall" when declaring the classes virtual destructor *, as it
does not cause the "this" reference/pointer to be transferred as the first
argument.
No problem though, I'm just keep using what I already got. :-)
*actualy I can, it just doesn't do anything there. :-(
> I suggest you post some sample of both ends of the interface
> you are trying to work with.
> and your reference about the 'this' pointer (not reference) looks
> like there is some misunderstanding going on here.
posted in my initial message in the previous thread how I'm using it, and
thereby what I ment. If not ...
To be honest, I have no idea when you guys call it a reference, and when a
pointer. To me the two are the same.
https://stackoverflow.com/questions/57483/what-are-the-differences-between-a
-pointer-variable-and-a-reference-variable-in
Oh, nice. So in VC++ a reference is just a special, limited kind of
pointer. I guess I ment reference than.
Regards,
Rudy Wieser
-- Origional message:
omlelm$g80$1...@gioia.aioe.org...
Manfred
Aug 12, 2017, 8:23:31 AM8/12/17
to
On 08/12/2017 12:32 PM, R.Wieser wrote:
> Manfred,
>
>> I suspect that you are a bit misled about what you are trying
>> to do.
>
> I'm listening, please continue.
It looks as if you are trying to coerce two different C++ runtime
> Manfred,
>
>> I suspect that you are a bit misled about what you are trying
>> to do.
>
> I'm listening, please continue.
implementations in the same process space - which would be trouble (it
is undefined behaviour at best).
>
> But I don't think you quite understood the situation here: The mechanism
> *already works*. I'm just trying to "neat it up" a bit.
Based on the information provided, both can be the case.
>
> My current thread is about if I can use destructor declared as pure virtual
> to call the destructor method in the external object. As it turns out, I
> can't use "__stdcall" when declaring the classes virtual destructor *, as it
> does not cause the "this" reference/pointer to be transferred as the first
> argument.
> No problem though, I'm just keep using what I already got. :-)
>
> *actualy I can, it just doesn't do anything there. :-(
calling its destructor, which could also be trouble.
>
>> I suggest you post some sample of both ends of the interface
>> you are trying to work with.
>
> You already got the vc++ end. Anything wrong with it ? How ?
both ends, what is the C++ runtime implementation on both ends, and what
more about the ABI.
>
>> and your reference about the 'this' pointer (not reference) looks
>> like there is some misunderstanding going on here.
>
> Poteto, potato. I think you will be able to understand from the example I
> posted in my initial message in the previous thread how I'm using it, and
> thereby what I ment. If not ...
the C++ implementation, according to the rules dictated by the ABI.
Instead of talking about ECX register and the like, you should make
clear what is the ABI specified by your implementation (which must be
the same on both ends, by the way)
>
> To be honest, I have no idea when you guys call it a reference, and when a
> pointer. To me the two are the same.
>
> https://stackoverflow.com/questions/57483/what-are-the-differences-between-a
> -pointer-variable-and-a-reference-variable-in
>
> Oh, nice. So in VC++ a reference is just a special, limited kind of
> pointer. I guess I ment reference than.
>
> Regards,
> Rudy Wieser
>
R.Wieser
Aug 13, 2017, 2:55:11 AM8/13/17
to
Manfred
> It looks as if you are trying to coerce two different C++
> runtime implementations in the same process space
Uhmmm. Not quite, but somewhat ?
[Quote=me]
than VC++*, meaning that I can't even be certain it can access the
processors registers.
[/Quote]
> which would be trouble (it is undefined behaviour at best).
If you know a better (and ofcourse defined by the language) way to call to
an external object (by way of a pointer table) I'm willing (understatement)
to listen.
> The question is if it works by coincidence or because it is correct.
:-) If, as Kalle, mentions it, the vtable structure has never been defined
the conclusion is rather simple: its by sheer coincidence -- even though the
code itself is (functions) correct (yeah, I know thats a bit of a
contradiction).
On the other hand, A vtable is a simple list of pointers, and does not
really seem prone to a(ny) sudden changes.
> It is not clear if you are trying to destroy an object by explicitly
> calling its destructor, which could also be trouble.
Please re-ead the initial post of this thread. That is what this thread is
all about. Can I do it (call the, as virtual declared, destructor and
access an external object) ? What "gotyas" do I need to be aware of ?
But as it turns out vc++ does not allow me to do so, as it refuses, even for
a pure virtual destructor, to deliver the 'this' reference as the first
argument, so using it is already off the table.
> > You already got the vc++ end. Anything wrong with it ? How ?
>
> It depends on what is on the other end,
Than you have a *big* problem on your hands, as I *can't say* what is on the
other end.
As mentioned, it might be written in vc++, but even than it might be from
fully different compiler version. It might also be written in delphi,
pascal, vbasic or any other language. In short, *I'm* (pretty-much)
defining the ABI.
Ofcourse, I've already created an ABI. But if you have a good reason to
change the vc++ side (and reference to how it *should* be done!) than again,
I'm willing to listen.
> It's not poteto potato. The 'this' pointer (not reference) is passed
> by the C++ implementation,
So when I use it to refer to a classes method ("MyObject->Destructor") its
called a reference, but when I provide it as an argument
("->Destructor(MyObject)") / its provided (implicitily) its suddenly a
pointer ? Yeah, that really makes talking about it so much easier. :-(
> you should make clear what is the ABI specified by your implementation
I already did. Several times. Starting with the example call posted in
the initial message of my previous thread and repeated thruout both the
threads
As a reference, see the first paragraph in my first quote in this message.
How many more times do I need to repeat that requirement ? :-(
> > I guess I ment reference than.
>
> I guess you guessed wrong...
Now *thats* helpfull. Not. :-(
Regards,
Rudy Wieser
-- Origional message:
Manfred <non...@invalid.add> schreef in berichtnieuws
ommrvc$cis$1...@gioia.aioe.org...
> It looks as if you are trying to coerce two different C++
> runtime implementations in the same process space
[Quote=me]
I'm calling an external (to the VC++ program) object (stored in a
dynamically loaded DLL) which methods are based on the COM model, meaning
that the first argument is supposed to be a 'this' reference.
The reason for that is *that object might be written in a language other
dynamically loaded DLL) which methods are based on the COM model, meaning
that the first argument is supposed to be a 'this' reference.
than VC++*, meaning that I can't even be certain it can access the
processors registers.
[/Quote]
> which would be trouble (it is undefined behaviour at best).
an external object (by way of a pointer table) I'm willing (understatement)
to listen.
> The question is if it works by coincidence or because it is correct.
the conclusion is rather simple: its by sheer coincidence -- even though the
code itself is (functions) correct (yeah, I know thats a bit of a
contradiction).
On the other hand, A vtable is a simple list of pointers, and does not
really seem prone to a(ny) sudden changes.
> It is not clear if you are trying to destroy an object by explicitly
> calling its destructor, which could also be trouble.
all about. Can I do it (call the, as virtual declared, destructor and
access an external object) ? What "gotyas" do I need to be aware of ?
But as it turns out vc++ does not allow me to do so, as it refuses, even for
a pure virtual destructor, to deliver the 'this' reference as the first
argument, so using it is already off the table.
> > You already got the vc++ end. Anything wrong with it ? How ?
>
> It depends on what is on the other end,
other end.
As mentioned, it might be written in vc++, but even than it might be from
fully different compiler version. It might also be written in delphi,
pascal, vbasic or any other language. In short, *I'm* (pretty-much)
defining the ABI.
Ofcourse, I've already created an ABI. But if you have a good reason to
change the vc++ side (and reference to how it *should* be done!) than again,
I'm willing to listen.
> It's not poteto potato. The 'this' pointer (not reference) is passed
> by the C++ implementation,
called a reference, but when I provide it as an argument
("->Destructor(MyObject)") / its provided (implicitily) its suddenly a
pointer ? Yeah, that really makes talking about it so much easier. :-(
> you should make clear what is the ABI specified by your implementation
the initial message of my previous thread and repeated thruout both the
threads
As a reference, see the first paragraph in my first quote in this message.
How many more times do I need to repeat that requirement ? :-(
> > I guess I ment reference than.
>
> I guess you guessed wrong...
Regards,
Rudy Wieser
-- Origional message:
ommrvc$cis$1...@gioia.aioe.org...
Kalle Olavi Niemitalo
Aug 13, 2017, 5:39:36 AM8/13/17
to
"R.Wieser" <add...@not.available> writes:
> On the other hand, A vtable is a simple list of pointers, and does not
> really seem prone to a(ny) sudden changes.
https://itanium-cxx-abi.github.io/cxx-abi/abi.html#vtable-components
> On the other hand, A vtable is a simple list of pointers, and does not
> really seem prone to a(ny) sudden changes.
says that the vtable may also contain offsets and a typeinfo pointer.
That's for the Itanium ABI though; I don't know how the Microsoft ABI
handles those.
If you want to be portable, then define a struct for the function
pointers, like MIDL generates for C.
R.Wieser
Aug 13, 2017, 6:57:54 AM8/13/17
to
Kalle,
> https://itanium-cxx-abi.github.io/cxx-abi/abi.html#vtable-components
> says that the vtable may also contain offsets and a typeinfo pointer.
> That's for the Itanium ABI though; I don't know how the Microsoft
> ABI handles those.
Yep, such a change would really throw a wrench in the machinery ...
> If you want to be portable, then define a struct for the function
> pointers, like MIDL generates for C.
:-) I was starting to think in the same direction. Alas, as my experience
with vc++ is rather minimal I will have to depend on my google-fu (read:
luck, as I currently do not even know what I should be looking for) turning
up an example I can take my lead from.
Oh well, it won't be the first time I will googeling a number of days for a
possible solution, and trying this-and-that example to see if it will fit.
Regards,
Rudy Wieser
-- Origional message:
> https://itanium-cxx-abi.github.io/cxx-abi/abi.html#vtable-components
> says that the vtable may also contain offsets and a typeinfo pointer.
> That's for the Itanium ABI though; I don't know how the Microsoft
> ABI handles those.
> If you want to be portable, then define a struct for the function
> pointers, like MIDL generates for C.
with vc++ is rather minimal I will have to depend on my google-fu (read:
luck, as I currently do not even know what I should be looking for) turning
up an example I can take my lead from.
Oh well, it won't be the first time I will googeling a number of days for a
possible solution, and trying this-and-that example to see if it will fit.
Regards,
Rudy Wieser
-- Origional message:
Kalle Olavi Niemitalo <k...@iki.fi> schreef in berichtnieuws
87bmnjp...@Niukka.kon.iki.fi...
Manfred
Aug 13, 2017, 7:39:32 AM8/13/17
to
On 08/13/2017 08:55 AM, R.Wieser wrote:
> Manfred
>
>> It looks as if you are trying to coerce two different C++
>> runtime implementations in the same process space
>
> Uhmmm. Not quite, but somewhat ?
In fact this seems to be the case, from your replies below.
> Manfred
>
>> It looks as if you are trying to coerce two different C++
>> runtime implementations in the same process space
>
> Uhmmm. Not quite, but somewhat ?
>
> [Quote=me]
> I'm calling an external (to the VC++ program) object (stored in a
> dynamically loaded DLL) which methods are based on the COM model, meaning
> that the first argument is supposed to be a 'this' reference.
>
> The reason for that is *that object might be written in a language other
> than VC++*, meaning that I can't even be certain it can access the
> processors registers.
> [/Quote]
>
>> which would be trouble (it is undefined behaviour at best).
>
> If you know a better (and ofcourse defined by the language) way to call to
> an external object (by way of a pointer table) I'm willing (understatement)
> to listen.
not define an ABI), and in fact you mentioning COM leads to the
consideration that COM is /neither/ part of the standard /nor/ portable,
it is instead a proprietary technology made by Microsoft that only works
with itself: a COM server and a COM client must both share the COM
framework.
It is worth recalling that there are very good reasons for which you
/cannot/ create a COM object with new, even if it is a C++ object, and
you must use CoCreateInstance instead. There are very good reasons as
well for which you /cannot/ destroy a COM object with delete, even if it
is a C++ object, and you /must/ call Release() instead (and the reasons
go beyond reference counting).
Note also that part of COM is definition of the ABI, and if you look
into the headers generated by MIDL you see that they are carefully
crafted to fit this ABI under the assumption that they are compiled with
a Microsoft compiler, and thus they are not portable.
>
>> The question is if it works by coincidence or because it is correct.
>
> :-) If, as Kalle, mentions it, the vtable structure has never been defined
> the conclusion is rather simple: its by sheer coincidence -- even though the
> code itself is (functions) correct (yeah, I know thats a bit of a
> contradiction).
>
> On the other hand, A vtable is a simple list of pointers, and does not
> really seem prone to a(ny) sudden changes.
>
>> It is not clear if you are trying to destroy an object by explicitly
>> calling its destructor, which could also be trouble.
>
> Please re-ead the initial post of this thread. That is what this thread is
> all about. Can I do it (call the, as virtual declared, destructor and
> access an external object) ? What "gotyas" do I need to be aware of ?
>
> But as it turns out vc++ does not allow me to do so, as it refuses, even for
> a pure virtual destructor, to deliver the 'this' reference as the first
> argument, so using it is already off the table.
>
>>> You already got the vc++ end. Anything wrong with it ? How ?
>>
>> It depends on what is on the other end,
>
> Than you have a *big* problem on your hands, as I *can't say* what is on the
> other end.
>
> As mentioned, it might be written in vc++, but even than it might be from
> fully different compiler version. It might also be written in delphi,
> pascal, vbasic or any other language.
I had a DLL that was compiled with VC++, exposing some C++ classes. I
was using it in a VC++ project, only a different version (say e.g. 2008
vs 2010, it could be anything, I don't remember which exactly).
It turned out that the runtime implementation of the 'new' and 'delete'
operators was different in the two versions, thus causing the program to
fail at runtime.
In short, *I'm* (pretty-much)
> defining the ABI.
>
> Ofcourse, I've already created an ABI. But if you have a good reason to
> change the vc++ side (and reference to how it *should* be done!) than again,
> I'm willing to listen.
your own if you don't know the one of the component you are trying to
connect to. If you have no idea of what's there, I guess it's too bad...
>
>> It's not poteto potato. The 'this' pointer (not reference) is passed
>> by the C++ implementation,
>
> So when I use it to refer to a classes method ("MyObject->Destructor") its
> called a reference, but when I provide it as an argument
> ("->Destructor(MyObject)") / its provided (implicitily) its suddenly a
> pointer ? Yeah, that really makes talking about it so much easier. :-(
>
>> you should make clear what is the ABI specified by your implementation
>
> I already did. Several times. Starting with the example call posted in
> the initial message of my previous thread and repeated thruout both the
> threads
> As a reference, see the first paragraph in my first quote in this message.
https://en.wikipedia.org/wiki/Application_binary_interface
>
> How many more times do I need to repeat that requirement ? :-(
>
>>> I guess I ment reference than.
>>
>> I guess you guessed wrong...
>
> Now *thats* helpfull. Not. :-(
pointers and references. It is up to you if you are willing to.
>
> Regards,
> Rudy Wieser
>
>
R.Wieser
Aug 14, 2017, 4:35:55 AM8/14/17
to
Manfred,
> > > It looks as if you are trying to coerce two different C++
> > > runtime implementations in the same process space
> >
> > Uhmmm. Not quite, but somewhat ?
>
> In fact this seems to be the case, from your replies below.
Your reading comprehension fails you I'm afraid.
[quote-of-quote]
that object might be written in A LANGUAGE OTHER THAN vc++"
[/quote]
(upper-casing mine)
As far as I can tell that seems to indicate that there is a chance that the
other part MIGHT be C++ too, but could easily be something else.
> I don't think there is a way defined by the language (the standard
> does not define an ABI),
Lol. You're barking up the wrong tree there. I do not, and have never
done so, ask for the language to deliver me an ABI, I'm trying to *find the
tools* the language has to create my own.
> It is worth recalling that there are very good reasons for which
> you /cannot/ create a COM object with new, even if it is a C++
> object,
Your reading comprehension fails you again.
I've never said I wanted to create a COM object (and in retrospect
mentioning VisualBasic as a language the external object could be written in
was a bit of a mistake on my side), I said I wanted the *METHOD CALLS* to be
COM alike. With me *specifically* describing that that, *from my very
first post on*, ment I wanted the 'this' reference/pointer/whatever
delivered (as in, to the external object) as the first argument.
> > Than you have a *big* problem on your hands, as I *can't say*
> > what is on the other end.
>
> *I* don't have any problem, it looks like you have.
I don't have a problem, as I know exactly what I'm after. Heck, I even
penned it down a number of times now !
The only problem I have is that I do not know enough of the VC++ language to
pick out the right commands for it. And thats where *you* where supposed to
come in.
The *problem* is that although you have offered yourself to help, you are
seemingly either incapable or even not really willing to do so.
And before you now blow your top, let me explain: Besides complaining
about how my choices are all wrong and repeatedly requesting (demanding?) my
code while ignoring what you already got, you have done *zero* in regard to
pointing me to possible better solutions.
And *thats* (pointers) is all I'm here for. With those I can investigate
what they do and in the end *make my own choice* to which one I want to
implement.
I'm *definitily not* here for you to dictate what I need to write.
So far I have indulged you in the hope you would come to some conclusion I
could use. But as you seem to be incapable/unwilling of doing so, I'm going
to end our conversation here.
Someone earier in this thread said "you get what you pay for". Boy, did I
get my full pound! :-((
Regards,
Rudy Wieser
P.s
Compare your method of helping with the way Kalle does it. I think you can
learn a lot from that/him.
-- Origional mesage:
> > > It looks as if you are trying to coerce two different C++
> > > runtime implementations in the same process space
> >
> > Uhmmm. Not quite, but somewhat ?
>
> In fact this seems to be the case, from your replies below.
[quote-of-quote]
that object might be written in A LANGUAGE OTHER THAN vc++"
[/quote]
(upper-casing mine)
As far as I can tell that seems to indicate that there is a chance that the
other part MIGHT be C++ too, but could easily be something else.
> I don't think there is a way defined by the language (the standard
> does not define an ABI),
done so, ask for the language to deliver me an ABI, I'm trying to *find the
tools* the language has to create my own.
> It is worth recalling that there are very good reasons for which
> you /cannot/ create a COM object with new, even if it is a C++
> object,
I've never said I wanted to create a COM object (and in retrospect
mentioning VisualBasic as a language the external object could be written in
was a bit of a mistake on my side), I said I wanted the *METHOD CALLS* to be
COM alike. With me *specifically* describing that that, *from my very
first post on*, ment I wanted the 'this' reference/pointer/whatever
delivered (as in, to the external object) as the first argument.
> > Than you have a *big* problem on your hands, as I *can't say*
> > what is on the other end.
>
> *I* don't have any problem, it looks like you have.
penned it down a number of times now !
The only problem I have is that I do not know enough of the VC++ language to
pick out the right commands for it. And thats where *you* where supposed to
come in.
The *problem* is that although you have offered yourself to help, you are
seemingly either incapable or even not really willing to do so.
And before you now blow your top, let me explain: Besides complaining
about how my choices are all wrong and repeatedly requesting (demanding?) my
code while ignoring what you already got, you have done *zero* in regard to
pointing me to possible better solutions.
And *thats* (pointers) is all I'm here for. With those I can investigate
what they do and in the end *make my own choice* to which one I want to
implement.
I'm *definitily not* here for you to dictate what I need to write.
So far I have indulged you in the hope you would come to some conclusion I
could use. But as you seem to be incapable/unwilling of doing so, I'm going
to end our conversation here.
Someone earier in this thread said "you get what you pay for". Boy, did I
get my full pound! :-((
Regards,
Rudy Wieser
P.s
Compare your method of helping with the way Kalle does it. I think you can
learn a lot from that/him.
-- Origional mesage:
Manfred <inv...@invalid.add> schreef in berichtnieuws
ompdou$44e$1...@gioia.aioe.org...
Manfred
Aug 14, 2017, 12:02:50 PM8/14/17
to
On 8/14/2017 10:36 AM, R.Wieser wrote:
> Manfred,
>
<barking snipped>
> Manfred,
>
<barking snipped>
>
> I'm *definitily not* here for you to dictate what I need to write.
>
> So far I have indulged you in the hope you would come to some conclusion I
> could use. But as you seem to be incapable/unwilling of doing so, I'm going
> to end our conversation here.
Fine with me, you managed to land into my killfile.
> I'm *definitily not* here for you to dictate what I need to write.
>
> So far I have indulged you in the hope you would come to some conclusion I
> could use. But as you seem to be incapable/unwilling of doing so, I'm going
> to end our conversation here.
R.Wieser
Aug 15, 2017, 2:46:58 AM8/15/17
to
Manfred,
> Fine with me, you managed to land into my killfile.
You do not seem to be willing to actually help me, so, as I posted earlier,
thats fine by me. Your kind of "help" sucks me dry, leaving me *very* tired
indeed. :-(
I still hope you will take a peek at how Kalle did/does it though.
Regards,
Rudy Wieser
Manfred <non...@invalid.add> schreef in berichtnieuws
omshik$r8n$1...@gioia.aioe.org...
> Fine with me, you managed to land into my killfile.
thats fine by me. Your kind of "help" sucks me dry, leaving me *very* tired
indeed. :-(
I still hope you will take a peek at how Kalle did/does it though.
Regards,
Rudy Wieser
Manfred <non...@invalid.add> schreef in berichtnieuws
Alf P. Steinbach
Aug 15, 2017, 3:36:00 AM8/15/17
to
On 8/15/2017 8:47 AM, R.Wieser wrote:
> Manfred,
>
>> Fine with me, you managed to land into my killfile.
>
> You do not seem to [...]
> Manfred,
>
>> Fine with me, you managed to land into my killfile.
>
The person you're replying to doesn't see your message.
You can meaningfully address others who may be following the exchange,
but it's mostly meaningless to address a person who can't see your
posting. It COULD conceivably happen that someone else would quote your
text in its entirety, but that's a very slim chance.
Also, please stop top-posting, or bottom-quoting (whatever). At one
time, like twenty years ago, my Usenet signature about top-posting made
it into a database FAQ, of all things. Thought I should mention it, that
it's not so smart to insist on knowing better than the old-timers.
---
Now, you've been pretty secretive about the external COM-like objects
that you're dealing with. There are three and half main contenders:
actual COM objects, Java JNI objects, XCOM objects, and possibly
homegrown game support objects. Regardless, you should use the tools for
the kind that you're dealing with, to generate C and C++ interfaces that
correspond exactly to the binary level layout, and use the documentation
for that kind to figure out lifetime management and so on – it differs
greatly, depending on the kind of object.
For COM and XCOM use the MIDL compiler. It takes an IDL interface
definition as input and generates C and C++ code.
Cheers!,
- Alf
Öö Tiib
Aug 15, 2017, 5:49:39 AM8/15/17
to
On Tuesday, 15 August 2017 10:36:00 UTC+3, Alf P. Steinbach wrote:
> On 8/15/2017 8:47 AM, R.Wieser wrote:
> > Manfred,
> >
> >> Fine with me, you managed to land into my killfile.
> >
> > You do not seem to [...]
>
> The person you're replying to doesn't see your message.
The person you're replying to has several times expressed that he
> On 8/15/2017 8:47 AM, R.Wieser wrote:
> > Manfred,
> >
> >> Fine with me, you managed to land into my killfile.
> >
> > You do not seem to [...]
>
> The person you're replying to doesn't see your message.
expects direct one (or may be two) sentence answers to questions that
he asks. Any other form of communication than that will give him
grief, suck him dry, stick in his hair, make him very tired and so on.
So why you want to see him suffer like that? :)
R.Wieser
Aug 15, 2017, 6:33:25 AM8/15/17
to
Alf,
> The person you're replying to doesn't see your message.
Do not confuse a promiss of doing something with actually doing it. :-)
Also, your reply to it makes sure he at least knows that it exists and even
gets the gist of it.
> Also, please stop top-posting, or bottom-quoting (whatever).
If I have to take your classification of my posting style as an example I'm
afraid you wouldn't recognise either even if it would spit you in the eyes
...
Can you make sense of what I'm saying ? Can you recognise whom I'm
responding to ? Can you recognise the (marked!) point where you really do
not need to continue reading anymore, as below it is aan integral copy of
the responded-to post ?
If so than stop complaining about someone not doing something exactly way
you prefer to see it. :-(
And yes, *you*. Do not confuse to be able to point to something someone has
written once as a right to force others to obey it. The word extremism is
not only applicable to religion (particulary including christianity) you
know. :-(
If you want to control how and what others may do than I suggest you set up
a moderated subforum (take CLAX86 for example). That way you can kick the
shit outof anyone not doing exactly what you want them to do. :-)
Also, why haven't you responded to my questions in my previous message to
you (GUI framework and other) ? If you want to be able to demand some kind
of behaviour from other people (in regard to some Usenet "rules" -- which,
with the absence of a policing body, can only be guidelines), than should
you than not be the first one to do so yourself (in regard to common
decency -- answering questions that directed to you in regard to comments
you made) ?
In short, when you're the pot you should definitily *not* be the one who
complains about the kettle being black. Right ? Right.
Furthermore, why do you think that repeating your stance while refusing to
even acknowledge a response to it the first time you posted it will gain you
any respect ? I've got news for you: It doesn't. Quite the reverse
actually.
Regards,
Rudy Wieser
-- Origional message:
Alf P. Steinbach <alf.p.stein...@gmail.com> schreef in berichtnieuws
omu80f$si6$1...@dont-email.me...
> The person you're replying to doesn't see your message.
Also, your reply to it makes sure he at least knows that it exists and even
gets the gist of it.
> Also, please stop top-posting, or bottom-quoting (whatever).
afraid you wouldn't recognise either even if it would spit you in the eyes
...
Can you make sense of what I'm saying ? Can you recognise whom I'm
responding to ? Can you recognise the (marked!) point where you really do
not need to continue reading anymore, as below it is aan integral copy of
the responded-to post ?
If so than stop complaining about someone not doing something exactly way
you prefer to see it. :-(
And yes, *you*. Do not confuse to be able to point to something someone has
written once as a right to force others to obey it. The word extremism is
not only applicable to religion (particulary including christianity) you
know. :-(
If you want to control how and what others may do than I suggest you set up
a moderated subforum (take CLAX86 for example). That way you can kick the
shit outof anyone not doing exactly what you want them to do. :-)
Also, why haven't you responded to my questions in my previous message to
you (GUI framework and other) ? If you want to be able to demand some kind
of behaviour from other people (in regard to some Usenet "rules" -- which,
with the absence of a policing body, can only be guidelines), than should
you than not be the first one to do so yourself (in regard to common
decency -- answering questions that directed to you in regard to comments
you made) ?
In short, when you're the pot you should definitily *not* be the one who
complains about the kettle being black. Right ? Right.
Furthermore, why do you think that repeating your stance while refusing to
even acknowledge a response to it the first time you posted it will gain you
any respect ? I've got news for you: It doesn't. Quite the reverse
actually.
Regards,
Rudy Wieser
-- Origional message:
omu80f$si6$1...@dont-email.me...
> On 8/15/2017 8:47 AM, R.Wieser wrote:
> > Manfred,
> >
> >> Fine with me, you managed to land into my killfile.
> >
> > You do not seem to [...]
>
> The person you're replying to doesn't see your message.
>
> You can meaningfully address others who may be following the exchange,
> but it's mostly meaningless to address a person who can't see your
> posting. It COULD conceivably happen that someone else would quote your
> text in its entirety, but that's a very slim chance.
>
> Also, please stop top-posting, or bottom-quoting (whatever). At one
> time, like twenty years ago, my Usenet signature about top-posting made
> it into a database FAQ, of all things. Thought I should mention it, that
> it's not so smart to insist on knowing better than the old-timers.
>
> ---
>
> Now, you've been pretty secretive about the external COM-like objects
> that you're dealing with. There are three and half main contenders:
> actual COM objects, Java JNI objects, XCOM objects, and possibly
> homegrown game support objects. Regardless, you should use the tools for
> the kind that you're dealing with, to generate C and C++ interfaces that
> correspond exactly to the binary level layout, and use the documentation
> for that kind to figure out lifetime management and so on - it differs
> > Manfred,
> >
> >> Fine with me, you managed to land into my killfile.
> >
> > You do not seem to [...]
>
> The person you're replying to doesn't see your message.
>
> You can meaningfully address others who may be following the exchange,
> but it's mostly meaningless to address a person who can't see your
> posting. It COULD conceivably happen that someone else would quote your
> text in its entirety, but that's a very slim chance.
>
> Also, please stop top-posting, or bottom-quoting (whatever). At one
> time, like twenty years ago, my Usenet signature about top-posting made
> it into a database FAQ, of all things. Thought I should mention it, that
> it's not so smart to insist on knowing better than the old-timers.
>
> ---
>
> Now, you've been pretty secretive about the external COM-like objects
> that you're dealing with. There are three and half main contenders:
> actual COM objects, Java JNI objects, XCOM objects, and possibly
> homegrown game support objects. Regardless, you should use the tools for
> the kind that you're dealing with, to generate C and C++ interfaces that
> correspond exactly to the binary level layout, and use the documentation
R.Wieser
Aug 15, 2017, 7:05:24 AM8/15/17
to
嘱,
> The person you're replying to has several times expressed
> that he expects direct one (or may be two) sentence answers
> to questions that he asks.
Not quite. I do not expect a single line per se, I will even allow the
people who actually *help* me to use multiple lines (how's that for
arrogance ? And yes, in case you did not understand, that was a joke)
But the comparision between multiple full-page posts not even giving an
indication of working to *anything*, let alone an answer to the question
(effectivily saying nothing but for continued complaints about not having
enough information) and on the other hand someone who understood the
question enough to respond with a single line that was spot on is ...
remarkable to say the least, don't you think ?
If even if you multiple-full-page-of-saying-nothing responders could meet
Kalle's method a quarter of the way I would have a *much* larger chance of
actually getting an answer. I mean, any chance larger than Zero can be
considered "much larger", can't it ? :-)
>Any other form of communication than that will give him
> grief, suck him dry, stick in his hair, make him very tired
> and so on.
Newsflash: A cow is an animal. But not all animals are cows
Do I have to spell it out for you, or do you think you understand without me
doing so ? Good.
Regards,
Rudy Wieser
-- Origional message:
嘱 Tiib <oot...@hot.ee> schreef in berichtnieuws
0ac6ad47-e227-4596...@googlegroups.com...
> The person you're replying to has several times expressed
> that he expects direct one (or may be two) sentence answers
> to questions that he asks.
people who actually *help* me to use multiple lines (how's that for
arrogance ? And yes, in case you did not understand, that was a joke)
But the comparision between multiple full-page posts not even giving an
indication of working to *anything*, let alone an answer to the question
(effectivily saying nothing but for continued complaints about not having
enough information) and on the other hand someone who understood the
question enough to respond with a single line that was spot on is ...
remarkable to say the least, don't you think ?
If even if you multiple-full-page-of-saying-nothing responders could meet
Kalle's method a quarter of the way I would have a *much* larger chance of
actually getting an answer. I mean, any chance larger than Zero can be
considered "much larger", can't it ? :-)
>Any other form of communication than that will give him
> grief, suck him dry, stick in his hair, make him very tired
> and so on.
Do I have to spell it out for you, or do you think you understand without me
doing so ? Good.
Regards,
Rudy Wieser
-- Origional message:
0ac6ad47-e227-4596...@googlegroups.com...
Öö Tiib
Aug 15, 2017, 9:03:07 AM8/15/17
to
On Tuesday, 15 August 2017 14:05:24 UTC+3, R.Wieser wrote:
> 嘱,
It wasn't written 嘱 (Chinese zhu') but Öö (two o's with diaeresis).
Whatever you use can't apparently parse unicode. Can you tell
what it is?
>
> > The person you're replying to has several times expressed
> > that he expects direct one (or may be two) sentence answers
> > to questions that he asks.
>
> Not quite. I do not expect a single line per se, I will even allow the
> people who actually *help* me to use multiple lines (how's that for
> arrogance ? And yes, in case you did not understand, that was a joke)
My whole reply to Alf to what you reply here was a joke. It had smiley
at end to indicate that. Why you erased it?
> 嘱,
It wasn't written 嘱 (Chinese zhu') but Öö (two o's with diaeresis).
Whatever you use can't apparently parse unicode. Can you tell
what it is?
>
> > The person you're replying to has several times expressed
> > that he expects direct one (or may be two) sentence answers
> > to questions that he asks.
>
> Not quite. I do not expect a single line per se, I will even allow the
> people who actually *help* me to use multiple lines (how's that for
> arrogance ? And yes, in case you did not understand, that was a joke)
at end to indicate that. Why you erased it?
David Brown
Aug 15, 2017, 10:30:55 AM8/15/17
to
On 15/08/17 15:02, Öö Tiib wrote:
> On Tuesday, 15 August 2017 14:05:24 UTC+3, R.Wieser wrote:
>> 嘱,
>
> It wasn't written 嘱 (Chinese zhu') but Öö (two o's with diaeresis).
> Whatever you use can't apparently parse unicode. Can you tell
> what it is?
He is using MS Outlook Express 5, from around 2000 if I am not mistaken.
> On Tuesday, 15 August 2017 14:05:24 UTC+3, R.Wieser wrote:
>> 嘱,
>
> It wasn't written 嘱 (Chinese zhu') but Öö (two o's with diaeresis).
> Whatever you use can't apparently parse unicode. Can you tell
> what it is?
This is long before MS accepted that there was anyone using anything
other than Windows and MS programs. Thus the encoding his messages use
is Windows-1251, not utf-8 like almost everyone else these days, and
because it is a Microsoft program from that era, the messages are not
marked with the encoding.
You are using Google Groups, which is an equally horrendous news client
(but bad in different ways). It appears unable to guess the correct
encoding, and assumes it is utf-8, resulting in messed up characters.
Ignoring the actual /content/ of Rudy's posts, which are a level of
arrogance and rudeness that I have rarely seen in newsgroups, the
letters of your name come through fine for me when read with
Thunderbird. It looks like the combination of two bad news clients is
needed for the problem.
R.Wieser
Aug 15, 2017, 12:12:55 PM8/15/17
to
嘱,
> It wasn't written ? (Chinese zhu') but 嘱 (two o's with diaeresis).
Yep. And that I copy-pasted those two-o's-with-diaeresis from one place in
the message to the top. No idea why your browser makes a mess of it ?
> My whole reply to Alf to what you reply here was a joke.
Sure it was. But at whos expense ?
> It had smiley at end to indicate that. Why you erased it?
Yeah, directly following a line directed at somebody, but definitily not me.
Nope, I think you knew very well who your jab was aimed at -- and are now
trying to make it sound as if it wasn't ment that way.
Besides, you already showed that you you have no problem with sucking stuff
outof your thumb, and than tried to play it off as if it was the plain
truth -- and than drop the whole matter when you got challenged in that
regard. Nope, you lost my belief in your honesty by doing that.
But don't worry about that, you can just blacklist me too and just ignore
being caught out. :-)
d896c131-7f50-4f27...@googlegroups.com...
> It wasn't written ? (Chinese zhu') but 嘱 (two o's with diaeresis).
Yep. And that I copy-pasted those two-o's-with-diaeresis from one place in
the message to the top. No idea why your browser makes a mess of it ?
> My whole reply to Alf to what you reply here was a joke.
> It had smiley at end to indicate that. Why you erased it?
Nope, I think you knew very well who your jab was aimed at -- and are now
trying to make it sound as if it wasn't ment that way.
Besides, you already showed that you you have no problem with sucking stuff
outof your thumb, and than tried to play it off as if it was the plain
truth -- and than drop the whole matter when you got challenged in that
regard. Nope, you lost my belief in your honesty by doing that.
But don't worry about that, you can just blacklist me too and just ignore
being caught out. :-)
d896c131-7f50-4f27...@googlegroups.com...
On Tuesday, 15 August 2017 14:05:24 UTC+3, R.Wieser wrote:
> ?,
Öö Tiib
Aug 15, 2017, 3:02:25 PM8/15/17
to
On Tuesday, 15 August 2017 19:12:55 UTC+3, R.Wieser wrote:
> Öö,
>
> > It wasn't written 嘱? (Chinese zhu') but Öö (two o's with diaeresis).
>
> > My whole reply to Alf to what you reply here was a joke.
>
> Sure it was. But at whos expense ?
You of course provide the whole comedy here.
>
> > It had smiley at end to indicate that. Why you erased it?
>
> Yeah, directly following a line directed at somebody, but definitily not me.
>
> Nope, I think you knew very well who your jab was aimed at -- and are now
> trying to make it sound as if it wasn't ment that way.
Why? It was sure meant that way. I did not try to hide it.
Are you joking again? I may not laugh at you? :D
>
> Besides, you already showed that you you have no problem with sucking stuff
> outof your thumb, and than tried to play it off as if it was the plain
> truth -- and than drop the whole matter when you got challenged in that
> regard. Nope, you lost my belief in your honesty by doing that.
>
> But don't worry about that, you can just blacklist me too and just ignore
> being caught out. :-)
Why should I blacklist anyone? If reading them is too boring then I can
always do something else.
>
> Regards,
> Rudy Wieser
>
>
> -- Origional message:
> Öö Tiib <oot...@hot.ee> schreef in berichtnieuws
> Öö,
>
> > It wasn't written 嘱? (Chinese zhu') but Öö (two o's with diaeresis).
>
> Yep. And that I copy-pasted those two-o's-with-diaeresis from one place in
> the message to the top. No idea why your browser makes a mess of it ?
Oh, sorry, David Brown explained it why it happens.
> Yep. And that I copy-pasted those two-o's-with-diaeresis from one place in
> the message to the top. No idea why your browser makes a mess of it ?
>
> > My whole reply to Alf to what you reply here was a joke.
>
> Sure it was. But at whos expense ?
>
> > It had smiley at end to indicate that. Why you erased it?
>
> Yeah, directly following a line directed at somebody, but definitily not me.
>
> Nope, I think you knew very well who your jab was aimed at -- and are now
> trying to make it sound as if it wasn't ment that way.
Are you joking again? I may not laugh at you? :D
>
> Besides, you already showed that you you have no problem with sucking stuff
> outof your thumb, and than tried to play it off as if it was the plain
> truth -- and than drop the whole matter when you got challenged in that
> regard. Nope, you lost my belief in your honesty by doing that.
>
> But don't worry about that, you can just blacklist me too and just ignore
> being caught out. :-)
always do something else.
>
> Regards,
> Rudy Wieser
>
>
> -- Origional message:
> d896c131-7f50-4f27...@googlegroups.com...
> On Tuesday, 15 August 2017 14:05:24 UTC+3, R.Wieser wrote:
> > 嘱,
> On Tuesday, 15 August 2017 14:05:24 UTC+3, R.Wieser wrote:
R.Wieser
Aug 15, 2017, 4:47:33 PM8/15/17
to
嘱,
> Oh, sorry, David Brown explained it why it happens.
Kiddo, you do not even seem to understand the difference between a
possibility and a proven fact.
For the rest, Good luck with your "jokes", and good luck with Alf and your
attempt to find a bystander so you can agree with each other how all you
guys did was right, and "that other" had everything wrong.
It doesn't take away the fact that you didn't understand the question
(though someone else had no problem with doing so), even though it was one
of the simpelest, most concise you could ever get. *And* it was even
accompanied with the relevant example code !
Kiddo, you might think the world of your prowess, but you've shown that it
doesn't ammount to much. And your "bedside manners" -- where you pull
stuff outof your ass ("wrappers" and "big mess") and present it as truth --
leaves something to be desired too.
Goodbye.
Rudy Wieser
P.s.
I've got a nice joke for you: I went to school for free. You on the other
hand went for nothing. :-) (here, have your smiley back) Its ofcourse
nasty to say, but as I've presented it as a joke ... lolsz ?
-- Origional message:
嘱 Tiib <oot...@hot.ee> schreef in berichtnieuws
8579384a-fa1a-443c...@googlegroups.com...
>
> > It wasn't written ?? (Chinese zhu') but 嘱 (two o's with diaeresis).
> 嘱 Tiib <oot...@hot.ee> schreef in berichtnieuws
> Oh, sorry, David Brown explained it why it happens.
possibility and a proven fact.
For the rest, Good luck with your "jokes", and good luck with Alf and your
attempt to find a bystander so you can agree with each other how all you
guys did was right, and "that other" had everything wrong.
It doesn't take away the fact that you didn't understand the question
(though someone else had no problem with doing so), even though it was one
of the simpelest, most concise you could ever get. *And* it was even
accompanied with the relevant example code !
Kiddo, you might think the world of your prowess, but you've shown that it
doesn't ammount to much. And your "bedside manners" -- where you pull
stuff outof your ass ("wrappers" and "big mess") and present it as truth --
leaves something to be desired too.
Goodbye.
Rudy Wieser
P.s.
I've got a nice joke for you: I went to school for free. You on the other
hand went for nothing. :-) (here, have your smiley back) Its ofcourse
nasty to say, but as I've presented it as a joke ... lolsz ?
-- Origional message:
嘱 Tiib <oot...@hot.ee> schreef in berichtnieuws
8579384a-fa1a-443c...@googlegroups.com...
On Tuesday, 15 August 2017 19:12:55 UTC+3, R.Wieser wrote:
> 嘱,
>
> > It wasn't written ?? (Chinese zhu') but 嘱 (two o's with diaeresis).
> d896c131-7f50-4f27...@googlegroups.com...
> On Tuesday, 15 August 2017 14:05:24 UTC+3, R.Wieser wrote:
> > ?,
> On Tuesday, 15 August 2017 14:05:24 UTC+3, R.Wieser wrote:
Öö Tiib
Aug 16, 2017, 2:27:35 AM8/16/17
to
On Tuesday, 15 August 2017 23:47:33 UTC+3, R.Wieser wrote:
> Öö,
your bitter behavior; people even older than me usually have inveterate
conditions that hurt and sometimes cause them to grizzle. Microsoft and
Google tools tend to have incompatibilities that neither side will fix.
So it is good for working hypothesis, can you prove it wrong?
>
> For the rest, Good luck with your "jokes", and good luck with Alf and your
> attempt to find a bystander so you can agree with each other how all you
> guys did was right, and "that other" had everything wrong.
I did not say that you did anything wrong. It was all your sore, patronizing
and disparaging tone of communication that is joke of its own. Sorry if
it makes me laugh, but it makes. Who you think you are? You demonstrate
it in this post as well.
>
> It doesn't take away the fact that you didn't understand the question
> (though someone else had no problem with doing so), even though it was one
> of the simpelest, most concise you could ever get. *And* it was even
> accompanied with the relevant example code !
I certainly do make mistakes. Several, every day. My mistakes have made me
rich. It can be that I misunderstood your question, so what? I certainly
start to forget the nuances of decade old C++ compilers and 32 bit
platforms. I don't use these, that's why. So sue me. Can't? Then
drown everything in your bile. :D
>
> Kiddo, you might think the world of your prowess, but you've shown that it
> doesn't ammount to much. And your "bedside manners" -- where you pull
> stuff outof your ass ("wrappers" and "big mess") and present it as truth --
> leaves something to be desired too.
Oh, you are clearly mirroring here. Is the pain of yours in the butt? Are
you in bed? Do you feel being unimportant niggler? If it is so then sorry,
shit happens. Realize, none of it is my fault so you are being unjust here.
>
> Goodbye.
> Rudy Wieser
>
> P.s.
> I've got a nice joke for you: I went to school for free. You on the other
> hand went for nothing. :-) (here, have your smiley back) Its ofcourse
> nasty to say, but as I've presented it as a joke ... lolsz ?
:) Good joke but not about me. I was educated by Soviet Union ages ago.
It wasn't "for free", it was liability. We had obligation of youth
to study. It was "To Learn, to learn, to learn!" said Lenin. Oh, I did
actually like it. Whatever is up with you ... I hope it gets better.
Good day.
>
>
> -- Origional message:
> Öö Tiib <oot...@hot.ee> schreef in berichtnieuws
> >
> > > It wasn't written 嘱 (Chinese zhu') but Öö (two o's with diaeresis).
> Öö,
>
> > Oh, sorry, David Brown explained it why it happens.
>
> Kiddo, you do not even seem to understand the difference between a
> possibility and a proven fact.
Does that "Kiddo" mean that you are older than me? That may explain
> > Oh, sorry, David Brown explained it why it happens.
>
> Kiddo, you do not even seem to understand the difference between a
> possibility and a proven fact.
your bitter behavior; people even older than me usually have inveterate
conditions that hurt and sometimes cause them to grizzle. Microsoft and
Google tools tend to have incompatibilities that neither side will fix.
So it is good for working hypothesis, can you prove it wrong?
>
> For the rest, Good luck with your "jokes", and good luck with Alf and your
> attempt to find a bystander so you can agree with each other how all you
> guys did was right, and "that other" had everything wrong.
and disparaging tone of communication that is joke of its own. Sorry if
it makes me laugh, but it makes. Who you think you are? You demonstrate
it in this post as well.
>
> It doesn't take away the fact that you didn't understand the question
> (though someone else had no problem with doing so), even though it was one
> of the simpelest, most concise you could ever get. *And* it was even
> accompanied with the relevant example code !
rich. It can be that I misunderstood your question, so what? I certainly
start to forget the nuances of decade old C++ compilers and 32 bit
platforms. I don't use these, that's why. So sue me. Can't? Then
drown everything in your bile. :D
>
> Kiddo, you might think the world of your prowess, but you've shown that it
> doesn't ammount to much. And your "bedside manners" -- where you pull
> stuff outof your ass ("wrappers" and "big mess") and present it as truth --
> leaves something to be desired too.
you in bed? Do you feel being unimportant niggler? If it is so then sorry,
shit happens. Realize, none of it is my fault so you are being unjust here.
>
> Goodbye.
> Rudy Wieser
>
> P.s.
> I've got a nice joke for you: I went to school for free. You on the other
> hand went for nothing. :-) (here, have your smiley back) Its ofcourse
> nasty to say, but as I've presented it as a joke ... lolsz ?
It wasn't "for free", it was liability. We had obligation of youth
to study. It was "To Learn, to learn, to learn!" said Lenin. Oh, I did
actually like it. Whatever is up with you ... I hope it gets better.
Good day.
>
>
> -- Origional message:
> Öö Tiib <oot...@hot.ee> schreef in berichtnieuws
> 8579384a-fa1a-443c...@googlegroups.com...
> On Tuesday, 15 August 2017 19:12:55 UTC+3, R.Wieser wrote:
> > Öö,
> On Tuesday, 15 August 2017 19:12:55 UTC+3, R.Wieser wrote:
> >
> > > It wasn't written 嘱 (Chinese zhu') but Öö (two o's with diaeresis).
Paul N
Aug 17, 2017, 3:49:10 PM8/17/17
to
On Thursday, August 10, 2017 at 7:03:00 PM UTC+1, R.Wieser wrote:
> Hello all,
>
> This is sort of a of continuation of my previous question, as it regards the
> same object.
>
> I would like to use a virtual destructor for a pure virtual class (no code
> in the vc++ program), but have no idea about the/its side-effects.
>
> Like who is responsible for freeing the objects memory in case a virtual
> destructor is executed.
I think you may be confused about what a destructor is. A destructor does not kill off an object. An object can be killed off in various ways. One is if it has been created using "new" and you call "delete" on it. Another is if it is an automatic variable (a "local" variable) and the program reaches the end of the block it is in. When the object is destroyed, two things happen - the destructor is called, and the memory occupied by the object is freed. So the destructor does not kill the object, but is a chance for the programmer to specify what happens when the object is killed by some other means. For example, the destructor can be used to close any open files, or it can free some other memory that the object has allocated (but not the memory used by the object itself).
> Hello all,
>
> This is sort of a of continuation of my previous question, as it regards the
> same object.
>
> I would like to use a virtual destructor for a pure virtual class (no code
> in the vc++ program), but have no idea about the/its side-effects.
>
> Like who is responsible for freeing the objects memory in case a virtual
> destructor is executed.
So, whether it's a virtual destructor or not, you do not need to worry about freeing the memory actually occupied by the object. Unless you've used "placement new".
> The reason I'm asking is because in my case the external object releases its
> own memory, and having the vc++ program try to do it again would probably
> not end well ...
>
> The same goes for the "delete(object)" command. I assume it its, apart
> from zeroing-the object variable after the method call returns, fully
> equivalent to "object->~object();", but am not at all sure of it.
I don't think that there's any guarantee it will zero the memory, but it will free it, yes.
> I have googled, but I only seem to be able to find pages talking about
> derived classes, which is most certainly not how I'm using it.
The only point in declaring the destructor virtual is if you are at least planning on having derived classes. The point is that you can then delete a derived class using a pointer of type "pointer to base".
> So, in the case of a virtual destructor, who is responsible for/does the
> releasing of the objects allocated memory ? And are there other (side)
> effects I should be aware of ?
No, it should all work as planned. Virtual destructors are good.
0 new messages