Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #32824 > unrolled thread

Write once C and forth structs

Back to article view | Back to comp.lang.forth

Contents

  Write once C and forth structs Hannu Vuolasaho <vuokkosetae@gmail.com> - 2014-08-02 13:25 +0300
    Re: Write once C and forth structs Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-02 13:47 +0200
      Re: Write once C and forth structs Hannu Vuolasaho <vuokkosetae@gmail.com> - 2014-08-02 15:40 +0300
        Re: Write once C and forth structs Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-02 19:08 +0200
      Re: Write once C and forth structs hughaguilar96@yahoo.com - 2014-08-02 20:47 -0700
        Re: Write once C and forth structs hughaguilar96@yahoo.com - 2014-08-03 21:03 -0700
          Re: Write once C and forth structs "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-04 04:16 -0400
            Re: Write once C and forth structs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-04 11:39 -0500
              Re: Write once C and forth structs Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-04 22:35 +0200
                Re: Write once C and forth structs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-05 12:33 +0000
                  Re: Write once C and forth structs hughaguilar96@yahoo.com - 2014-08-05 20:31 -0700
                    Re: Write once C and forth structs Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-08-05 21:45 -0700
                      Re: Write once C and forth structs Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-08-05 21:45 -0700
                      Re: Write once C and forth structs humptydumpty <ouatubi@gmail.com> - 2014-08-05 23:00 -0700
                    Re: Write once C and forth structs "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-06 16:38 -0400
                  Re: Write once C and forth structs hughaguilar96@yahoo.com - 2014-08-06 17:18 -0700
              Re: Write once C and forth structs "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-04 17:43 -0400
              Re: Write once C and forth structs Samuel DEVULDER <samuel-dot-devulder-at-laposte-dot-net> - 2014-08-05 08:26 +0200
                Re: Write once C and forth structs hughaguilar96@yahoo.com - 2014-08-05 20:23 -0700
                  Re: Write once C and forth structs Samuel DEVULDER <samuel-dot-devulder-at-laposte-dot-net> - 2014-08-06 08:40 +0200
                    Re: Write once C and forth structs hughaguilar96@yahoo.com - 2014-08-06 14:43 -0700
                  Re: Write once C and forth structs Gerd Brix <gbrix@gmx.eu> - 2014-08-06 08:54 +0200

Page 1 of 2  [1] 2  Next page →

#32824 — Write once C and forth structs

Is there a way to write once structs for both C and forth? Or at least 
some automagic conversion from one to another way? I find it quite 
tedious and stupid to write twice them.

I'm using gforth.

Best regards,
Hannu Vuolasaho

[toc] | [next] | [standalone]

#32826

Hannu Vuolasaho wrote:

> Is there a way to write once structs for both C and forth? Or at least
> some automagic conversion from one to another way? I find it quite
> tedious and stupid to write twice them.
> 
> I'm using gforth.

Gerald Wodni has a swig plugin which converts C structs into equivalent 
Forth.  However, swig at the moment is a bit stale, he has his branch in a 
Mercurial repository, instead of a git branch at github.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#32827

On 02.08.2014 14:47, Bernd Paysan wrote:
> Hannu Vuolasaho wrote:
>
>> Is there a way to write once structs for both C and forth? Or at least
>> some automagic conversion from one to another way? I find it quite
>> tedious and stupid to write twice them.
>>
>> I'm using gforth.
>
> Gerald Wodni has a swig plugin which converts C structs into equivalent
> Forth.  However, swig at the moment is a bit stale, he has his branch in a
> Mercurial repository, instead of a git branch at github.
>
I tried to search that. forth.wodni.at Which should be his forth page 
and logically place to look, doesn't resolv. Do you have URL for the repo?

Best regards,
Hannu Vuolasaho

[toc] | [prev] | [next] | [standalone]

#32828

Hannu Vuolasaho wrote:

