This is what Visual Studio tells me:
Stop!
What you see is just the instruction (here, generate code in order to call a function) for the compiler.
What I investigated was the code already generated by the compiler (.cpp vs .o).
So we both are talking about two completely different things.
Let's clear things up:
m_oldregion=InstallClipRegion(m_pwindow->m_pWindow->WLayer,m_newregion);
If this is compiled in C++ mode, SAS/C will produce an "external reference" to a function called "@InstallClipRegion__FP5LayerP6Region". This is an ordinary C++ functions, which SAS/C has already created / has to create.
But if this is compiled in C mode, SAS/C will produce an "external reference" to a function called "_InstallClipRegion", which is either the synonym for the shared library's function offset or some sort of glue code, which makes this function offset available to the compiler.
Now I have to speak verbosely.
An ordinary C/C++ function is just an address in memory, if you call it, f.e. "InstallClipRegion(...)", the code generated by the compiler just puts the parameters either on the stack frame or in the appropriate registers (or both, depends on ABI) and then jumps directly to the address, which you used by its synonym. In this example "InstallClipRegion" is the synonym, let's say (as an example) for the address 600000 in memory and the compiler respectively the linker, knows exactly this synonym's address, because the compiler generated it.
Amiga OS1.x to 3.x shared libraries don't contain addresses which are directly jumpable. Instead, there is a base address and from there downwards (i.e. negative) the jump offsets are defined, called library vector offsets (LVO). Normally, you cannot reach these jump addresses with the instruction set offered by a C/C++ compiler, because something like LayersBase->InstallClipRegion() isn't near any possibility, because "InstallClipRegion" is just the synonym for the negative number '-174' and due to the AmigaOS 1.x to 3.x ABI the parameters have to reside in varying processor registers!
Thus what was made in the early days of Amiga OS1.x was to grant the poor C coder access to those shared library offset in form of assembler generated glue code:
XREF _LayersBase ; Reference to an absolute 32-bit symbol
XDEF _InstallClipRegion ; Define an absolute 32-bit symbol
; Symbols (as we use them here) are just 32-bit memory addresses!
_InstallClipRegion
move.l a6,-(sp) ; Remember for restoring the processor
; register A6 within the stack frame
movea.l 8(sp),a0 ; Take parameter 'layer' from stack frame
; (the C compiler stored it there)
movea.l 12(sp),a1 ; Take parameter 'region' from stack frame
; (the C compiler stored it there)
movea.l _LayersBase,a6 ; Put base address in processor register
; A6 (convention), _LayersBase was set up by
; the C/C++ compiler, see OpenLibrary().
jsr -174(a6) ; Jump to this address and carry out the instructions
; residing there
movea.l (sp)+,a6 ; When we get back, restore this register's content
rts ; Back to C/C++ compiler generated code with return code
; in processor register D0
In reality, the offset -174 is not named InstallClipRegion but _LVOInstallClipRegion - but the function which is carried out is named InstallClipRegion!
Because it was a mess for any C coder to link against those glue code, there were approaches to avoid using glue code; SAS/C does it by specifying "#pragma libcall LayersBase InstallClipRegion ae 9802", which when encountered by the SAS/C compiler, will produce the necessary code in order to fire up the function hidden behind the offset "ae" (174) automatically, including that all parameters were put in the appropriate registers without touching the stack frame. First of all, any time now InstallClipRegion() is called by the application programmer, the corresponding code will be generated, what makes the executable file a little larger, but the benefit is that the code is drastically faster than before, because the compiler will "inline" this code, i.e. does directly jump to the appropriate code which resides in the corresponding shared library without taking the detour via the glue code.
Today, any Amiga compiler will use "inlined" code, whether by preprocessor commands or directly using assembler instruction doesn't make any difference. But still LayersBase->InstallClipRegion() isn't possible under C/C++, what would be the correct notation if we speak about genuine C/C++ functions. OS4 introduced therefore a more abstract method, ILayers->InstallClipRegion() - note the change from LayersBase to ILayers!
Now you and me know that OS functions (or any functions in a shared library), when we use them, are *not* any kind of genuine C/C++ functions, but some very complicated constructs (from a C/C++ compilers point of view), which fortunately is causing us today no headache anymore, thanks to the work done by the compiler builder!
Hence, "@InstallClipRegion__FP5LayerP6Region" is just a memory address (genuine C++ function), whereas "_InstallClipRegion" is the synonym for code that calls a certain function in a shared library. On the paper (i.e. within a source code) they look pretty much the same, but once the compiler encounters them, it will create different code.
Thus,
m_oldregion=InstallClipRegion(m_pwindow->m_pWindow->WLayer,m_newregion);
compiled in C++ mode without telling the compiler that this is a special function (i.e. without using 'extern "C"') will produce code, which will create a reference to "@InstallClipRegion__FP5LayerP6Region".
Compiled in C++ mode but using 'extern "C"' should not at all create a reference to "_InstallClipRegion" but should "inline" the required code.
The same goes for C compiles; there should be no reference to "_InstallClipRegion", just the inlined code.
If, and only if one does *not* specify "proto/layers.h", there will be references to "_InstallClipRegion", i.e. the compiler will not create inlined code. Thus, if one specifies "proto/layers.h" SAS/C will include "pragmas/layers.h" and "clib/layers.h", which will have the result of inlined code for Amiga shared library functions (offsets) without any references written out to the corresponding object file.
Maybe, but only maybe, SAS/C will not directly write such inline code, but let this do the linker - but, to be honest, I wouldn't bet a dime on this. Like I already told, I don't have a copy of SAS/C to explore this.
Besides, hopefully my English is not so bad that you do not understand what I mean. I have praised already once in a while to take an English course but earning money do foil my best plans...
BTW, what do you think of this AFrame? It caught my attention because it provides objects in a fashion recognizable to me. I even like the fact that, for example, a window has "events" like OnWindowClose or OnGadgetDown.
Well, I haven't taken a closer look. I just listed the object file structure of the static lib and searched for external references in the object files.
Since I don't own a copy of SAS/C I cannot run any own tests (static libs are bound to the compiler that created it, especially C++ static libs) - or are all source codes provided?
In addition, I tried some of the examples, but unfortunately, a lot of them crashed instantly. Next, there is no real layout method, nor font sensitivity as far as I saw. But then again, I have only spent five minutes or so investigating. No closing judgement possible...
Regards