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

Groups > comp.lang.c > #109191 > unrolled thread

Approach to create/use containers in C

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

Contents

  Approach to create/use containers in C Thiago Adams <thiago.adams@gmail.com> - 2017-05-04 06:13 -0700
    Re: Approach to create/use containers in C Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-04 09:27 -0400
    Re: Approach to create/use containers in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 15:26 +0200
    Re: Approach to create/use containers in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 15:29 +0200
      Re: Approach to create/use containers in C Thiago Adams <thiago.adams@gmail.com> - 2017-05-04 06:40 -0700
        Re: Approach to create/use containers in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 15:49 +0200
        Re: Approach to create/use containers in C bartc <bc@freeuk.com> - 2017-05-04 16:38 +0100
          Re: Approach to create/use containers in C Thiago Adams <thiago.adams@gmail.com> - 2017-05-04 09:59 -0700
            Re: Approach to create/use containers in C bartc <bc@freeuk.com> - 2017-05-04 18:45 +0100
              Re: Approach to create/use containers in C Thiago Adams <thiago.adams@gmail.com> - 2017-05-05 10:22 -0700
    Re: Approach to create/use containers in C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-04 06:33 -0700
      Re: Approach to create/use containers in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 15:40 +0200
        Re: Approach to create/use containers in C Thiago Adams <thiago.adams@gmail.com> - 2017-05-04 06:54 -0700
          Re: Approach to create/use containers in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 16:06 +0200
    Re: Approach to create/use containers in C Richard Heathfield <rjh@cpax.org.uk> - 2017-05-04 15:46 +0100
      Re: Approach to create/use containers in C Thiago Adams <thiago.adams@gmail.com> - 2017-05-04 07:50 -0700
        Re: Approach to create/use containers in C Richard Heathfield <rjh@cpax.org.uk> - 2017-05-04 16:10 +0100
        Re: Approach to create/use containers in C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-04 08:18 -0700
          Re: Approach to create/use containers in C Thiago Adams <thiago.adams@gmail.com> - 2017-05-04 09:48 -0700
            Re: Approach to create/use containers in C Richard Heathfield <rjh@cpax.org.uk> - 2017-05-04 17:55 +0100
            Re: Approach to create/use containers in C Ike Naar <ike@iceland.freeshell.org> - 2017-05-04 22:04 +0000
          Re: Approach to create/use containers in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-04 20:03 +0100
            Re: Approach to create/use containers in C Thiago Adams <thiago.adams@gmail.com> - 2017-05-04 12:25 -0700
              Re: Approach to create/use containers in C Robert Wessel <robertwessel2@yahoo.com> - 2017-05-04 15:03 -0500
                Re: Approach to create/use containers in C Thiago Adams <thiago.adams@gmail.com> - 2017-05-04 13:09 -0700
          Re: Approach to create/use containers in C Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 01:34 -0700
        Re: Approach to create/use containers in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 17:17 +0200
      Re: Approach to create/use containers in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-04 19:36 +0100
    Re: Approach to create/use containers in C Robert Wessel <robertwessel2@yahoo.com> - 2017-05-04 12:09 -0500
      Re: Approach to create/use containers in C Robert Wessel <robertwessel2@yahoo.com> - 2017-05-04 12:17 -0500
        Re: Approach to create/use containers in C Thiago Adams <thiago.adams@gmail.com> - 2017-05-04 10:30 -0700
          Re: Approach to create/use containers in C Ian Collins <ian-news@hotmail.com> - 2017-05-05 07:50 +1200
        Re: Approach to create/use containers in C Keith Thompson <kst-u@mib.org> - 2017-05-04 11:29 -0700
        Re: Approach to create/use containers in C Andreas Perstinger <andipersti@gmail.com> - 2017-05-04 18:34 +0000
          Re: Approach to create/use containers in C Robert Wessel <robertwessel2@yahoo.com> - 2017-05-04 15:07 -0500
    Re: Approach to create/use containers in C Doug Weiman <no@nyet.net> - 2017-05-04 21:19 +0000
      Re: Approach to create/use containers in C Keith Thompson <kst-u@mib.org> - 2017-05-04 14:41 -0700
        Re: Approach to create/use containers in C Doug Weiman <no@nyet.net> - 2017-05-04 22:30 +0000
    Re: Approach to create/use containers in C "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2017-05-04 21:47 +0000
    Re: Approach to create/use containers in C luser droog <luser.droog@gmail.com> - 2017-05-05 00:43 -0700