> On 02.08.2014 14:47, Bernd Paysan wrote:
>> Hannu Vuolasaho wrote:
>>
>>> Is there a way to write once structs for both C and forth? Or at least
>>> some automagic conversion from one to another way? I find it quite
>>> tedious and stupid to write twice them.
>>>
>>> I'm using gforth.
>>
>> Gerald Wodni has a swig plugin which converts C structs into equivalent
>> Forth.  However, swig at the moment is a bit stale, he has his branch in
>> a Mercurial repository, instead of a git branch at github.
>>
> I tried to search that. forth.wodni.at Which should be his forth page
> and logically place to look, doesn't resolv. Do you have URL for the repo?

I did, but it doesn't work any longer. I'll check with Gerald.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#32830

On Saturday, August 2, 2014 4:47:38 AM UTC-7, Bernd Paysan wrote:
> Hannu Vuolasaho wrote:
> 
> > Is there a way to write once structs for both C and forth? Or at least
> > some automagic conversion from one to another way? 
> 
> Gerald Wodni has a swig plugin which converts C structs into equivalent 
> Forth.  

It would make more sense to me to go the other way --- from Forth to C. Interpreting the meaning of C code involves writing something like a C compiler!

This is a struct taken from my novice package:

0
    w field .lo
    w field .hi
constant double 

I think that you would want to change that into something like this:

0 struct
    w field .lo
    w field .hi
end-struct: double 

STRUCT doesn't do anything at all, and END-STRUCT: is just a synonym for CONSTANT.

Now, however, you can modify STRUCT FIELD and END-STRUCT: to generate C code and dump it into a text file. 

This is a pretty good idea; I think I will add this to the next novice package release. I actually thought of this some time ago, but never got around to doing it.

[toc] | [prev] | [next] | [standalone]

#32835

On Saturday, August 2, 2014 8:47:39 PM UTC-7, hughag...@yahoo.com wrote:
> This is a struct taken from my novice package:
> 
> 0
>     w field .lo
>     w field .hi
> constant double 
> 
> I think that you would want to change that into something like this:
> 
> 0 struct
>     w field .lo
>     w field .hi
> end-struct: double 
> 
> STRUCT doesn't do anything at all, and END-STRUCT: is just a synonym for CONSTANT.
> 
> Now, however, you can modify STRUCT FIELD and END-STRUCT: to generate C code and dump it into a text file. 
> 
> This is a pretty good idea; I think I will add this to the next novice package release. I actually thought of this some time ago, but never got around to doing it.

The big problem here, is that C structs are limited to always starting at 0. That is just one of the weird and pointless restrictions of C --- most likely none of the C designers knew what inheritance is.

Because of this, none of the structs in the novice package can be ported directly into C. Having a facility to port structs into C would only be useful if the the structs were written with C's restriction in mind --- and who is going to do that in Forth? --- this is why I never got around to implementing it.

[toc] | [prev] | [next] | [standalone]

#32838

On Mon, 04 Aug 2014 00:03:22 -0400, <hughaguilar96@yahoo.com> wrote:

> The big problem here, is that C structs are limited
> to always starting at 0.

What? ...

In fact, I have absolutely no idea what you're even
attempting to say here.  Please explain what you
mean by:

   "C structs are limited to always starting at 0".

Are you thinking of typedef's?  Even then, that
needs some explanation to know where you're coming
 from and what you're attempting to say.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#32843

Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
> On Mon, 04 Aug 2014 00:03:22 -0400, <hughaguilar96@yahoo.com> wrote:
> 
>> The big problem here, is that C structs are limited
>> to always starting at 0.
> 
> What? ...
> 
> In fact, I have absolutely no idea what you're even
> attempting to say here.  Please explain what you
> mean by:
> 
>   "C structs are limited to always starting at 0".

He's talking about type extension.  Like this in C++:

typedef struct {
  int one;
} a;

typedef struct : a {
  int two;
} b;

