|
In C++ you have ints, variables for floating point numbers, bools. Does Assembly have the same variable differentiation? Can you move any type of variable into a register?
|
|
|
|
|
yes and no.
There's no types in assembly.
You just move data to a register; the data can be anything (int, float, address to a string, ...)
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Not entirely true: floating point registers are still separate AFAIK. The rest are all the same.
Mircea
|
|
|
|
|
What about db, dw, dd, dq ... ?
|
|
|
|
|
Assembler does have (sort of) data types, in the way that you declare variables. But at the instruction level it is up to the programmer to ensure that the items are handled correctly. Take a look at NASM - The Netwide Assembler[^] for specific details.
|
|
|
|
|
Richard MacCutchan wrote: it is up to the programmer to ensure that the items are handled correctly Truth!
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Richard thanks for your reference.
|
|
|
|
|
You are welcome. And NASM is a good introduction to Assembler, and machine code.
|
|
|
|
|
Thanks for your feedback guys
|
|
|
|
|
Hi,
as learning process, i need some code (or simple sample project) that shows how to post?send message from a library (dll) to application (dialog or console). If a thread in dll sends message to app, how is the best to approach that?. Using GetMessage?.
|
|
|
|
|
Keep in mind of course that a library doesn't do anything. Applications do stuff and use libraries.
So you want two applications.
You can start with researching (google) examples of Rest (http.)
|
|
|
|
|
Yes.
I am trying to experiment another feature that may become handy.
|
|
|
|
|
|
same message id is created in dll and in application?.
in application there is a routine that polls the messages. correct?.
|
|
|
|
|
Yes, you can create a message inside a DLL and send it to an application. But that still needs a controlling application to drive the DLL; so why would you do it that way? .A Windows (as opposed to a Console) application, must contain a message pump which pulls messages from its queue and processes them.
|
|
|
|
|
in case DLL need to inform application of something changed.
callback is better for this case?.
|
|
|
|
|
An unequivocal YES! Sending window messages is about the least flexible thing you can use because it's limited to being used only with Windows applications that have a message pump. That keeps you from using it in Console apps, Service apps, and all web applications.
|
|
|
|
|
wizQ wrote: in case DLL need to inform application of something changed. I think you misunderstand the role of a support library. A library (whether .lib or .dll) is a set of passive functions that are only activated when called from an application (Console or Windows). So it is unlikely that they would be able to "know" when anything happened that needed to be communicated to other applications.
|
|
|
|
|
//TestDll2.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __cdecl NS::A::A(int (__cdecl*)(class std::basic_string<char,struct std::char_traits<char="">,class std::allocator<char> >))" (__imp_??0A@NS@@QEAA@P6AHV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z@Z) referenced in function main
=====file TestDll2.cpp=====
#include <iostream>
#include "..\\MyDll\\MyDll.h"
using namespace std;
using namespace NS;
int Print(string str);
int main()
{
NS::A* a = new NS::A(Print);
NS::printDlgt("Hello World!");
}
int Print(string str)
{
cout << str << endl;
return 0;
} MyDll project files
=====MyDll.cpp=====
#include "pch.h"
#include "MyDll.h"
namespace NS
{
PrintDelegate printDlgt;
A::A(PrintDelegate print_Dlgt)
{
NS::printDlgt = print_Dlgt;
}
}
=====MyDll.h=====
#include <iostream>
#ifndef MYDLL_H
#define MYDLL_H
#ifdef MYDLL_EXPORTS
#define MYDLL_API __declspec(dllexport)
#else
#define MYDLL_API __declspec(dllimport)
#endif
using namespace std;
typedef int (*PrintDelegate)(string str);
namespace NS
{
extern PrintDelegate printDlgt;
class MYDLL_API A
{
public:
A(PrintDelegate print_Dlgt);
};
}
#endif
|
|
|
|
|
Oscar K. wrote: //MYDLL_EXPORTS is set in C++\Preprocessor
What do you mean by that? MYDLL_EXPORTS should only be defined in MyDll.cpp, just before the #include "MyDll.h" . You also need to ensure that you add MyDll.lib to the linker options in your build.
[edit]
On reflection I think maybe the definition of extern PrintDelegate printDlgt; is not correct. I think it should also by declared with MYDLL_API .
I will try and test this later today.
[/edit]
modified 17-Mar-24 5:19am.
|
|
|
|
|
#define MYDLL_EXPORTS is already set in Debug\Properties\C++\Preprocessor
#define MYDLL_EXPORTS in MyDll.cpp invokes macro redefinition
extern PrintDelegate printDlgt in MyDll.h is usual decision, that's how it's done
|
|
|
|
|
Oscar K. wrote: #define MYDLL_EXPORTS in MyDll.cpp invokes macro redefinition You should only have it in one place, and inside the dll implementation file (MyDll.cpp) is the better choice.
Oscar K. wrote: extern PrintDelegate printDlgt in MyDll.h is usual decision, that's how it's done Correct, but that only makes it visible to the build of the DLL. When you build your test code the it is declared extern which the compiler accepts as it should be defined in another compilation unit, as part of the build of the main program. But when you try to link the program the linker cannot find where that item is actually defined because it only exists in the DLL. And since it has not been exported it is not listed in the lib or exp files.
|
|
|
|
|
I added extern PrintDelegate NS::printDlgt; to TestDll2.cpp, but I have got again error unresolved external. I see class A (MyDll.dll) in Dll viewer.
|
|
|
|
|
And you will continue to get that error until you create the object inside the namespace and use the MYDLL_API export prefix. As I have said more than once, you cannot use extern on an item that only exists in a DLL.
|
|
|
|
|
I changed extern PrintDelegate printDlgt;
to
extern MYDLL_API PrintDelegate printDlgt;
Now it works properly
Thanks Richard
|
|
|
|