Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #151039
| From | BGB <cr88192@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: The big problem of C |
| Date | 2020-04-04 20:06 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <r6baut$6eb$1@dont-email.me> (permalink) |
| References | <d2036eb4-d744-4914-bb25-624e7ba528bd@googlegroups.com> <a5anlg-tmt1.ln1@mail.home.palmen-it.de> <f141ff4f-57a6-4728-8c10-5c6d3b19e377@googlegroups.com> <1vanlg-38v1.ln1@mail.home.palmen-it.de> <58e8e325-8bab-4d51-8d4b-57c903037e84@googlegroups.com> |
On 4/4/2020 6:48 PM, Thiago Adams wrote:
> On Saturday, April 4, 2020 at 6:32:08 PM UTC-3, Felix Palmen wrote:
>> * Malcolm McLean
>>> One of the regulars who hasn't posted here for a while wrote a C
>>> containers library, which he tried to get standardised. But it achieved
>>> almost no traction. The main reason seemed to be that it is always just
>>> a bit easier to roll your own basic data structure in C than to use
>>> one written by a third party. I'm not sure whether this says something
>>> good or somethign bad about C.
>>
>> This is the main point here :) Although I think the reason is: such a
>> thing doesn't have to be in the C standard library. If you need a really
>> generic implementation, you can create one *or* use one of the existing
>> implementations.
>
> There is no generic implementation in C.
> Unless you are considering void* casts. Doing this we have
> problems as well like debugging etc.
>
>
>> Or you can just implement something eventually much
>> simpler that directly fits your usecase. It's up to you :) Keeping the
>> standard lib (as part of the language) minimal is a feature of C, not a
>> problem. If it's a problem for your project, you might have picked the
>> wrong language.
>
> I think the only container that should be part of the language
> is array because this type, or a very similar type, is already
> present on the language. (normal C arrays)
> See the link for swift lang.
>
Consider, for example, how one might approach Java-like arrays in C:
One needs a pointer to a data area, may or may not be fixed size;
One needs information about how big the array is;
One needs some way to bounds-check accesses, and access each element;
It preferably needs to be at least vaguely efficient.
Additionally, we need to be able to detect that a reference is an array,
and the base type; but accesses themselves can be assumed to be the
correct types.
so, eg, something like:
struct ArrayHeader_s {
BaseObjectVTable *vt; //indirectly encodes "what is this?"
void *data; //untyped
void *lim_data; //limit
};
The VTable might in-turn look something like:
struct BaseObjectVTable_s {
ClassInfo *clz; //what type of object is this?
intptr_t offs; //offset from object-base (*1).
... //typically, function pointers for each method for the class.
};
An array might have a ClassInfo which simply identifies that it is an
array object, and gives a type-signature for the element type. The
method pointers would simply be those for an anonymous object (eg: it
may be the case that "delete obj;" essentially compiles to
"obj->operator_delete();" in the default case).
Other types might have pointers for each method implemented by the
class, usually appended onto whatever was inherited from the parent
class, ...
*1: One way to handle interfaces being to tack a bunch of interface
VTable pointers onto the end of the object, then to adjust the 'this'
pointer during an interface-method-call using an offset to get 'this' to
point to the object's base. Casting an object to an implemented
interface goes the other way, and adjusting the pointer to point to the
interface's VTable pointer (the ClassInfo will contain a list of
interfaces the class implements, and the offset of its VT pointer).
A lot of this can be mostly ignored when accessing elements, which will
follow a process:
Calculate the address of the desired element;
Check against the limit;
Get/Set the element if this doesn't fail.
So, say:
int32_t FooRTL_ArrayGetElemInt(ArrayHeader *arr, size_t index)
{
int32_t *t0;
t0=((int32_t *)arr->data)+index;
if(t0>(int32_t *)(arr->lim_data))
{
/* Throw */
}
return(*t0);
}
Cost can reduced slightly, and the logic can be inlined, if you know
that no bounds-check is needed, eg:
((int32_t *)arr->data)[index]
Now, repeat all this for every "primitive type" in the core type-system.
If a type reduces to a primitive type, one can reuse the existing
handlers (eg: "Foo*" and "Bar*" can be treated as equivalent); and
arrays containing structures can be lumped together under an "array with
scale" subtype, ...
But, then we still have an extra pointer deref, and caching this will
cost an additional register in the register allocation, ...
int32_t *t0;
...
t0=arr->data;
...
i1=t0[i0]; //accesses to 'arr' go through cached pointer
...
It can sort of work, but it is also a case of "death by 1000 paper cuts"
in terms of the overall performance impact... (with a more significant
risk if we can't eliminate the bounds checks, ...)
Then one may end up with different syntax for things like arrays with
automatic lifetime (allocated on stack) vs arrays with dynamic lifetime
(allocated on heap), special cases in the semantics, ...
It is sort of a problem, like if one adds "high level" features, then
these features come with costs. This can be sort of demotivating...
OTOH: It is probably OK if one doesn't really care all that much about
performance...
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
The big problem of C Thiago Adams <thiago.adams@gmail.com> - 2020-04-04 13:41 -0700
Re: The big problem of C felix@palmen-it.de (Felix Palmen) - 2020-04-04 23:18 +0200
Re: The big problem of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 14:24 -0700
Re: The big problem of C felix@palmen-it.de (Felix Palmen) - 2020-04-04 23:31 +0200
Re: The big problem of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 14:39 -0700
Re: The big problem of C Bart <bc@freeuk.com> - 2020-04-04 23:08 +0100
Re: The big problem of C Thiago Adams <thiago.adams@gmail.com> - 2020-04-04 16:48 -0700
Re: The big problem of C BGB <cr88192@gmail.com> - 2020-04-04 20:06 -0500
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 19:44 +0200
Re: The big problem of C Thiago Adams <thiago.adams@gmail.com> - 2020-04-04 16:40 -0700
Re: The big problem of C felix@palmen-it.de (Felix Palmen) - 2020-04-05 01:58 +0200
Re: The big problem of C Thiago Adams <thiago.adams@gmail.com> - 2020-04-04 18:05 -0700
Re: The big problem of C Ian Collins <ian-news@hotmail.com> - 2020-04-05 15:17 +1200
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 09:44 +0200
Re: The big problem of C felix@palmen-it.de (Felix Palmen) - 2020-04-05 11:14 +0200
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 11:27 +0200
Re: The big problem of C felix@palmen-it.de (Felix Palmen) - 2020-04-05 11:34 +0200
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 11:45 +0200
Re: The big problem of C nobody@example.org (Scott) - 2020-04-05 16:27 +0000
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 19:38 +0200
Re: The big problem of C David Brown <david.brown@hesbynett.no> - 2020-04-05 22:19 +0200
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-06 10:16 +0200
Re: The big problem of C David Brown <david.brown@hesbynett.no> - 2020-04-06 13:36 +0200
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-06 13:55 +0200
Re: The big problem of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 05:04 -0700
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-06 14:11 +0200
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-06 18:01 +0200
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-06 22:08 +0200
Re: The big problem of C Öö Tiib <ootiib@hot.ee> - 2020-04-06 20:47 -0700
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-07 09:06 +0200
Re: The big problem of C already5chosen@yahoo.com - 2020-04-07 05:58 -0700
Re: The big problem of C David Brown <david.brown@hesbynett.no> - 2020-04-07 17:55 +0200
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-07 19:02 +0200
Re: The big problem of C already5chosen@yahoo.com - 2020-04-07 10:21 -0700
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-07 20:02 +0200
Re: The big problem of C already5chosen@yahoo.com - 2020-04-07 13:10 -0700
Re: The big problem of C felix@palmen-it.de (Felix Palmen) - 2020-04-07 22:34 +0200
Railway programming (Was : The big problem of C) Spiros Bousbouras <spibou@gmail.com> - 2020-04-08 00:01 +0000
Re: Railway programming (Was : The big problem of C) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-08 01:11 +0100
Re: Railway programming (Was : The big problem of C) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-08 01:12 +0100
Re: Railway programming (Was : The big problem of C) felix@palmen-it.de (Felix Palmen) - 2020-04-08 09:56 +0200
Re: Railway programming (Was : The big problem of C) Spiros Bousbouras <spibou@gmail.com> - 2020-04-09 11:55 +0000
Re: Railway programming (Was : The big problem of C) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-04-08 08:17 +0000
Re: Railway programming (Was : The big problem of C) felix@palmen-it.de (Felix Palmen) - 2020-04-08 09:42 +0200
Re: The big problem of C already5chosen@yahoo.com - 2020-04-07 06:13 -0700
Re: The big problem of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-07 09:17 -0700
Re: The big problem of C already5chosen@yahoo.com - 2020-04-07 09:44 -0700
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-07 09:07 +0200
Re: The big problem of C Öö Tiib <ootiib@hot.ee> - 2020-04-06 05:01 -0700
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-06 14:42 +0200
Re: The big problem of C Bart <bc@freeuk.com> - 2020-04-06 00:09 +0100
Re: The big problem of C David Brown <david.brown@hesbynett.no> - 2020-04-06 09:09 +0200
Re: The big problem of C Bart <bc@freeuk.com> - 2020-04-05 12:41 +0100
Re: The big problem of C Thiago Adams <thiago.adams@gmail.com> - 2020-04-05 07:05 -0700
Re: The big problem of C BGB <cr88192@gmail.com> - 2020-04-04 17:48 -0500
Re: The big problem of C Thiago Adams <thiago.adams@gmail.com> - 2020-04-04 17:16 -0700
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 09:25 +0200
Re: The big problem of C jacobnavia <jacob@jacob.remcomp.fr> - 2020-04-05 09:50 +0200
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 09:53 +0200
Re: The big problem of C jacobnavia <jacob@jacob.remcomp.fr> - 2020-04-05 18:00 +0200
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 19:35 +0200
Re: The big problem of C jacobnavia <jacob@jacob.remcomp.fr> - 2020-04-06 08:05 +0200
Re: The big problem of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 04:25 -0700
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 13:32 +0200
Re: The big problem of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 04:57 -0700
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 14:09 +0200
Re: The big problem of C chad <cdalten@gmail.com> - 2020-04-05 05:20 -0700
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 15:04 +0200
Re: The big problem of C Öö Tiib <ootiib@hot.ee> - 2020-04-05 05:22 -0700
Re: The big problem of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 05:33 -0700
Re: The big problem of C Öö Tiib <ootiib@hot.ee> - 2020-04-05 06:55 -0700
Re: The big problem of C felix@palmen-it.de (Felix Palmen) - 2020-04-05 16:42 +0200
Re: The big problem of C BGB <cr88192@gmail.com> - 2020-04-05 09:57 -0500
Re: The big problem of C Spiros Bousbouras <spibou@gmail.com> - 2020-04-06 10:46 +0000
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-06 13:14 +0200
Re: The big problem of C Philipp Klaus Krause <pkk@spth.de> - 2020-04-05 19:00 +0200
Re: The big problem of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 10:08 -0700
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 19:52 +0200
Re: The big problem of C BGB <cr88192@gmail.com> - 2020-04-05 13:37 -0500
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 20:49 +0200
Re: The big problem of C BGB <cr88192@gmail.com> - 2020-04-05 15:27 -0500
Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-06 10:14 +0200
Re: The big problem of C Thiago Adams <thiago.adams@gmail.com> - 2020-04-05 12:07 -0700
Re: The big problem of C Guillaume <message@bottle.org> - 2020-04-06 15:09 +0200
Re: The big problem of C Thiago Adams <thiago.adams@gmail.com> - 2020-04-06 07:02 -0700
Re: The big problem of C BGB <cr88192@gmail.com> - 2020-04-06 10:30 -0500
Re: The big problem of C Thiago Adams <thiago.adams@gmail.com> - 2020-04-06 09:06 -0700
Re: The big problem of C Guillaume <message@bottle.org> - 2020-04-06 18:43 +0200
Re: The big problem of C Thiago Adams <thiago.adams@gmail.com> - 2020-04-06 12:19 -0700
Re: The big problem of C Thiago Adams <thiago.adams@gmail.com> - 2020-04-08 18:27 -0700
csiph-web