Here, struct b extends a.

Andrew.

[toc] | [prev] | [next] | [standalone]

#32847

Andrew Haley wrote:

> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
>> On Mon, 04 Aug 2014 00:03:22 -0400, <hughaguilar96@yahoo.com> wrote:
>> 
>>> The big problem here, is that C structs are limited
>>> to always starting at 0.
>> 
>> What? ...
>> 
>> In fact, I have absolutely no idea what you're even
>> attempting to say here.  Please explain what you
>> mean by:
>> 
>>   "C structs are limited to always starting at 0".
> 
> He's talking about type extension.  Like this in C++:
> 
> typedef struct {
>   int one;
> } a;
> 
> typedef struct : a {
>   int two;
> } b;
> 
> Here, struct b extends a.

Yes, this sort of stuff is pretty useful, so useful that I added it to the 
Forth200x structure implementation in Gforth:

: extend-structure ( n "name" -- struct-sys n ) \ Gforth
    \g extend an existing structure
    standard:field >r 0 value lastxt >body r> ;

And if you want to start a structure that extends nothing? Of course:

: begin-structure ( "name" -- struct-sys 0 ) \ X:structures
    0 extend-structure ;

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#32852

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Andrew Haley wrote:
>> He's talking about type extension.  Like this in C++:
>> 
>> typedef struct {
>>   int one;
>> } a;
>> 
>> typedef struct : a {
>>   int two;
>> } b;
>> 
>> Here, struct b extends a.
>
>Yes, this sort of stuff is pretty useful, so useful that I added it to the 
>Forth200x structure implementation in Gforth:
>
>: extend-structure ( n "name" -- struct-sys n ) \ Gforth
>    \g extend an existing structure
>    standard:field >r 0 value lastxt >body r> ;
>
>And if you want to start a structure that extends nothing? Of course:
>
>: begin-structure ( "name" -- struct-sys 0 ) \ X:structures
>    0 extend-structure ;

Or instead you could just do it as follows:

0
field: one
constant a

a
field: two
constant b

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#32857

On Tuesday, August 5, 2014 5:33:18 AM UTC-7, Anton Ertl wrote:
> Bernd Paysan <bernd.paysan@gmx.de> writes:
> >Yes, this sort of stuff is pretty useful, so useful that I added it to the 
> >Forth200x structure implementation in Gforth:
> 
> >: extend-structure ( n "name" -- struct-sys n ) \ Gforth
> >    \g extend an existing structure
> >    standard:field >r 0 value lastxt >body r> ;
> 
> >And if you want to start a structure that extends nothing? Of course:
> 
> >: begin-structure ( "name" -- struct-sys 0 ) \ X:structures
> >    0 extend-structure ;

> Or instead you could just do it as follows:
> 
> 0
> field: one
> constant a
> 
> a
> field: two
> constant b

That is what I do in my novice package. 

