[YLUG] Pointer help correction

[Dominic Hibbs]

#define BIGINT 1
> #define DOUBLE 2
> #define STRING 4
> #define ARRAY  8
> #define INITIALISED 16
>
> struct sdescript
> {
>   char *   sptr;    // pointer to string
>   int salloc;    // allocated space for string
>   int slength;    // actual length of string - always <= salloc
> };
>
> union varval {
>   int *bi;        // BIGINT
>   double *df;        // DOUBLE
>   sdescript *sd;    // STRING
> };
>
> struct variable {    //
>   union varval  value;    //
>     char * varname;
>     int varlength;
>     char bitflags;
> };


and

 variable v;
  *v.value.bi = 10;
  v.varname = "@%";
  v.bitflags = BIGINT;
  *MOC = v;

where MOC is declared as void * gives

bb1fun.cc:183: error: 'void*' is not a pointer-to-object type
183 is the *MOC line.

Your input is deeply appreciated.

Cheers Dominic

What you haven't told us is if your C++ program structures need to
> *exactly* match the assembler structures


No.


> So, actual data in the structure could be represented by something
> like:
>
> struct s
> {
>   void*   a,
>   int16_t b,
>   int16_t c
> };
>
> struct record
> {
>   union u1
>   {
>     int64_t* a,
>     double*  b,
>     s*       c
>   };
>
>   union u2
>   {
>     uint64_t  a,
>     s         b
>   };
>
>   ...
> };
>
>
> While this is compact and efficient, it's also a horror from a C++
> programmer's perspective.


Yes

C++ provides mechanisms in the Standard
> Library to do lists, e.g. std::list and std::vector.  These templated
> containers should, with compiler optimisations turned on, be just as
> time- and space-efficient as your assembly.
>
> Consider, C++ lets you code from a higher level perspective, so rather
> than show us the exact structure, tell us what you want the code to
> /do/, and what information needs to be represented.  There's sure to
> be a clean and efficient way of representing it.
>
> Also note: pointers are /not/ 32 bits.  They might be on i386, but
> they are not on amd64, and on other architectures, even 32-bit ones,
> they may be greater than 32 bits (e.g. function pointers).



Good point.

  A pointer
> is a pointer, and has an architecture-specific size which might even
> change depending on what you are pointing to; you can't assume it's 32
> bits, ever.  A C or C++ compiler will always handle this for you.
>
>
> Regards,
> Roger
>
> _______________________________________________
> York mailing list
> York at lists.lug.org.uk
> https://mailman.lug.org.uk/mailman/listinfo/york
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.lug.org.uk/pipermail/york/attachments/20080113/00823b78/attachment.html