Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #93474 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2016-09-14 12:01 -0700 |
| Last post | 2016-09-15 11:23 -0700 |
| Articles | 19 on this page of 99 — 14 participants |
Back to article view | Back to comp.lang.c
Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-14 12:01 -0700
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-14 13:15 -0700
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-14 13:27 -0700
Re: Sugestions for runtime polymorphism Richard Heathfield <rjh@cpax.org.uk> - 2016-09-14 21:50 +0100
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-14 14:20 -0700
Re: Sugestions for runtime polymorphism "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-14 17:32 -0400
Re: Sugestions for runtime polymorphism Keith Thompson <kst-u@mib.org> - 2016-09-14 16:30 -0700
Re: Sugestions for runtime polymorphism "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-14 17:54 -0400
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-14 17:34 -0700
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-14 17:58 -0700
Re: Sugestions for runtime polymorphism Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-14 19:50 -0700
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-15 05:03 -0700
Re: Sugestions for runtime polymorphism BartC <bc@freeuk.com> - 2016-09-15 10:43 +0100
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-15 05:29 -0700
Re: Sugestions for runtime polymorphism BartC <bc@freeuk.com> - 2016-09-15 19:49 +0100
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-15 11:58 -0700
Re: Sugestions for runtime polymorphism BartC <bc@freeuk.com> - 2016-09-15 20:29 +0100
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-15 14:00 -0700
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-16 07:27 -0700
Re: Sugestions for runtime polymorphism BartC <bc@freeuk.com> - 2016-09-16 16:34 +0100
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-16 09:36 -0700
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-20 12:59 -0700
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-20 14:08 -0700
Re: Sugestions for runtime polymorphism Ian Collins <ian-news@hotmail.com> - 2016-09-21 15:53 +1200
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-21 07:38 -0700
Re: Sugestions for runtime polymorphism Ian Collins <ian-news@hotmail.com> - 2016-09-23 09:12 +1200
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-21 05:26 -0700
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-21 05:35 -0700
Re: Sugestions for runtime polymorphism Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-21 06:01 -0700
Re: Sugestions for runtime polymorphism Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-22 01:44 -0700
Re: Sugestions for runtime polymorphism BartC <bc@freeuk.com> - 2016-09-22 13:16 +0100
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-22 08:02 -0700
Re: Sugestions for runtime polymorphism Keith Thompson <kst-u@mib.org> - 2016-09-22 11:44 -0700
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-22 09:52 -0700
Re: Sugestions for runtime polymorphism David Brown <david.brown@hesbynett.no> - 2016-09-23 09:49 +0200
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-23 07:55 -0700
Re: Sugestions for runtime polymorphism David Brown <david.brown@hesbynett.no> - 2016-09-24 16:29 +0200
Re: Sugestions for runtime polymorphism Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-24 15:56 +0100
Re: Sugestions for runtime polymorphism David Brown <david.brown@hesbynett.no> - 2016-09-24 17:50 +0200
Re: Sugestions for runtime polymorphism "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-24 13:45 -0400
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-24 11:26 -0700
Re: Sugestions for runtime polymorphism Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 10:38 -0700
Re: Sugestions for runtime polymorphism Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-24 21:03 +0100
Re: Sugestions for runtime polymorphism David Brown <david.brown@hesbynett.no> - 2016-09-25 12:43 +0200
Re: Sugestions for runtime polymorphism "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-25 11:48 -0400
Re: Sugestions for runtime polymorphism David Brown <david.brown@hesbynett.no> - 2016-09-25 18:39 +0200
Re: Sugestions for runtime polymorphism "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-25 13:14 -0400
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-25 13:47 -0700
Re: Sugestions for runtime polymorphism Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 10:39 -0700
Re: Sugestions for runtime polymorphism David Brown <david.brown@hesbynett.no> - 2016-09-25 23:25 +0200
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-25 13:10 -0700
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-25 12:55 -0700
Re: Sugestions for runtime polymorphism Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-25 20:38 +0100
Re: Sugestions for runtime polymorphism David Brown <david.brown@hesbynett.no> - 2016-09-25 23:20 +0200
Re: Sugestions for runtime polymorphism Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 07:15 -0700
Re: Sugestions for runtime polymorphism David Brown <david.brown@hesbynett.no> - 2016-09-28 21:29 +0200
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-24 10:52 -0700
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-24 10:33 -0700
Re: Sugestions for runtime polymorphism David Brown <david.brown@hesbynett.no> - 2016-09-25 12:46 +0200
Re: Sugestions for runtime polymorphism Keith Thompson <kst-u@mib.org> - 2016-09-24 13:58 -0700
Re: Sugestions for runtime polymorphism Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 04:46 -0700
Re: Sugestions for runtime polymorphism Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-24 00:07 -0700
Re: Sugestions for runtime polymorphism Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-23 08:52 -0700
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-23 09:56 -0700
Re: Sugestions for runtime polymorphism Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-23 12:00 -0700
Re: Sugestions for runtime polymorphism Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-22 08:45 -0700
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-22 09:36 -0700
Re: Sugestions for runtime polymorphism Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-23 12:06 -0700
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-23 15:29 -0700
Re: Sugestions for runtime polymorphism Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-29 07:56 -0700
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-30 10:54 -0700
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-30 11:18 -0700
Re: Sugestions for runtime polymorphism BartC <bc@freeuk.com> - 2016-09-30 19:26 +0100
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-30 12:41 -0700
Re: Sugestions for runtime polymorphism Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-30 21:07 +0100
Re: Sugestions for runtime polymorphism Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-30 23:30 -0700
Re: Sugestions for runtime polymorphism Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-01 11:35 +0100
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-10-01 14:44 -0700
Re: Sugestions for runtime polymorphism Richard Heathfield <rjh@cpax.org.uk> - 2016-09-14 22:56 +0100
Re: Sugestions for runtime polymorphism David Brown <david.brown@hesbynett.no> - 2016-09-15 13:19 +0200
Re: Sugestions for runtime polymorphism James Kuyper <jameskuyper@verizon.net> - 2016-09-15 08:07 -0400
Re: Sugestions for runtime polymorphism David Brown <david.brown@hesbynett.no> - 2016-09-15 14:24 +0200
Re: Sugestions for runtime polymorphism Richard Heathfield <rjh@cpax.org.uk> - 2016-09-15 15:34 +0100
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-15 05:10 -0700
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-15 09:12 -0700
Re: Sugestions for runtime polymorphism BartC <bc@freeuk.com> - 2016-09-14 23:32 +0100
Re: Sugestions for runtime polymorphism "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-09-14 17:35 -0700
Re: Sugestions for runtime polymorphism Ian Collins <ian-news@hotmail.com> - 2016-09-15 16:24 +1200
Re: Sugestions for runtime polymorphism Keith Thompson <kst-u@mib.org> - 2016-09-15 10:31 -0700
Re: Sugestions for runtime polymorphism BartC <bc@freeuk.com> - 2016-09-14 22:53 +0100
Re: Sugestions for runtime polymorphism Keith Thompson <kst-u@mib.org> - 2016-09-14 16:56 -0700
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-14 15:58 -0700
Re: Sugestions for runtime polymorphism Keith Thompson <kst-u@mib.org> - 2016-09-14 18:49 -0700
Re: Sugestions for runtime polymorphism luser droog <luser.droog@gmail.com> - 2016-09-14 14:17 -0700
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-14 14:25 -0700
Re: Sugestions for runtime polymorphism luser droog <luser.droog@gmail.com> - 2016-09-14 14:40 -0700
Re: Sugestions for runtime polymorphism luser droog <luser.droog@gmail.com> - 2016-09-14 14:57 -0700
Re: Sugestions for runtime polymorphism BartC <bc@freeuk.com> - 2016-09-14 23:10 +0100
Re: Sugestions for runtime polymorphism Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-15 11:23 -0700
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-09-15 08:07 -0400 |
| Message-ID | <nre2ui$ht4$1@dont-email.me> |
| In reply to | #93530 |
On 09/15/2016 07:19 AM, David Brown wrote: ... > You might still frown - after all, recommending C++ is blasphemy in > c.l.c There's no concept of blasphemy here (Rick Hodgins excluded). We're all mostly in agreement that there's at least a few contexts where C is most appropriate, but holding that belief doesn't have to blind you to the fact that other languages are also sometimes more appropriate.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-15 14:24 +0200 |
| Message-ID | <nre3t8$lnf$1@dont-email.me> |
| In reply to | #93532 |
On 15/09/16 14:07, James Kuyper wrote: > On 09/15/2016 07:19 AM, David Brown wrote: > ... >> You might still frown - after all, recommending C++ is blasphemy in >> c.l.c > > There's no concept of blasphemy here (Rick Hodgins excluded). We're all > mostly in agreement that there's at least a few contexts where C is most > appropriate, but holding that belief doesn't have to blind you to the > fact that other languages are also sometimes more appropriate. > It was a joke, and I'm pretty sure Richard took it as such - but perhaps a smiley would have been in order. I know fine that most people here are perfectly happy to accept that C is not always the best language to choose.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-09-15 15:34 +0100 |
| Message-ID | <nrebi7$ghc$2@dont-email.me> |
| In reply to | #93535 |
On 15/09/16 13:24, David Brown wrote: > On 15/09/16 14:07, James Kuyper wrote: >> On 09/15/2016 07:19 AM, David Brown wrote: >> ... >>> You might still frown - after all, recommending C++ is blasphemy in >>> c.l.c >> >> There's no concept of blasphemy here (Rick Hodgins excluded). We're all >> mostly in agreement that there's at least a few contexts where C is most >> appropriate, but holding that belief doesn't have to blind you to the >> fact that other languages are also sometimes more appropriate. >> > > It was a joke, and I'm pretty sure Richard took it as such It's no laughing matter. The Cabal* has been informed. *TINC -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-09-15 05:10 -0700 |
| Message-ID | <0bb4f6c8-ef59-4e6b-8ae7-e8657bcbaa04@googlegroups.com> |
| In reply to | #93530 |
On Thursday, September 15, 2016 at 8:19:22 AM UTC-3, David Brown wrote: > On 14/09/16 23:56, Richard Heathfield wrote: > > On 14/09/16 22:20, Thiago Adams wrote: > >> On Wednesday, September 14, 2016 at 5:50:50 PM UTC-3, Richard > >> Heathfield > Did you mean TypeSpecifier? In my experience, > >> mis-spellings are best > >>> corrected sooner rather than later, before they pollute the whole > >>> code base. > >> > >> Yes! > >> > >>> Why not just: > >>> > >>> SimpleTypeSpecifer * p = malloc(sizeof *p); > >> > >> I use visual C++, and I compile the same code in C and C++. For the > >> Microsoft compilers, the C++ version is usually better. (Produces > >> more error messages and faster exe) So the "C/C++ version" requires > >> more casts. > > > > Um, okay, can we just take it as read that I'm wearing a mean, frowning > > expression, and leave it at that? I doubt very much whether I'd change > > your mind. But if it were me, I'd implement it as a C library, compile > > it under C rules, and then use C++'s "extern C" thing to link it in. > > > > The obvious alternative would be to write the whole thing in C++ rather > than C, and use a class hierarchy rather than a DIY solution with > unions, enums, etc. > > You might still frown - after all, recommending C++ is blasphemy in > c.l.c - but at least the language and the compiler would be consistent. > > (And don't newer versions of MSVS use clang for C, which is a perfectly > good C tool?) > I want to create a C static analyser and use it in its own code.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-15 09:12 -0700 |
| Message-ID | <f269243b-fd32-4679-979d-6fe05f391fd8@googlegroups.com> |
| In reply to | #93501 |
On Wednesday, September 14, 2016 at 4:56:23 PM UTC-5, Richard Heathfield wrote:
> On 14/09/16 22:20, Thiago Adams wrote:
> > Yes. This would be my next question. How do you handle memory failure
> > in your programs.
>
> Let the caller decide. Always. A library routine should detect memory
> failure and report it to the caller. It should never arbitrarily abort,
> and it should never ignore the possibility of failure. The caller knows
> far better than you do what the library is being used for (even -- and
> perhaps especially -- if the caller is being written /by you/, six
> months from now).
Both of the following guarantees from a memory-allocation function
would be useful, but it would be impossible for an implementation to
honor both of them except in a narrow set of cases:
1. A call to the memory-allocation function will return (never hanging,
crashing, etc.)
2. A call to the memory-allocation function will never return anything
other than a pointer to an otherwise-unused block of the requested
size.
In cases where a program would be unable to do anything useful in case of
an allocation failure other than exiting without making any stray memory
accesses, the second guarantee may be much more useful than the first.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-14 23:32 +0100 |
| Message-ID | <nrcj5m$uev$1@dont-email.me> |
| In reply to | #93491 |
On 14/09/2016 22:20, Thiago Adams wrote:
> But the question is general.
> If you need 0..N shapes and a shape can be rectangle , circle or ellipse how would you do?
enum {rectangle, circle, ellipse} Shape_id;
typedef struct {
Shape_id shapetype;
union { // data for the different kinds of shape
//....
}
} Shape;
I used this (or a scheme along these lines) in real projects in the
1980s. Probably now people prefer an OO approach but the above is simple
and easy to understand.
But I'd be wary of assuming that such a system can be simply adapted for
implementing dynamic types (if that is what you're attempting; it's not
clear).
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-09-14 17:35 -0700 |
| Message-ID | <nrcqct$gfd$1@dont-email.me> |
| In reply to | #93491 |
On 9/14/2016 2:20 PM, Thiago Adams wrote:
> On Wednesday, September 14, 2016 at 5:50:50 PM UTC-3, Richard Heathfield > Did you mean TypeSpecifier? In my experience, mis-spellings are best
>> corrected sooner rather than later, before they pollute the whole code base.
>
> Yes!
>
>> Why not just:
>>
>> SimpleTypeSpecifer * p = malloc(sizeof *p);
>
> I use visual C++, and I compile the same code in C and C++. For the Microsoft compilers, the C++ version is usually better. (Produces more error messages and faster exe)
> So the "C/C++ version" requires more casts.
>
> But this:
> SimpleTypeSpecifer * p = (SimpleTypeSpecifer *) malloc(sizeof *p);
>
> works. I liked it.
>
>> You forgot something important. This should be:
>>
>> if(p != NULL)
>> {
>> p->object.type = type;
>> }
>>
>>> return p;
>>> }
>
> Yes. This would be my next question.
> How do you handle memory failure in your programs.
>
> This is a parser program. Probably the best thing to do is exit on memory failure. But I may regret this decision in the future.
>
>
>> This seems like a lot of trouble to take over types. Why not just trust
>> that the user-programmer knows what type he put into the array, and that
>> he'll know to take that type out again?
>
> This is a runtime problem. Nobody knows what the types are there...we need some runtime "id" and them cast.
> This will be AST for the C language. I need visit the nodes after.
>
> But the question is general.
> If you need 0..N shapes and a shape can be rectangle , circle or ellipse how would you do?
I like Richard Heathfield's solution much better wrt shapes, but the
following just might be of interest to you:
http://pastebin.com/f52a443b1
;^)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-09-15 16:24 +1200 |
| Message-ID | <e3um34F1l4bU3@mid.individual.net> |
| In reply to | #93491 |
On 09/15/16 09:20 AM, Thiago Adams wrote: > On Wednesday, September 14, 2016 at 5:50:50 PM UTC-3, Richard Heathfield > Did you mean TypeSpecifier? In my experience, mis-spellings are best >> corrected sooner rather than later, before they pollute the whole code base. > > Yes! > >> Why not just: >> >> SimpleTypeSpecifer * p = malloc(sizeof *p); > > I use visual C++, and I compile the same code in C and C++. For the Microsoft compilers, the C++ version is usually better. (Produces more error messages and faster exe) > So the "C/C++ version" requires more casts. > In that case, why not just use C++ and the polymorphism issues becomes moot. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-15 10:31 -0700 |
| Message-ID | <lnwpid2hob.fsf@kst-u.example.com> |
| In reply to | #93522 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Ian Collins <ian-news@hotmail.com> writes:
>>In that case, why not just use C++ and the polymorphism issues becomes moot.
>
> That would agree well with the style guidelines:
>
> »CPL.1: Prefer C++ to C«
>
> github.com/isocpp/CppCoreGuidelines
That's a set of guidelines for coding *in C++*. I'm surprised they
even bother to mention that.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-14 22:53 +0100 |
| Message-ID | <nrcgs8$jrc$1@dont-email.me> |
| In reply to | #93485 |
On 14/09/2016 21:27, Thiago Adams wrote:
> This sample compiles and run.
It might do but I find it very difficult to follow!
> typedef enum {
> ObjectType_TypeSpecifer_Void,
> ObjectType_TypeSpecifer_Char,
> ObjectType_TypeSpecifer_Struct,
> ObjectType_TypeSpecifer_Enum,
> } ObjectType;
These names are far too long-winded (and badly spelled as has been
pointed out). The important bits of these names - the Void, Char, Struct
and Enum portions - are dominated by that 'ObjectType_TypeSpecifer'
prefix, which is easy to get mixed up with all the other names that also
use 'Object', 'Type' and 'Specifer'. (And 'Type' occurs twice.)
(In my own code where I want have a similar bunch of type enums, I would
just use t_void, t_char, etc. But I do have a rather concise style. I
also dislike typing.)
> typedef struct
> {
> ObjectType type;
> } Object;
So, ObjectType is just an int. And you're creating an entire struct just
to store that int, which designates a kind of object I presume. And
you're calling that struct an Object, while is a little misleading as it
doesn't contain or point to any actual data of type 'type'.
> typedef struct
> {
> Object object;
> } SimpleTypeSpecifer;
Now you're taking that int and wrapping it in yet another layer of struct!
> SimpleTypeSpecifer* SimpleTypeSpecifer_Create(ObjectType type)
> {
> SimpleTypeSpecifer * p = (SimpleTypeSpecifer *)malloc(sizeof(SimpleTypeSpecifer));
> p->object.type = type;
> return p;
> }
Now, you have a function that allocates heap storage for that int.
That is, you've taken an enum (an int really), which encodes the type of
an object, wrapped it into two layers of struct, and used dynamic
allocation for those 4 bytes.
However, is SimpleTypeSpecifer supposed to contain any actual data, or
any simple type, as at the moment it contains only a type tag?
> typedef struct
> {
> Object object;
> //more data...
> } StructTypeSpecifer;
This is more promising: perhaps that '//more data...' will contain
something useful.
> typedef struct
> {
> Object object;
> //more data...
> } EnumTypeSpecifer;
>
> typedef union
> {
> Object* pObject;
> SimpleTypeSpecifer* pSimpleTypeSpecifer;
> EnumTypeSpecifer* pEnumTypeSpecifer;
> StructTypeSpecifer* pStructTypeSpecifer;
> } TypeSpecifier;
What's the purpose of Object* here? All those other fields already point
to a struct that *contain* Object as their first element, but here you
also have an Object directly.
Is it to have a way of referring to the Object type tag that is at the
start of all these structs, without needing to know which of .pObject,
.pEnumTypeSpecifer etc need to be used?
> int main()
> {
> //Some array
> TypeSpecifier specifiers[1];
> //Everthing added as "Object"
> specifiers[0].pObject = (Object*)SimpleTypeSpecifer_Create(ObjectType_TypeSpecifer_Void);
As 'Object' or 'SimpleTypeSpecifer'? These appear to be doing similar
jobs. And which of them corresponds to ..._Void, and ..._Char? As I
can't see a VoidTypeSpecifer or CharTypeSpecifer struct.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-14 16:56 -0700 |
| Message-ID | <lninty3ujj.fsf@kst-u.example.com> |
| In reply to | #93499 |
BartC <bc@freeuk.com> writes:
> On 14/09/2016 21:27, Thiago Adams wrote:
[...]
>> typedef struct
>> {
>> ObjectType type;
>> } Object;
>
> So, ObjectType is just an int. And you're creating an entire struct just
> to store that int, which designates a kind of object I presume. And
> you're calling that struct an Object, while is a little misleading as it
> doesn't contain or point to any actual data of type 'type'.
A small quibble that doesn't affect your argument: ObjectType (which was
defined as an enumerated type) is an integer type, but it's not an int.
It's compatible with (not identical with) *some* predefined integer
type, but the choice is implementation-defined. (gcc, for example,
makes it compatible with unsigned int.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-14 15:58 -0700 |
| Message-ID | <552f7fcd-4ea8-40cf-a33e-47d4b9a9da27@googlegroups.com> |
| In reply to | #93503 |
On Wednesday, September 14, 2016 at 5:07:07 PM UTC-5, Keith Thompson wrote: > A small quibble that doesn't affect your argument: ObjectType (which was > defined as an enumerated type) is an integer type, but it's not an int. > It's compatible with (not identical with) *some* predefined integer > type, but the choice is implementation-defined. (gcc, for example, > makes it compatible with unsigned int.) If the enum is used only as a means of assigning labels for constants but is never used as an lvalue type, it generally won't matter what type a compiler decides to use for it. If one wants to target a dialect of C or C++ which does not allow one to specify the underlying type, declaring storage of the desired underlying type may be less elegant than declaring it as the enum type, but it allows one to control how things are stored. Additionally, if one will need to perform math or bitwise operations on an enum, using integer lvalues consistently will allow such operations to be performed without typecasts.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-14 18:49 -0700 |
| Message-ID | <lneg4m3pa0.fsf@kst-u.example.com> |
| In reply to | #93506 |
supercat@casperkitty.com writes:
> On Wednesday, September 14, 2016 at 5:07:07 PM UTC-5, Keith Thompson wrote:
>> A small quibble that doesn't affect your argument: ObjectType (which was
>> defined as an enumerated type) is an integer type, but it's not an int.
>> It's compatible with (not identical with) *some* predefined integer
>> type, but the choice is implementation-defined. (gcc, for example,
>> makes it compatible with unsigned int.)
>
> If the enum is used only as a means of assigning labels for constants but is
> never used as an lvalue type, it generally won't matter what type a compiler
> decides to use for it.
What is an "lvalue type"? An lvalue is a kind of expression. I think
what you mean is "... never used for objects" -- but even that's not
quite accurate, since you can certainly define objects of an enumerated
type without caring about its representation.
I suggest the real criterion is simply whether you care about the object
representation.
> If one wants to target a dialect of C or C++ which
> does not allow one to specify the underlying type, declaring storage of the
> desired underlying type may be less elegant than declaring it as the enum
> type, but it allows one to control how things are stored.
I won't get into C++, but a "dialect" of C that doesn't allow the
underlying type to be specified is the one most of us call "C" (or
perhaps "ISO C" if we're being more explicit).
> Additionally, if
> one will need to perform math or bitwise operations on an enum, using integer
> lvalues consistently will allow such operations to be performed without
> typecasts.
(I presume you mean "casts", which is what explicit conversions are
really called.)
If you care about the representation, you can certainly use both an
enumerated type and a specific integer type together:
enum {
E0 = 0x0001,
E1 = 0x0002,
E2 = 0x0004,
E3 = 0x0008,
/* ... */
};
uint16_t foo = E0, bar = E2;
It's unfortunate that the values can't be outside the range
INT_MIN..INT_MAX.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-09-14 14:17 -0700 |
| Message-ID | <cc1b9c3e-76df-4ae5-9802-2b9d99aeb354@googlegroups.com> |
| In reply to | #93474 |
On Wednesday, September 14, 2016 at 2:01:49 PM UTC-5, Thiago Adams wrote: > I need to create an array of "TypeSpecifiers" that are polymorphic. I have the list of all possible types. > > Does anyone have suggestions to implement this? > Here's an overview of the object structure in my PostScript interpreter. Each object carries a small integer which is used like an enum (mostly). http://stackoverflow.com/a/6971534/733077 Another writeup of the same idea: http://stackoverflow.com/a/26773579/733077 For the entire evolution of the idea, see this thread: https://groups.google.com/d/topic/comp.lang.postscript/VsFzRwnuM_E/discussion
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-09-14 14:25 -0700 |
| Message-ID | <c0d123f6-6075-408c-bfa0-fcb317597023@googlegroups.com> |
| In reply to | #93490 |
On Wednesday, September 14, 2016 at 6:17:22 PM UTC-3, luser droog wrote: > On Wednesday, September 14, 2016 at 2:01:49 PM UTC-5, Thiago Adams wrote: > > I need to create an array of "TypeSpecifiers" that are polymorphic. I have the list of all possible types. > > > > Does anyone have suggestions to implement this? > > > > Here's an overview of the object structure in my PostScript interpreter. > Each object carries a small integer which is used like an enum (mostly). > http://stackoverflow.com/a/6971534/733077 > > Another writeup of the same idea: > http://stackoverflow.com/a/26773579/733077 > > For the entire evolution of the idea, see this thread: > https://groups.google.com/d/topic/comp.lang.postscript/VsFzRwnuM_E/discussion Do you use a "variant" type? I think this is a good solution only if the objects have similar sizes, otherwise memory is wasted.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-09-14 14:40 -0700 |
| Message-ID | <7e049d97-aef6-4d50-932d-e659c15a4940@googlegroups.com> |
| In reply to | #93493 |
On Wednesday, September 14, 2016 at 4:26:06 PM UTC-5, Thiago Adams wrote: > On Wednesday, September 14, 2016 at 6:17:22 PM UTC-3, luser droog wrote: > > On Wednesday, September 14, 2016 at 2:01:49 PM UTC-5, Thiago Adams wrote: > > > I need to create an array of "TypeSpecifiers" that are polymorphic. I have the list of all possible types. > > > > > > Does anyone have suggestions to implement this? > > > > > > > Here's an overview of the object structure in my PostScript interpreter. > > Each object carries a small integer which is used like an enum (mostly). > > http://stackoverflow.com/a/6971534/733077 > > > > Another writeup of the same idea: > > http://stackoverflow.com/a/26773579/733077 > > > > For the entire evolution of the idea, see this thread: > > https://groups.google.com/d/topic/comp.lang.postscript/VsFzRwnuM_E/discussion > > Do you use a "variant" type? > I think this is a good solution only if the objects have similar sizes, otherwise memory is wasted. I've been evolving the idea through other projects, and the APL one does it a little differently, but always for reference types, the object contains not a pointer but an index into a table of allocation records (which contains the pointer). For the APL interpreter, I squeezed the tag-union into one 32bit int. http://codereview.stackexchange.com/q/140994/5912 There are some unused bits lying around that might be swept up later.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-09-14 14:57 -0700 |
| Message-ID | <fea99d45-bffe-44e7-9059-3d976f655f50@googlegroups.com> |
| In reply to | #93493 |
On Wednesday, September 14, 2016 at 4:26:06 PM UTC-5, Thiago Adams wrote: > On Wednesday, September 14, 2016 at 6:17:22 PM UTC-3, luser droog wrote: > > On Wednesday, September 14, 2016 at 2:01:49 PM UTC-5, Thiago Adams wrote: > > > I need to create an array of "TypeSpecifiers" that are polymorphic. I have the list of all possible types. > > > > > > Does anyone have suggestions to implement this? > > > > > > > Here's an overview of the object structure in my PostScript interpreter. > > Each object carries a small integer which is used like an enum (mostly). > > http://stackoverflow.com/a/6971534/733077 > > > > Another writeup of the same idea: > > http://stackoverflow.com/a/26773579/733077 > > > > For the entire evolution of the idea, see this thread: > > https://groups.google.com/d/topic/comp.lang.postscript/VsFzRwnuM_E/discussion > > Do you use a "variant" type? Yes, exactly, tag-union is a more common name in the C world, I think, because it tells you how it's implemented. > I think this is a good solution only if the objects have similar sizes, otherwise memory is wasted. Yes. That's the challenge of design a memory record structure so that the tokens of interest /do/ have similar sizes.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-14 23:10 +0100 |
| Message-ID | <nrchsv$qld$1@dont-email.me> |
| In reply to | #93493 |
On 14/09/2016 22:25, Thiago Adams wrote:
> On Wednesday, September 14, 2016 at 6:17:22 PM UTC-3, luser droog wrote:
>> On Wednesday, September 14, 2016 at 2:01:49 PM UTC-5, Thiago Adams wrote:
>>> I need to create an array of "TypeSpecifiers" that are polymorphic. I have the list of all possible types.
>>>
>>> Does anyone have suggestions to implement this?
>>>
>>
>> Here's an overview of the object structure in my PostScript interpreter.
>> Each object carries a small integer which is used like an enum (mostly).
>> http://stackoverflow.com/a/6971534/733077
>>
>> Another writeup of the same idea:
>> http://stackoverflow.com/a/26773579/733077
>>
>> For the entire evolution of the idea, see this thread:
>> https://groups.google.com/d/topic/comp.lang.postscript/VsFzRwnuM_E/discussion
>
> Do you use a "variant" type?
> I think this is a good solution only if the objects have similar sizes, otherwise memory is wasted.
I use a 'variant' type but within the context of an interpreted
language; not for direct use within the implementation language (eg. C)
where the following would be unwieldy.
Probably not very efficient but in outline it's something like this:
typedef struct { // usually 16 bytes in total
int tag; // type indicator
union {
int64_t value;
uint64_t uvalue;
double xvalue;
object* objptr;
}
} variant;
The stack-based execution model pushes and pops variant structs.
Anything other than a simple type (void, integer, float) uses a pointer
to heap-allocated storage of an 'object' descriptor. This is currently a
fixed 32-byte struct for all such types for simplicity.
However, your array descriptor you posted elsewhere is 24 bytes on
64-bit systems, so is not far off 32 bytes.
The objects descriptor contains bounds, allocate sizes and pointers to
the actual data, also on the heap. (For this system, there is also a
reference count).
Object types includes dynamic and extendible data such as lists (arrays
of variants), strings, sets, dicts, as well as arrays of 'packed' types
like C arrays, but flexible.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-15 11:23 -0700 |
| Message-ID | <kfnwpidggy5.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #93474 |
Thiago Adams <thiago.adams@gmail.com> writes: > I need to create an array of "TypeSpecifiers" that are polymorphic. > I have the list of all possible types. > > Does anyone have suggestions to implement this? > [snip proposal sketch] I have several suggestions (given with the benefit of having read some of the downstream articles). 1. Don't write code in the common intersection of C and C++. Write code in C, or write code in C++, but don't try to write in the common intersection. 2. For what you want to do, probably C++ is a better fit. Just use classes and virtual functions. You won't need unions, and if done right you probably won't need any integer type tags either (although that may depend on how the items are processed). 3. In any case don't use unions. They aren't the right tool here. 4. If you can, avoid the use of integer type tags, but in any case don't discriminate on those type tags in open code. What this means most importantly is don't be casting all over the place to access type-specific fields. Wrap type-specific access in functions, and call those functions in ways that are guaranteed by construction to be type safe. 5. There are well-known ways to do dynamic polymorphism (called by some object-oriented programming) in C. In fact I coded up a short example and was considering posting it until I noticed that it wouldn't meet your condition of being written in the common intersection of C and C++. (The example uses designated initializers and compound literals, neither of which is any version of C++.) If you decide to go ahead in C, I suggest looking into these techniques further, and adapting one to your needs. 6. If you decide to go ahead in the common intersection of C and C++, I recommend looking for a good therapist.
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.c
csiph-web