Page 2 of 2 — ← Prev page 1 [2]

#109277

On 2017-05-04, Thiago Adams <thiago.adams@gmail.com> wrote:
> In one javascript project I worked, it took 6 months to find all bugs 
> caused by a refactoring. 

How about the ones you haven't found yet?

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

#109250

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Thursday, May 4, 2017 at 3:50:54 PM UTC+1, Thiago Adams wrote:
>> 
>> I think the bad point of this solution is performance because 
>> it is more dynamic. Also less type check.
>>
> You can't type check, but people make far too much fuss about "type safety",
> because it happens to be a programming error that is easy for the compiler
> to catch.

That's very much a C (and C-like) language perspective.  Even for some
relatively natural type systems, type checking can be undecidable and it
is often NP-complete.  But you are right that it is often made easy to
check.

Of course that's, in part, what makes it something that is over fussed
about in that the fuss is more justifiable, the less easy the
type-checking is.  At the far end of that spectrum would be a type
system in which type-checking the program is equivalent to proving the
program semantically correct.

> In Javascript you don't have it, because "duck typing" is easier
> for the interpreter to implement. And a bug that involves reinterpreting bits
> as the wrong type will usually come out very early.

JavaScript (AKA EcmaScript) does have type checking -- just very little
of it.

<snip>
-- 
Ben.

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

#109252

On Thursday, May 4, 2017 at 4:03:16 PM UTC-3, Ben Bacarisse wrote:
> Malcolm McLean  writes:
> 
> > On Thursday, May 4, 2017 at 3:50:54 PM UTC+1, Thiago Adams wrote:
> >> 
> >> I think the bad point of this solution is performance because 
> >> it is more dynamic. Also less type check.
> >>
> > You can't type check, but people make far too much fuss about "type safety",
> > because it happens to be a programming error that is easy for the compiler
> > to catch.
> 
> That's very much a C (and C-like) language perspective.  Even for some
> relatively natural type systems, type checking can be undecidable and it
> is often NP-complete.  But you are right that it is often made easy to
> check.
> 
> Of course that's, in part, what makes it something that is over fussed
> about in that the fuss is more justifiable, the less easy the
> type-checking is.  At the far end of that spectrum would be a type
> system in which type-checking the program is equivalent to proving the
> program semantically correct.

When I know that the compiler will not check type for me, 
for instance a cast, I create a "cast" macro.
For instance:

#define Type1_As_Type2(p) ((Type2*)p)

Then let's say Type2 cannot be converted to Type1 anymore.
I just delete the macro and the compiler will show where the 
cast is not allowed anymore because it will not find the macro.

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

#109258

On Thu, 4 May 2017 12:25:35 -0700 (PDT), Thiago Adams
<thiago.adams@gmail.com> wrote:

>On Thursday, May 4, 2017 at 4:03:16 PM UTC-3, Ben Bacarisse wrote:
>> Malcolm McLean  writes:
>> 
>> > On Thursday, May 4, 2017 at 3:50:54 PM UTC+1, Thiago Adams wrote:
>> >> 
>> >> I think the bad point of this solution is performance because 
>> >> it is more dynamic. Also less type check.
>> >>
>> > You can't type check, but people make far too much fuss about "type safety",
>> > because it happens to be a programming error that is easy for the compiler
>> > to catch.
>> 
>> That's very much a C (and C-like) language perspective.  Even for some
>> relatively natural type systems, type checking can be undecidable and it
>> is often NP-complete.  But you are right that it is often made easy to
>> check.
>> 
>> Of course that's, in part, what makes it something that is over fussed
>> about in that the fuss is more justifiable, the less easy the
>> type-checking is.  At the far end of that spectrum would be a type
>> system in which type-checking the program is equivalent to proving the
>> program semantically correct.
>
>When I know that the compiler will not check type for me, 
>for instance a cast, I create a "cast" macro.
>For instance:
>
>#define Type1_As_Type2(p) ((Type2*)p)
>
>Then let's say Type2 cannot be converted to Type1 anymore.
>I just delete the macro and the compiler will show where the 
>cast is not allowed anymore because it will not find the macro.
>


Would not turning that into a "cast function" be even better:

inline static Type2* Type1_As_Type2(Type1 *p)
{
   return ((Type2*)p);
}

You still get the compiler to warn you when the conversion is deleted,
plus you get it to type check the source parameter.  And any compiler
should inline and no-op that (assuming the pointer formats are, as is
common, compatible).

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

#109261

On Thursday, May 4, 2017 at 5:03:36 PM UTC-3, robert...@yahoo.com wrote:
> On Thu, 4 May 2017 12:25:35 -0700 (PDT), Thiago Adams
> wrote:
> 
> >On Thursday, May 4, 2017 at 4:03:16 PM UTC-3, Ben Bacarisse wrote:
> >> Malcolm McLean  writes:
> >> 
> >> > On Thursday, May 4, 2017 at 3:50:54 PM UTC+1, Thiago Adams wrote:
> >> >> 
> >> >> I think the bad point of this solution is performance because 
> >> >> it is more dynamic. Also less type check.
> >> >>
> >> > You can't type check, but people make far too much fuss about "type safety",
> >> > because it happens to be a programming error that is easy for the compiler
> >> > to catch.
> >> 
> >> That's very much a C (and C-like) language perspective.  Even for some
> >> relatively natural type systems, type checking can be undecidable and it
> >> is often NP-complete.  But you are right that it is often made easy to
> >> check.
> >> 
> >> Of course that's, in part, what makes it something that is over fussed
> >> about in that the fuss is more justifiable, the less easy the
> >> type-checking is.  At the far end of that spectrum would be a type
> >> system in which type-checking the program is equivalent to proving the
> >> program semantically correct.
> >
> >When I know that the compiler will not check type for me, 
> >for instance a cast, I create a "cast" macro.
> >For instance:
> >
> >#define Type1_As_Type2(p) ((Type2*)p)
> >
> >Then let's say Type2 cannot be converted to Type1 anymore.
> >I just delete the macro and the compiler will show where the 
> >cast is not allowed anymore because it will not find the macro.
> >
> 
> 
> Would not turning that into a "cast function" be even better:
> 
> inline static Type2* Type1_As_Type2(Type1 *p)
> {
>    return ((Type2*)p);
> }
> 
> You still get the compiler to warn you when the conversion is deleted,
> plus you get it to type check the source parameter.  And any compiler
> should inline and no-op that (assuming the pointer formats are, as is
> common, compatible).

Actually, I do this way also :D
I agree that is better.
Sometimes this method requires a forward declaration because it uses compiler.


For type safety, the C language can be improved a lot without to change any line from the standard. Just  using static analysis.

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

#109305

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Thursday, May 4, 2017 at 3:50:54 PM UTC+1, Thiago Adams wrote:
>
>> I think the bad point of this solution is performance because
>> it is more dynamic.  Also less type check.
>
> You can't type check, but people make far too much fuss about "type safety",
> because it happens to be a programming error that is easy for the compiler
> to catch.  [...]

That is a remarkably naive viewpoint.

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

#109218

On Thu, 4 May 2017 07:50:40 -0700 (PDT)
Thiago Adams <thiago.adams@gmail.com> wrote:

> I think the bad point of this solution is performance because 
> it is more dynamic. Also less type check.

Once more a C approach wouldn't put any constructor/destructor pointers in a
structure without a good reason to do so, which I don't see in the previous
example if not to mimic a C++ pattern.

I would rather build a machinery to process with static field such as:

#define DATAFIELD_MAX 255

struct row
{
  void *prevrow;
  void *nextrow;
  int freechar;
  char datafield[DATAFIELD_MAX];
  int datatype;
};

struct table
{
  int nrow;
  struct *rowp;
};

struct table *insert(struct table *tab, char *data, size_t size);
struct table *remove(struct table *tab, char *data, size_t size);
int gettype(struct table *tab, char *data, size_t size);
char *getdata(struct table *tab, int type);

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

#109245

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 04/05/17 14:13, Thiago Adams wrote:
>> I need to create many dynamic arrays and some maps in C for different types.
>>
>> How do you deal with this problem?
>
> I deal with it using a struct:
>
> {
>   pcl_constructor *constructor;
>   pcl_destructor *destructor;
>   pcl_comparator *comparator;
>   pcl_executor *executor;
>   void *data;  /* pointer to array data */
>   size_t size; /* size of one object */
>   size_t count; /* number of objects */
>   size_t capacity; /* current capacity, must be >= count */
>   size_t maxcap; /* maximum capacity */
> };

