Sunday, August 13, 2017

Digest for comp.lang.c++@googlegroups.com - 9 updates in 4 topics

kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Aug 12 11:45PM -0700

On Sunday, August 13, 2017 at 2:16:33 AM UTC+5:30, Paavo Helde wrote:
> why your C++ data is sent to PHP via 30-year old e-mail systems?
 
> Cheers
> Paavo
 
Actually i dont have much idea about encoding as somone pointed out in this post to start with a random and simplest encoding format which is well supported by nearlly all programming languages and i am using this because i have to send huge strings via socket to remote servers and there may be chance of misinterpretitions in between so to me encoding data would preserve the strings in the orginal form on either end of transport
"Öö Tiib" <ootiib@hot.ee>: Aug 13 04:06AM -0700

On Friday, 11 August 2017 11:39:39 UTC+3, Ian Collins wrote:
> > here
 
> Sockets are typically used to transfer binary data, why do you see
> special characters as a problem?
 
Perhaps in manner as it always tends to be with silly PHP.
https://xkcd.com/327/
Paavo Helde <myfirstname@osa.pri.ee>: Aug 13 10:48PM +0300

On 13.08.2017 9:45, kushal bhattacharya wrote:
 
> Actually i dont have much idea about encoding as somone pointed out in this post to start with a random and simplest encoding format which is well supported by nearlly all programming languages and i am using this because i have to send huge strings via socket to remote servers and there may be chance of misinterpretitions in between so to me encoding data would preserve the strings in the orginal form on either end of transport
 
The question remains: why do you think that the sockets ruin your huge
strings somehow? Why not small strings, for example? And why do they not
ruin the terabytes of youtube videos downloaded every day, for that
matter? Have the Sockets declared some kind of personal vendetta on you?
"R.Wieser" <address@not.available>: Aug 13 08:55AM +0200

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.
 
> 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 <noname@invalid.add> schreef in berichtnieuws
ommrvc$cis$1@gioia.aioe.org...
 
> The question is if it works by coincidence or because it is correct.
> 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
 
> >> 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
> 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
Kalle Olavi Niemitalo <kon@iki.fi>: Aug 13 12:44PM +0300


> 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
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" <address@not.available>: Aug 13 12:57PM +0200

Kalle,
 
> 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:
Kalle Olavi Niemitalo <kon@iki.fi> schreef in berichtnieuws
87bmnjpzt8.fsf@Niukka.kon.iki.fi...
Manfred <invalid@invalid.add>: Aug 13 01:39PM +0200

On 08/13/2017 08:55 AM, R.Wieser wrote:
 
>> 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.
 
 
> 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.
 
I don't think there is a way defined by the language (the standard does
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.
 
 
>> 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.
 
*I* don't have any problem, it looks like you have.
 
 
> 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 even had a similar problem with different versions of MSVC++.
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)
 
> 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.
 
You have to follow the ABI of the other end, you can't define an ABI of
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...
 
> 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. :-(
 
This shows confusion about what pointers are.
 
> 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.
 
That was not an ABI.
https://en.wikipedia.org/wiki/Application_binary_interface
 
 
>>> I guess I ment reference than.
 
>> I guess you guessed wrong...
 
> Now *thats* helpfull. Not. :-(
 
It could have directed you into looking for a correct definition of
pointers and references. It is up to you if you are willing to.
 
asetofsymbols@gmail.com: Aug 13 02:49AM -0700

With all as object and Objects Oriented languages, especially C++ even in old standards
that allow to write constructor and destructor of objects too
All it is already easy
(if one not use too much portion of language)
 
I think would more easy if something goes wrong in a object
the object has some flag that say that object is wrong and one place where there is the last error it meet
 
If I name that error object with
 
E
 
Than each operator or function use E as argument for calculate its result has to return as result one error object that I call E'
 
All this it is easy because if I print one object, the print function check if that is error object
if yes print that would be some error
and who see the program know there is something that went wrong...
 
Disclaimer:
Yes it is only theory I don't know if this could be ok because I not had implement all this
Marcel Mueller <news.5.maazl@spamgourmet.org>: Aug 13 10:55AM +0200

On 12.08.17 19.33, Mr Flibble wrote:
> Anyone who claims that std::set and std::map is no use to them is
> obviously Doing It Wrong (TM). They are essential containers and should
> be used when it is appropriate to use them.
 
OK, you are right. I just did not have any use case so far (approx. 20
years) where they are superior to a B-Tree.
 
When I used this containers it was only for the reason that a B-Tree was
not available and it was not worth the trouble to include a B-Tree
implementation.
 
If I had the choice whether a RBTree or a B-Tree is in the standard I
would clearly vote for the B-Tree. Unfortunately many container
libraries choose the other way (e.g. .NET as well).
 
> If you don't know when it
> is appropriate to use them or you think that it is never appropriate to
> use them then you are newb.
 
The only thing I can think of is when iterator invalidation on container
modifications is critical. At this point RB-Trees are a good choice. But
this requirement is infrequent.
 
 
Marcel
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)