A couple of Questions

[Timothy Baldwin]

On Wednesday 25 July 2001 12:43 am, you wrote:
> On 24 Jul 2001, in message
> <E15P7mh-0005IB-00 at bfg.reinhouse.freeserve.co.uk>,
>
> Timothy Baldwin <tim at reinhouse.freeserve.co.uk> wrote:
> > In swi.Wimp there is:
> >
> >    Message_Prequit       = .Bits: 8,
> >    Message_PreQuit       = .Bits: 8,  // V6.21 TV
> >
> > As DefMod stands, on RISC OS 3+, it will ignore the first line,
> > due to a case insensitive [1] comparison in Lookup().
> > What is actually intended?
>
> No, that was not what was intended. The correct form is Message_PreQuit,
> and prior to V6.21 it had been misspelled. When I corrected it, I left the
> previous definition, with the intention of providing backwards
> compatibility. It seems like my good intentions were in vain. Then again,
> I've not seen any complaints, so I guess there's not much point in
> restoring the old version...
>
> > Also in swi.Wimp:
> >
> > // Generic Wimp Message Header
> > TYPE Wimp_MessageHeader =
> >    .Struct
> >    (
> >       .Int:   size     "Message size",
> >       Wimp_T: sender   "Sender of message - set by the Wimp",
> >       .Int:   my_ref   "My reference - set by the Wimp",
> >       .Int:   your_ref "Your reference - 0 if not a reply",
> >       .Bits:  action,
> >       .Byte:  data ...
> >    );
> >
> > Why does Wimp_MessageHeader have a variable size data member?
>
> This is for historical reasons, and provides backward compatibility with
> earlier versions of the library. It allows clients to set up their own
> message structures, but is now largely superseded by the new forms
> introduced in 6.00.
>
> The base message header structure is defined for C by
> wimp_message_header_base, or as a macro in wimp_HEADER_MESSAGE_MEMBERS
> which is used in the wimp_full_message_* group of structures.
>
> > This is both illogical, and causes difficulties with C++ inheritance.
>
> I have been using OSLib for some considerable time now without problems wit
> C++.

I didn't mean that OSLib is currently broken.

> > I intend to improve C++ support.

The problem is how would DefMod know to make 
colourpicker_full_message_open_parent_request (and the like) inherit 
wimp_message_header_base instead of wimp_message_header.

The simplest solution would be create a new type wimp_message_base
to use as the base for the wimp_full_message_* group and wimp_message_header 
(and wimp_message).

> However, it would be nice to see a proper set of C++ classes defined by
> DefMod. I look forward to your efforts.

I propose:

A new DefMod type .SuperClass [2] which is used like:

Wimp_BlockBase = .SuperClass Wimp_Block

and compiles to something like:

#define wimp_BLOCK_BASE_MEMBERS
#if defined __GNUG__ && __GNUG__ >= 3
class wimp_block {};
#elif
typedef wimp_block wimp_block_base;
#endif

which can be used as a base class (eg for wimp_message_header, wimp_block and 
members). I realise the requirement for g++ version 3 excludes all 
*currently* avaiable RISC OS compilers, but I can't get a zero length class 
[3] out of Norcroft C + cfront or gcc 2.95. If anyone knows otherwise please 
let us know. 


Extending .Struct to support multiple inheiritence, and representing this as 
C++ inheritance. Use this to better represent the relationship between 
structures.

Allow the passing of references where pointers are currently excepted, 
implemented by inline function templates.

Use C++ const instead of #define so that the OSLib namespace is observered.

Always use the OSLib namespace on compilers which support namespaces, so as 
to avoid link incompatibilities between OSLib clients. Source compatibility 
will maintained with a "using namespace OSLib;" if NAMESPACE_OSLIB is not 
defined.

Implement variable size structures with C99 flexible array members [4] and 
independentally with C++ templates (100% source compatible with the current 
macro implementation).

Re-implement OSLibSupport.X with C++ exceptions, as an alternative, to allow 
interoperation with C++ exceptions.

Make all new preprocessor macros start with OSLIB_ as a precaution against 
conflicts.

Do the above without separate header files for C and C++, the alternative 
being putting separate header files on different paths and does not allow 
individual features be selected by macros.

Convert Defmod.c.Cheader to using (OSLibSupport.X) exceptions, and remove the 
code to generate C++ comments, this will make the code easier to understand.


About DefMod:

> > [1] If you make it case sensitive you will need this patch:
> >
> > Index: Source/User/oslib/MimeMap.swi
>
> [snip]
>
> Hmm, I don't think you picked the right patch there...
>
> I guess it ought to be case sensitive, but I'm a bit hesitant about doing
> this, in case it upsets something else, and I really don't think it's
> worth spending much time on right now...

Said patch fixes the only place OSLib breaks with a case sensitive DefMod 
(apart from multiple definitions of OS_VDULineFeed and Message_PreQuit).

After "fixing" these, the Hdr.* h.* s.* s32.*  files are identical to the 
ones in the distribution save the line containing the date (Tested on 
GNU/Linux, but I see no reason why I it could break on RISC OS).

BTW, putting the distributed assembly files is s;0 and s32;0 directories makes
writing tests in makefiles difficult to impossible as make (both amu and GNU 
make) interpret ; as meaning start of commands.

> However, seeing as you seem to have time on your hands, something that
> really does need sorting out is the amendments to DefMod to generate the
> post 6.0 structures from the variable length definitions for the Assembler
> headers. Now that really *would* be helpful. (Especially for Philip Ludlam
> :-)

[2] Or can anyone think of a better name?

[3] I can get sizeof() == 0, but it still adds data to the beginning of it's 
subclass which is what matters.

[4] Direct equivalent of DefMod's variable length arrays