dll call ???

[jchd]

Name mangling was added to C++ because of function overloading, not OO.

C++ names are mangled anyway, C names aren't.

Simple one: a C program using AutoItX.

You're confusing things. C can make use of AutoItX, but the DLL interface is C. So you're calling C from C. COM is another guy.

[jchd]

I think you totally missed by point, I think trancexx is more on the ball with what I am referring to. From what I understand (and I could be totally wrong) C and C++ code get compiled down to basically the same thing - so if you look at the assembly or machine code there would be really no difference between them. Concepts like OO, encapsulation only apply when creating the dll and have no meaning to the computer only to the compiler and the coder.

I raised the point to address Richard's comment and he is correct in his statement but I don't see how a dll being OO or not should make any different in calling it. The API will dictate what is required regardless of how it is implemented.

But how exactly do you handle vtables from C without (essentially "illegal" and non-portable) under_the_hood knowledge?

I agree that C and C++ can be made to produce comparable code for native types, but I don't see how they can cope together as soon as objects or references to them are first class citizens and are arguments or return values.

[Richard Robertson]

I think you totally missed by point, I think trancexx is more on the ball with what I am referring to. From what I understand (and I could be totally wrong) C and C++ code get compiled down to basically the same thing - so if you look at the assembly or machine code there would be really no difference between them. Concepts like OO, encapsulation only apply when creating the dll and have no meaning to the computer only to the compiler and the coder.

I raised the point to address Richard's comment and he is correct in his statement but I don't see how a dll being OO or not should make any different in calling it. The API will dictate what is required regardless of how it is implemented.

Ok. Show me, in AutoIt, how to call a C++ dll that uses objects instead of straight up functions.

[trancexx]

You are talking Spanish and he talks Portuguese.

Bottom line, you are talking about different things. That's what I see reading this topic.

[Richard Robertson]

You are talking Spanish and he talks Portuguese.

Bottom line, you are talking about different things. That's what I see reading this topic.

My point was that AutoIt can't (to my knowledge) use object oriented code right now. That was all I meant when I mentioned that .Net dlls are OO.

[bo8ster]

Ok. Show me, in AutoIt, how to call a C++ dll that uses objects instead of straight up functions.

I knew you where going to ask that question. I am thinking in context of something like windows or a "system" would handle objects and you just call the functions. I know AutoIt does really handle OO but it does not have to in order to work with it. I may be completely wrong and please let me know if I am but this is how I understand it.

Yes, you may have some "reference" or handle to the instance (handle to a text box for example) but that will be dictated by the API - example _WinAPI_GetClassName or (MSDN) GetClassInfo, no need to worry about Objects here, just the API.

The object may be a singleton so the object reference or handle is never required in the API. I assume the mouse cursor is implemented in this way and assuming it is written in C++ with objects, there should be no reason why you cannot use dllcall to call cursor functions. I would expect this to be the case with custom written programs too. I am sure you can think of custom examples.

[jchd]

Agreed, it's possible to have a real OO library bundled with a classical C-style interface for everything. But then the fact that the library uses OO or not is irrelevant since you just can't see how it's done internally. Inside things can be OO (Object Oriented), MD (Magic Driven), RB (Randomized Behavior) or any new programming paradigm that gets fashionable tomorrow. But DllCall as it is today would still invoke C-style simple functions with native C-style types.

Say we write a minimal complex number C++ class, with just some constructors, destructors and a few simple operations. Leave alone templates, base classes, inheritance and operators overloading: something really simple. Making a dll from that is easy. But then how would you invoke ctors, member functions or dtors using DllCall? The best you can have is a set of plain C-style functions (a C-style API) to instruct the library to internally create/manipulate/destroy objects for you, but you can't do that directly. Just like the Windows API for AutoIt programmers.

Using the published material, DllCall can only interface C-style (cdecl or stdcall) functions, but nothing using objects (in OO parlance) directly, except possibly with a lot of ugly, dirty, dangerous hacks.

[Richard Robertson]

bo8ster, I don't think you really understand the problem here.

[AlienStar]

I thank all of you about this discussion

I admit that I feel with lots of useful

I'll test all suggestions maybe get something benefit my work

Edited January 5, 2010 by AlienStar