A slight variation is to have the four functions and the size in a
separate struct, a pointer to which is shared between instances.

The down-side is that you must manage this shared data but that is often
very simple.  For example, in some programs you can just statically
declare a fixed number of these "class" structs.

I would probably try to put all the operations into either and array or
a flexible array member.  The last time I did this (as with all my
coding these days, it was a toy program) all of the operations had the
same type:

  typedef void Method(struct Object *this, ...);

and the constructor was method 0, the destructor method 1 and so on.

<snip>
-- 
Ben.

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

#109228

On Thu, 4 May 2017 06:13:59 -0700 (PDT), Thiago Adams
<thiago.adams@gmail.com> wrote:

>I need to create many dynamic arrays and some maps in C for different types.
>
>How do you deal with this problem?
>
>
>1)  Create a new file for each type with an generator or by hand?
>    Remove manually some not used functions?
>    Keep then in a generated folder?
>
>
>2)  Use define - include - undef?
>    #define TYPE MYTYPE
>    #include "Array.h"
>    #undef TYPE
>
>3)  Use a void* version of each container?
>
>4)  Define a macro DECLARE_ARRAY and IMPLEMENT_ARRAY?
>
>5)  Define only DECLARE_ARRAY  with inline functions
>
>6)  Create preprocessor to instantiate types/functions?
>
>8)  Create individual macros for each function (eg. ARRAY_PUSH)
>
>9)  Create individual macros using the generator?
>
>10)  Other?


Jacob Navia has implemented a C container library, which does many of
the same things as the C++ STL.  It may be worth at least taking a
look at some of his code:

https://www.cs.virginia.edu/~lcc-win32/ccl/ccl.html

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

#109230

On Thu, 04 May 2017 12:09:39 -0500, Robert Wessel
<robertwessel2@yahoo.com> wrote:

>On Thu, 4 May 2017 06:13:59 -0700 (PDT), Thiago Adams
><thiago.adams@gmail.com> wrote:
>
>>I need to create many dynamic arrays and some maps in C for different types.
>>
>>How do you deal with this problem?
>>
>>
>>1)  Create a new file for each type with an generator or by hand?
>>    Remove manually some not used functions?
>>    Keep then in a generated folder?
>>
>>
>>2)  Use define - include - undef?
>>    #define TYPE MYTYPE
>>    #include "Array.h"
>>    #undef TYPE
>>
>>3)  Use a void* version of each container?
>>
>>4)  Define a macro DECLARE_ARRAY and IMPLEMENT_ARRAY?
>>
>>5)  Define only DECLARE_ARRAY  with inline functions
>>
>>6)  Create preprocessor to instantiate types/functions?
>>
>>8)  Create individual macros for each function (eg. ARRAY_PUSH)
>>
>>9)  Create individual macros using the generator?
>>
>>10)  Other?
>
>
>Jacob Navia has implemented a C container library, which does many of
>the same things as the C++ STL.  It may be worth at least taking a
>look at some of his code:
>
>https://www.cs.virginia.edu/~lcc-win32/ccl/ccl.html


Sorry, better link:

https://code.google.com/archive/p/ccl/

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

#109235

On Thursday, May 4, 2017 at 2:17:53 PM UTC-3, robert...@yahoo.com wrote:
> On Thu, 04 May 2017 12:09:39 -0500, Robert Wessel
>  wrote:
> 
> >On Thu, 4 May 2017 06:13:59 -0700 (PDT), Thiago Adams
> > wrote:
> >
> >>I need to create many dynamic arrays and some maps in C for different types.
> >>
> >>How do you deal with this problem?
> >>
> >>
> >>1)  Create a new file for each type with an generator or by hand?
> >>    Remove manually some not used functions?
> >>    Keep then in a generated folder?
> >>
> >>
> >>2)  Use define - include - undef?
> >>    #define TYPE MYTYPE
> >>    #include "Array.h"
> >>    #undef TYPE
> >>
> >>3)  Use a void* version of each container?
> >>
> >>4)  Define a macro DECLARE_ARRAY and IMPLEMENT_ARRAY?
> >>
> >>5)  Define only DECLARE_ARRAY  with inline functions
> >>
> >>6)  Create preprocessor to instantiate types/functions?
> >>
> >>8)  Create individual macros for each function (eg. ARRAY_PUSH)
> >>
> >>9)  Create individual macros using the generator?
> >>
> >>10)  Other?
> >
> >
> >Jacob Navia has implemented a C container library, which does many of
> >the same things as the C++ STL.  It may be worth at least taking a
> >look at some of his code:
> >
> >https://www.cs.virginia.edu/~lcc-win32/ccl/ccl.html
> 
> 
> Sorry, better link:
> 
> https://code.google.com/archive/p/ccl/