I have no idea what Bernd is talking about with his BEGIN-STRUCTURE and EXTEND-STRUCTURE --- I almost never know what he is talking about :-( --- his programming philosophy seems to be: "No matter how simple and straight-forward anything is, it can always be made complicated and opaque, and then version that should be written in stone as part of the Forth-200x standard!"

[toc] | [prev] | [next] | [standalone]

#32858

miercuri, 6 august 2014, 06:31:53 UTC+3, hughag...@yahoo.com a scris:
> On Tuesday, August 5, 2014 5:33:18 AM UTC-7, Anton Ertl wrote:
> 
> > Bernd Paysan <bernd.paysan@gmx.de> writes:
> 
> > >Yes, this sort of stuff is pretty useful, so useful that I added it to the 
> 
> > >Forth200x structure implementation in Gforth:
> 
> > 
> 
> > >: extend-structure ( n "name" -- struct-sys n ) \ Gforth
> 
> > >    \g extend an existing structure
> 
> > >    standard:field >r 0 value lastxt >body r> ;
> 
> > 
> 
> > >And if you want to start a structure that extends nothing? Of course:
> 
> > 
> 
> > >: begin-structure ( "name" -- struct-sys 0 ) \ X:structures
> 
> > >    0 extend-structure ;
> 
> 
> 
> > Or instead you could just do it as follows:
> 
> > 
> 
> > 0
> 
> > field: one
> 
> > constant a
> 
> > 
> 
> > a
> 
> > field: two
> 
> > constant b
> 
> 
> 
> That is what I do in my novice package. 
> 
> 
> 
> I have no idea what Bernd is talking about with his BEGIN-STRUCTURE and EXTEND-STRUCTURE --- I almost never know what he is talking about :-( --- his programming philosophy seems to be: "No matter how simple and straight-forward anything is, it can always be made complicated and opaque, and then version that should be written in stone as part of the Forth-200x standard!"


That's exactly the kind of structures that I implemented myself. They are so simple!
Here is a little sample from one of my test files:

\ STRUCTURES
0	2 field .x
	2 field .y
	2 +				\ reserved
struct TPoint 
TPoint              \ continued
    2 field .color
struct TPixel

TPoint buffer: pt1

0	TPoint field .rtop
	TPoint field .lbot
struct TRect
TRect buffer: rect1

And some usage:
	500 pt1 .x h!
	23 rect1 .rtop .y h!
	pt1 .x h@ .
	rect1 .rtop .y h@ .

The best part is that I have a literal optimization that will compile just a single literal for the "rect1 .rtop .y" part. That's because FIELD generates a macro that compiles a literal and a + at compile time.

Speaking of that, I really see a need for some kind of CREATE DOES> kind of thing but with the DOES> part being able to run at compile time, just in order to generate macros like that above. Something like CREATE COMPILES>

Or is it possible with the DOES> ? I'm not that good in this kind of stuff...

[toc] | [prev] | [next] | [standalone]

#32859

miercuri, 6 august 2014, 07:45:04 UTC+3, Raimond Dragomir a scris:
> miercuri, 6 august 2014, 06:31:53 UTC+3, hughag...@yahoo.com a scris:
> 
> > On Tuesday, August 5, 2014 5:33:18 AM UTC-7, Anton Ertl wrote:
> 
> > 
> 
> > > Bernd Paysan <bernd.paysan@gmx.de> writes:
> 
> > 
> 
> > > >Yes, this sort of stuff is pretty useful, so useful that I added it to the 
> 
> > 
> 
> > > >Forth200x structure implementation in Gforth:
> 
> > 
> 
> > > 
> 
> > 
> 
> > > >: extend-structure ( n "name" -- struct-sys n ) \ Gforth
> 
> > 
> 
> > > >    \g extend an existing structure
> 
> > 
> 
> > > >    standard:field >r 0 value lastxt >body r> ;
> 
> > 
> 
> > > 
> 
> > 
> 
> > > >And if you want to start a structure that extends nothing? Of course:
> 
> > 
> 
> > > 
> 
> > 
> 
> > > >: begin-structure ( "name" -- struct-sys 0 ) \ X:structures
> 
> > 
> 
> > > >    0 extend-structure ;
> 
> > 
> 
> > 
> 
> > 
> 
> > > Or instead you could just do it as follows:
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 0
> 
> > 
> 
> > > field: one
> 
> > 
> 
> > > constant a
> 
> > 
> 
> > > 
> 
> > 
> 
> > > a
> 
> > 
> 
> > > field: two
> 
> > 
> 
> > > constant b
> 
> > 
> 
> > 
> 
> > 
> 
> > That is what I do in my novice package. 
> 
> > 
> 
> > 
> 
> > 
> 
> > I have no idea what Bernd is talking about with his BEGIN-STRUCTURE and EXTEND-STRUCTURE --- I almost never know what he is talking about :-( --- his programming philosophy seems to be: "No matter how simple and straight-forward anything is, it can always be made complicated and opaque, and then version that should be written in stone as part of the Forth-200x standard!"
> 
> 
> 
> 
> 
> That's exactly the kind of structures that I implemented myself. They are so simple!
> 
> Here is a little sample from one of my test files:
> 
> 
> 
> \ STRUCTURES
> 
> 0	2 field .x
> 
> 	2 field .y
> 
> 	2 +				\ reserved
> 
> struct TPoint 
> 
> TPoint              \ continued
> 
>     2 field .color
> 
> struct TPixel
> 
> 
> 
> TPoint buffer: pt1
> 
> 
> 
> 0	TPoint field .rtop
> 
> 	TPoint field .lbot
> 
> struct TRect
> 
> TRect buffer: rect1
> 
> 
> 
> And some usage:
> 
> 	500 pt1 .x h!
> 
> 	23 rect1 .rtop .y h!
> 
> 	pt1 .x h@ .
> 
> 	rect1 .rtop .y h@ .
> 
> 
> 
> The best part is that I have a literal optimization that will compile just a single literal for the "rect1 .rtop .y" part. That's because FIELD generates a macro that compiles a literal and a + at compile time.
> 
> 
> 
> Speaking of that, I really see a need for some kind of CREATE DOES> kind of thing but with the DOES> part being able to run at compile time, just in order to generate macros like that above. Something like CREATE COMPILES>
> 
> 
> 
> Or is it possible with the DOES> ? I'm not that good in this kind of stuff...

By the way, STRUCT is really CONSTANT (a compiler synonym)

[toc] | [prev] | [next] | [standalone]

#32860

On Wednesday, August 6, 2014 7:45:04 AM UTC+3, Raimond Dragomir wrote:
> miercuri, 6 august 2014, 06:31:53 UTC+3, hughag...@yahoo.com a scris:
> 
> > On Tuesday, August 5, 2014 5:33:18 AM UTC-7, Anton Ertl wrote:
> 
> > 
> 
> > > Bernd Paysan writes:
> 
> > 
> 
> > > >Yes, this sort of stuff is pretty useful, so useful that I added it to the 
> 
> > 
> 
> > > >Forth200x structure implementation in Gforth:
> 
> > 
> 
> > > 
> 
> > 
> 
> > > >: extend-structure ( n "name" -- struct-sys n ) \ Gforth
> 
> > 
> 
> > > >    \g extend an existing structure
> 
> > 
> 
> > > >    standard:field >r 0 value lastxt >body r> ;
> 
> > 
> 
> > > 
> 
> > 
> 
> > > >And if you want to start a structure that extends nothing? Of course:
> 
> > 
> 
> > > 
> 
> > 
> 
> > > >: begin-structure ( "name" -- struct-sys 0 ) \ X:structures
> 
> > 
> 
> > > >    0 extend-structure ;
> 
> > 
> 
> > 
> 
> > 
> 
> > > Or instead you could just do it as follows:
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 0
> 
> > 
> 
> > > field: one
> 
> > 
> 
> > > constant a
> 
> > 
> 
> > > 
> 
> > 
> 
> > > a
> 
> > 
> 
> > > field: two
> 
> > 
> 
> > > constant b
> 
> > 
> 
> > 
> 
> > 
> 
> > That is what I do in my novice package. 
> 
> > 
> 
> > 
> 
> > 
> 
> > I have no idea what Bernd is talking about with his BEGIN-STRUCTURE and EXTEND-STRUCTURE --- I almost never know what he is talking about :-( --- his programming philosophy seems to be: "No matter how simple and straight-forward anything is, it can always be made complicated and opaque, and then version that should be written in stone as part of the Forth-200x standard!"
> 
> 
> 
> 
> 
> That's exactly the kind of structures that I implemented myself. They are so simple!
> 
> Here is a little sample from one of my test files:
> 
> 
> 
> \ STRUCTURES
> 
> 0	2 field .x
> 
> 	2 field .y
> 
> 	2 +				\ reserved
> 
> struct TPoint 
> 
> TPoint              \ continued
> 
>     2 field .color
> 
> struct TPixel
> 
> 
> 
> TPoint buffer: pt1
> 
> 
> 
> 0	TPoint field .rtop
> 
> 	TPoint field .lbot
> 
> struct TRect
> 
> TRect buffer: rect1
> 
> 
> 
> And some usage:
> 
> 	500 pt1 .x h!
> 
> 	23 rect1 .rtop .y h!
> 
> 	pt1 .x h@ .
> 
> 	rect1 .rtop .y h@ .
> 
> 
> 
> The best part is that I have a literal optimization that will compile just a single literal for the "rect1 .rtop .y" part. That's because FIELD generates a macro that compiles a literal and a + at compile time.
> 
> 
> 
> Speaking of that, I really see a need for some kind of CREATE DOES> kind of thing but with the DOES> part being able to run at compile time, just in order to generate macros like that above. Something like CREATE COMPILES>
> 
> 
> 
> Or is it possible with the DOES> ? I'm not that good in this kind of stuff...

Hi!
Maybe:

: define-compiler-word CREATE init-code IMMEDIATE DOES> compile-code ; ( compile-only )

Now compile-code may postpone words or open pandora-case and use text-expansion macros.

Have a nice day,
humptydumpty

[toc] | [prev] | [next] | [standalone]

#32863

On Tue, 05 Aug 2014 23:31:53 -0400, <hughaguilar96@yahoo.com> wrote:

> I have no idea what Bernd is talking about with his BEGIN-STRUCTURE and
> EXTEND-STRUCTURE --- I almost never know what he is talking about :-(
> --- his programming philosophy seems to be: "No matter how simple and
> straight-forward anything is, it can always be made complicated and
> opaque, and then [that version] should be written in stone as part of
> the Forth-200x standard!"

LOL.  The seven-year award for c.l.f. humor goes to Hugh!


RP

[toc] | [prev] | [next] | [standalone]

#32868

On Tuesday, August 5, 2014 5:33:18 AM UTC-7, Anton Ertl wrote:
> >Andrew Haley wrote:
> >> He's talking about type extension.  Like this in C++:
> 
> >> typedef struct {
> >>   int one;
> >> } a;
> 
> >> typedef struct : a {
> >>   int two;
> >> } b;
> 
> >> Here, struct b extends a.
> ...
> Or instead you could just do it as follows:
> 
> 0
> field: one
> constant a
> 
> a
> field: two
> constant b

You seem to understand inheritance, but yet you denounced my ALLOCATION RfD. The whole point of ALLOCATION is that CLONE-NODE will work no matter whether the node is a parent type or a child type --- ALLOCATION allows CLONE-NODE to determine how much memory needs to be copied over.

What you said at the time, was that ALLOCATION was impossible because GLIBC doesn't support it, and Gforth depends upon GLIBC for its heap implementation --- what a pathetic excuse! --- since when is Forth dependent upon C??? 

You only denounced ALLOCATION because Leon Wagner had killed it by saying that he wouldn't support it in SwiftForth --- the excuse was an afterthought.

[toc] | [prev] | [next] | [standalone]

#32848

On Mon, 04 Aug 2014 12:39:27 -0400, Andrew Haley  
<andrew29@littlepinkcloud.invalid> wrote:
> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
>> On Mon, 04 Aug 2014 00:03:22 -0400, <hughaguilar96@yahoo.com> wrote:

>>> The big problem here, is that C structs are limited
>>> to always starting at 0.
>>
>> What? ...
>>
>> In fact, I have absolutely no idea what you're even
>> attempting to say here.  Please explain what you
>> mean by:
>>
>>   "C structs are limited to always starting at 0".
>
> He's talking about type extension.  Like this in C++:
>
> typedef struct {
>   int one;
> } a;
>
> typedef struct : a {
>   int two;
> } b;
>
> Here, struct b extends a.
>

"C structs are limited to single, discrete instances."

C structs can be placed at any available memory location, i.e.,
start at a non-zero location.

So, "... starting with 0" really has nothing to do with this ...
It's just Hugh's bad choice of wording.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#32849

Le 04/08/2014 18:39, Andrew Haley a écrit :

> typedef struct {
>    int one;
> } a;
>
> typedef struct : a {
>    int two;
> } b;
>
> Here, struct b extends a.

How about this ?

typedef struct {
    a super;
    int two;
} b;

b foo;

b.super.one = 1;
b.two = 2;

sam.

[toc] | [prev] | [next] | [standalone]

#32856

On Monday, August 4, 2014 11:26:10 PM UTC-7, Samuel DEVULDER wrote:
> How about this ?
> 
> typedef struct {
>     a super;
>     int two;
> } b;
> 
> b foo;
> 
> b.super.one = 1;
> b.two = 2;

C is much acclaimed because giving everything a name is supposed to improve readability. Most of the time however, the names are like your SUPER --- they are totally meaningless and just bloat out the source-code with a lot of weird nonsense that the programmer has to remember to put in correctly to get the program to work.

Also, you can't use SUPER because it is too generic --- if you have more than one inheritance chain and/or they are more than one level deep, you can't use SUPER every time. What you are going to end up doing, is using a big collection of meaningless field names all distinct from each other --- and good luck remembering which to use in which circumstance!

Wouldn't this be a lot more readable?

b.one = 1;
b.two = 2;

One good thing about this, is that if you have a function that only access the .ONE field, it will work on any struct that is of type A or any child of A (such as B). That is pretty much the fundamental concept of OOP!

[toc] | [prev] | [next] | [standalone]

#32861

Le 06/08/2014 05:23, hughaguilar96@yahoo.com a écrit :

> Also, you can't use SUPER because it is too generic

Actually name it as you want. "Parent" whould do as well.

  --- if you have more than one inheritance

It is a bad idea according to some standards (diamond problem), but if 
you want some struct to be both some kind of type1 and type2, you can use:

typedef struct {
    union {
      type1 type1;
      type2 type2;
    } super;
    int one;
} a;

With that construct, if you want to access "a" as a type1, just use 
a.super.type1. Easy.

> chain and/or they are more than one level deep, you can't use SUPER every time.

If you had:

typedef struct [
    int bar;
} foo;

typdef struct {
    foo super;
    int one;
} a;

you can do of course b.super.super.bar, i.e. you can use any level of 
super as needed.

> What you are going to end up doing, is using a big collection of meaningless field names
 > all distinct from each other

I disagree with the "all distinct part": you can name all them super if 
you want (recall: a struct is a namespace on its own). And for 
meaningless, it is just as meaningless as the coder chooses the name to be.

> --- and good luck remembering which to use in which circumstance!
>
> Wouldn't this be a lot more readable?
>
> b.one = 1;
> b.two = 2;

Use macro-processing for this, but I tend to think it is hiding the real 
stuff behind. And IIRC some compilers have a non-standard notion of 
transparent struct/union just for that purpose as well.

> One good thing about this, is that if you have a function that only access the .ONE field

So this function needs an A, just pass b.super to that function (it is 
the expected A Part). It'll run just fine.

> , it will work on any struct that is of type A or any child of A (such as B).

The same goes with the super construct above. If you need the super 
"class", simply use b.super.

> That is pretty much the fundamental concept of OOP!

In C all you get is a way of structuring the data. But you wont have all 
the features of OOP languages.

In any case I was just posting to say that is is wrong that you cannot 
extend struct in C. It can and it does very easily.

regards,

sam.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web