OSLib Namespace for C++

[Jonathan Coxhead]

> > Shame about the macros though :-(
> 
> For C++, you could replace those macros defining constants with
> |const|s.

   There is some code in there to do that (not "live" code, though---just 
some old work-in-progress). There is a DefMod switch, -c++, that controls 
it. It means that a DefMod line like

      CONST .Bits thing = 17

which in C becomes

      #define thing ((bits) 17)

is mapped to

      static bits const thing = 17;

instead. That part is not specially hard.

> > Hmm, I wonder how difficult it would be to develop an OSLib++
> > variant...
> 
> I was also thinking, "how about two libraries?"  One for
> cc/cfront, one for gcc.  Of course, two libraries inevitably means
> people asking for help when they are having problems, when all
> that is wrong is they should be using the other library.

   2 (or even more) libraries are also a necessity. The trouble is the 
OSLib generates object code, and so it has to match the underlying naming 
convention of the compiler. In C, this is easy---it just prepends an 
underscore.

   In C++, the problem is much bigger, because in order to call a function 
declared---with no extern "C"---as, say

      os_error *os_writec (int c);

the compiler mangles the name, and puts in the object file a name like

      os_writec__FiRpos_error

or some such nonsense. This ensures type-safe linkage. There is no standard 
for this: you have to read the documenation of your compilation system to 
find out how to do it.

   Again, there is some prototype code to have a stab at this (for the 
NorCroft/CFront combination), which ought to give an idea. But it would 
have to be redone for GNU, etc, and it's also the sort of thing that 
changes between releases. So a given "OSLib.o" would only work with a 
certain range of GNU releases.

   What would the benefits of this work be?

   I'm not sure. Apart from the absence of all those |extern "C"| 
directives, not a lot, I suspect. I think any real O-O interface to the O S 
("OSLib++") would have to invent lots of new concepts that could not be 
automatically generated by DefMod, so the right approach would be to write 
code in C++ that would be a client of the ordinary OSLib. The exception is 
a small number of cases where SWI's have been split because of different 
argument typing: e g

      extern os_error *xwimp_send_message_to_window
      (
         wimp_event_no  event,
         wimp_message  *message,
         wimp_w         to_w,
         wimp_i         to_i,
         wimp_t        *to_t
      );

could become

      extern os_error *xwimp_send_message
      (
         wimp_event_no  event,
         wimp_message  *message,
         wimp_w         to_w,
         wimp_i         to_i,
         wimp_t        *to_t
      );

under which name it overloads the other function with the same name,

      extern os_error *xwimp_send_message
      (
         wimp_event_no  event,
         wimp_message  *message,
         wimp_t         to
      );

where the 2 are distinguished by the argument types.

   This is fun, but not incredibly useful, it seems to me.

        /|
 . . . (_|/ o n a t h a n
        /|
       (_/