I guess the Jacob Navia approach is the "dynamic" approach
using function pointers.
The bad point is performance.

For performance considerations, memory consumption 
and program size we need to compare with the container made by hand or generator.

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

#109255

On 05/ 5/17 05:30 AM, Thiago Adams wrote:
> On Thursday, May 4, 2017 at 2:17:53 PM UTC-3, robert...@yahoo.com wrote:
>> On Thu, 04 May 2017 12:09:39 -0500, Robert Wessel
>>   wrote:
>>>
>>> Jacob Navia has implemented a C container library, which does many of
>>> the same things as the C++ STL.  It may be worth at least taking a
>>> look at some of his code:
>>>
>>> https://www.cs.virginia.edu/~lcc-win32/ccl/ccl.html
>>
>>
>> Sorry, better link:
>>
>> https://code.google.com/archive/p/ccl/
>
> I guess the Jacob Navia approach is the "dynamic" approach
> using function pointers.
> The bad point is performance.

In most testing I have seen or done, it performs well.

-- 
Ian

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

#109244

Robert Wessel <robertwessel2@yahoo.com> writes:
> On Thu, 04 May 2017 12:09:39 -0500, Robert Wessel
> <robertwessel2@yahoo.com> wrote:
[...]
>>Jacob Navia has implemented a C container library, which does many of
>>the same things as the C++ STL.  It may be worth at least taking a
>>look at some of his code:
>>
>>https://www.cs.virginia.edu/~lcc-win32/ccl/ccl.html
>
>
> Sorry, better link:
>
> https://code.google.com/archive/p/ccl/

The code.google.com service was shut down in 2016.  The project is still
available there, but I hope that jacob moves or copies it to a more
permanent location.

-- 
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]

#109248

On 2017-05-04, Robert Wessel <robertwessel2@yahoo.com> wrote:
> On Thu, 04 May 2017 12:09:39 -0500, Robert Wessel
> <robertwessel2@yahoo.com> wrote:
>>Jacob Navia has implemented a C container library, which does many of
>>the same things as the C++ STL.  It may be worth at least taking a
>>look at some of his code:
>>
>>https://www.cs.virginia.edu/~lcc-win32/ccl/ccl.html
>
>
> Sorry, better link:
>
> https://code.google.com/archive/p/ccl/

The link to the Google Code Archive is dead.

It looks like Jacob moved the CCL to GitHub:

https://github.com/jacob-navia/ccl

Bye, Andreas

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

#109259

On Thu, 4 May 2017 18:34:40 -0000 (UTC), Andreas Perstinger
<andipersti@gmail.com> wrote:

>On 2017-05-04, Robert Wessel <robertwessel2@yahoo.com> wrote:
>> On Thu, 04 May 2017 12:09:39 -0500, Robert Wessel
>> <robertwessel2@yahoo.com> wrote:
>>>Jacob Navia has implemented a C container library, which does many of
>>>the same things as the C++ STL.  It may be worth at least taking a
>>>look at some of his code:
>>>
>>>https://www.cs.virginia.edu/~lcc-win32/ccl/ccl.html
>>
>>
>> Sorry, better link:
>>
>> https://code.google.com/archive/p/ccl/
>
>The link to the Google Code Archive is dead.
>
>It looks like Jacob moved the CCL to GitHub:
>
>https://github.com/jacob-navia/ccl


I actually knew Google Code was dead, but had pretty much forgotten,
and didn't look too closely at the actual link (the "archive" should
have been a tip-off).  In any event, a link from what (I think) is
Jacob's main page for these things led me to the one I posted.  He may
need to update that.

https://www.cs.virginia.edu/~lcc-win32/

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

#109273

	What can containers do that processes cannot do, anyway? 

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

#109274

Doug Weiman <no@nyet.net> writes:
> What can containers do that processes cannot do, anyway? 

Containers and processes are entirely different things.  (Perhaps
you're thinking of a different kind of "container"?)

https://en.wikipedia.org/wiki/Container_(abstract_data_type)

-- 
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]

#109278

On Thu, 04 May 2017 14:41:34 -0700, Keith Thompson wrote:

> Doug Weiman <no@nyet.net> writes:
>> What can containers do that processes cannot do, anyway?
> 
> Containers and processes are entirely different things.  (Perhaps you're
> thinking of a different kind of "container"?)
> 
> https://en.wikipedia.org/wiki/Container_(abstract_data_type)

	Yes; my mistake.

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

#109276

On 2017-05-04, Thiago Adams <thiago.adams@gmail.com> wrote:
> I need to create many dynamic arrays and some maps in C for different types.
>
> How do you deal with this problem?
[snip]

When I did it years ago, I used an approach like

#define ARRAY_TYPE MYTYPE
#include "ARRAY.h"
#udef ARRAY_TYPE

I used a single include file instead of separate DECLARE_ARRAY and 
IMPLEMENT_ARRAY files.  A #define before the #include controlled 
whether the include file was to produce declarations or definitions.

The containers held structs rather than individual variables.  Memory 
management of those structs was the responsibility of the program that 
used the container.

One of the elements of that struct was of a type with a name like 
ARRAY_LINK.  The typename was a struct declared by the include file.  

The generated functions accessed only the elements of ARRAY_LINK.  
The generated functions were usually short.  By default, they were 
defined as static so that optimizing compilers could inline calls to 
the generated function or generate function call code that was compact.

The generated functions were type-specific to the struct held in a
container.

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

#109299

On Thursday, May 4, 2017 at 8:14:06 AM UTC-5, Thiago Adams wrote:
> I need to create many dynamic arrays and some maps in C for different types.
> 
> How do you deal with this problem?
> 
> 
> 1)  Create a new file for each type with an generator or by hand?
>     Remove manually some not used functions?
>     Keep then in a generated folder?
> 

My APL interpreter does it a somewhat-unique way which amounts
to very little code to add new types. I've explained this a few
times before so a search may turn up more (or at least varied)
details.

The crux is two basic mappings involved in a container like an
array. This may sound complicated by saying something like that
up front, but if you'll bear with me it may seem less unappealing
later on.

The first mapping I call "encoding". All the various types are
mapped into a few bits masked over the top of an 'int'. So 'int'
or 'typedef int object;' becomes an "atomic" representation of
an object.

Then the various containers just contain 'int' as the payload.
All data elements have a (small and) uniform size.

There may be a "performance" hit since all the real "data" is
doubly-indirected. So adding two float "objects" encoded in this
way involves 2 array lookups and a pointer dereference to yield
each float, and a malloc (and possible realloc) to create a new
object for the result.

But adding a new type is now trivial, and all containers 
automatically work for the new type.

> 2)  Use define - include - undef?
>     #define TYPE MYTYPE
>     #include "Array.h"
>     #undef TYPE
> 

I love love love X-Macros, but do it this way:

http://stackoverflow.com/questions/6635851/real-world-use-of-x-macros/6636596#6636596


> 3)  Use a void* version of each container?

I use 'int', but supposedly you could use void*. I find too many
of those on the screen makes me dizzy.

> 4)  Define a macro DECLARE_ARRAY and IMPLEMENT_ARRAY?
> 
> 5)  Define only DECLARE_ARRAY  with inline functions

That sort of thing isn't necessary with the extra Encoding
step I'm advertising. It allows heterogeneous arrays.
An array of 3 ints is created the same way as an array of
3 floats.

    array x = array_new_dims(3);

> 6)  Create preprocessor to instantiate types/functions?
> 
> 8)  Create individual macros for each function (eg. ARRAY_PUSH)
> 
> 9)  Create individual macros using the generator?
> 
> 10)  Other?

I think my approach falls under Other. Avoid too many macros.

I've written about various pieces of this design with code
on these pages:

https://codereview.stackexchange.com/questions/140994/encoding-data-into-integer-handles-for-language-interpreter

https://codereview.stackexchange.com/questions/122038/arbitrary-dimensional-arrays-with-transpose-and-slice

https://codereview.stackexchange.com/questions/114243/unicode-capable-symbol-table-n-way-search-tree-with-hash-buckets

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web