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

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

The big problem of C

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

Contents

  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

Page 1 of 5  [1] 2 3 4 5  Next page →

#151019 — The big problem of C

One of the biggest problem of C is the lack of parametrized
containers and algorithms.

To explain my point imagine each time you make an array
in C you had to create a new type.

For instance, let's say this syntax "int a[2]" was 
forbidden and you had to create a new type "int_array" to 
express arrays of int each time you need.

This is exactly what happens in C when we need 
resizable arrays.

Sometimes this type is so important inside your code that
it is not a problem to identify it with an unique name. 

But this is not the unique scenario. Sometimes all we need is
an ordinary resizable array of int, or generally some ordinary 
resizable array of pointers of some type.
Having to create new types for each of these just creates NOISE.

Arrays are an especial case here because they already exist 
inside the language. C++ has an workaround for the arrays 
it is called vector. I call it workaround because it tries 
to simulate arrays, for instance, overriding the operator [].
But the syntax in many points are different from C arrays.

Swift language seems to have identified and fixed this problem:

"
The type of a Swift array is written in full as Array<Element>,
where Element is the type of values the array is allowed to store.
You can also write the type of an array in shorthand form as [Element].
"

https://docs.swift.org/swift-book/LanguageGuide/CollectionTypes.html


I generally explain my view to prefer C over C++ but this is something
should be fixed in C.

In C we have VLAs. If you show a code sample for a new programmer
using VLA and compare with vector we can notice that the beginner
thinks VLA as something natural.
But VLAs also have limitations and we need a proper resiable 
array in C.



Do you agree? Do you create a new type each time you need
a resizable array? Do you avoid resizable arrays?

Here I am also using the word  resizable instead of dynamic
because I want to differentiate the case where we just 
specify the size once.
 
For instance:

struct X
{
  struct Item* items;
}

in C it is ambiguous here that items is a dynamic array of Item.
But it might be.
We can have some operation that reads a file for instance and fills
all items at once.

The syntax pX->items[0] will be similar of arrays.

[toc] | [next] | [standalone]

#151024

* Thiago Adams <thiago.adams@gmail.com>:
> One of the biggest problem of C is the lack of parametrized
> containers and algorithms.

I guess anyone who knows his way around C can stop reading right here.

-- 
 Dipl.-Inform. Felix Palmen  <felix@palmen-it.de>   ,.//..........
 {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
 {pgp public key}     http://palmen-it.de/pub.txt   //   """""""""""
 {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A

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

#151025

On Saturday, 4 April 2020 22:20:10 UTC+1, Felix Palmen  wrote:
> * Thiago Adams <thiago.adams@gmail.com>:
> > One of the biggest problem of C is the lack of parametrized
> > containers and algorithms.
> 
> I guess anyone who knows his way around C can stop reading right here.
> 
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.

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

#151026

* Malcolm McLean <malcolm.arthur.mclean@gmail.com>:
> 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. 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.

-- 
 Dipl.-Inform. Felix Palmen  <felix@palmen-it.de>   ,.//..........
 {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
 {pgp public key}     http://palmen-it.de/pub.txt   //   """""""""""
 {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A

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

#151028

On Saturday, 4 April 2020 22:32:08 UTC+1, Felix Palmen  wrote:
> * Malcolm McLean <malcolm.arthur.mclean@gmail.com>:
> > 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. 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 write a lot of C++ which is effectively C with just a few C++ features.
But one of those C++ features is the std::vector. It carries its length
around with it, it can be resized or assigned, and it is destroyed 
automatically. And it has automatic bounds checking. It's superior
to C arrays for most purposes.

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

#151030

On 04/04/2020 22:39, Malcolm McLean wrote:
> On Saturday, 4 April 2020 22:32:08 UTC+1, Felix Palmen  wrote:
>> * Malcolm McLean <malcolm.arthur.mclean@gmail.com>:
>>> 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. 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 write a lot of C++ which is effectively C with just a few C++ features.
> But one of those C++ features is the std::vector.

I suspect then that it's using more than a few C++ features. Look at 
what goes into making std::vector possible.

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

#151035

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.

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

#151039

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

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

#151088

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

Sorry, nearly every programs needs dynamic containers.
So a contemporary language has to support this.

> Or you can just implement something eventually much
> simpler that directly fits your usecase.

For something similar to std::string or std::vector there's no need
to have variations.

> Keeping the standard lib (as part of the language) minimal is
> a feature of C, not a problem.

It is a problem because C doesn't fit the needs.

> If it's a problem for your project, you might have picked the wrong language.

Yes, C might be good for tiny microcontroller-projects. For larger
things using it results in much unecessary work which can be handled
easier in other languages.

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

#151034

On Saturday, April 4, 2020 at 6:20:10 PM UTC-3, Felix Palmen wrote:
> * Thiago Adams 
> > One of the biggest problem of C is the lack of parametrized
> > containers and algorithms.
> 
> I guess anyone who knows his way around C can stop reading right here.

My point is not that impossible to use C because of this,
but I am saying that creating types to represent, for instance, 
resizable arrays creates a lot of noise when we just want
a ordinary array of something.

How do you do resizable arrays?

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

#151036

* Thiago Adams <thiago.adams@gmail.com>:
> How do you do resizable arrays?

Well, the typical approach to do it yourself is along the lines of

    struct foo
    {
        size_t size;
	size_t capacity;
	T *elements;
    };

and I *do* have this pattern pretty often in my code.

If you want a "generic" implementation, this can be done as well, but it
is complex. That's where well-known libraries step in, you probably
don't want do do this yourself. And, if you're coding in C, you probably
also want to think about the overhead (in runtime and memory
consumption) of such a solution.

If, for your project, you feel such containers should be part of the
language (and therefore be implemented in the standard library), you
might have picked the wrong language for your usecase ;)

It's a core feature of C to keep the language (and especially the
runtime) simple and small. Some even call it a "portable assembler".

-- 
 Dipl.-Inform. Felix Palmen  <felix@palmen-it.de>   ,.//..........
 {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
 {pgp public key}     http://palmen-it.de/pub.txt   //   """""""""""
 {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A

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

#151038

On Saturday, April 4, 2020 at 9:00:08 PM UTC-3, Felix Palmen wrote:
> * Thiago Adams 
> > How do you do resizable arrays?
> 
> Well, the typical approach to do it yourself is along the lines of
> 
>     struct foo
>     {
>         size_t size;
> 	size_t capacity;
> 	T *elements;
>     };
> 
> and I *do* have this pattern pretty often in my code.

I also do like this. The problem I am saying is that
we introduce more data types and this creates noise
and boilerplate code or macros or a new pattern with macros
that is enigmatic.

For instance, if I have the type struct Holiday.
And I need a list of Holidays. Using this approach 
I will  have to create a new type HolidaysArray.
Functions and  struct will use this new type.

struct Calendar {
  struct HollidaysArray holidays;
}
void F(struct HollidaysArray* holidays);

now compare with with this "natural" way

struct Calendar {
  struct Hollidays* holidays[20];
};

void F(HollidaysArray holidays[20]);


The question why not use a high level language?

Let's say this calendar algorithm needs to run really 
fast in some simulation. 
In this case  the choose of C is good. It will give us
performance and control. But the list of holidays is not
the problem for performance because the simulation
runs after configuration.

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

#151042

On 05/04/2020 13:05, Thiago Adams wrote:
> On Saturday, April 4, 2020 at 9:00:08 PM UTC-3, Felix Palmen wrote:
>> * Thiago Adams
>>> How do you do resizable arrays?
>>
>> Well, the typical approach to do it yourself is along the lines of
>>
>>      struct foo
>>      {
>>          size_t size;
>> 	size_t capacity;
>> 	T *elements;
>>      };
>>
>> and I *do* have this pattern pretty often in my code.
> 
> I also do like this. The problem I am saying is that
> we introduce more data types and this creates noise
> and boilerplate code or macros or a new pattern with macros
> that is enigmatic.

It sounds like you are looking got a language with naive container and 
generics, why not use one for this project?

-- 
Ian.

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

#151045

> Well, the typical approach to do it yourself is along the lines of
> 
>      struct foo
>      {
>          size_t size;
> 	size_t capacity;
> 	T *elements;
>      };

Show me a C-program that resembles what this code does:

#include <iostream>
#include <vector>
#include <string>
#include <algorithm>

using namespace std;

int main()
{
     vector<string> strings;
     string         strIn;
     for( ; ; )
     {
         getline( cin, strIn );
         if( strIn.length() != 0 )
             strings.emplace_back( move( strIn ) );
         else
             break;
     }
     sort( strings.begin(), strings.end() );
     for( string &s : strings )
         cout << s << endl;
}


If you want really want the same functionality you'd have
to write a magnitude more code. C is simply a mess.

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

#151053

* Bonita Montero <Bonita.Montero@gmail.com>:
> Show me a C-program that resembles what this code does:

Why?

> If you want really want the same functionality you'd have
> to write a magnitude more code. C is simply a mess.

This level of complexity in C++ is simply a mess. So what now? Choose
the tool you think fits best the goals of your current project, instead
of trying to start a boring language flame.

-- 
 Dipl.-Inform. Felix Palmen  <felix@palmen-it.de>   ,.//..........
 {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
 {pgp public key}     http://palmen-it.de/pub.txt   //   """""""""""
 {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A

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

#151054

>> Show me a C-program that resembles what this code does:

> Why?

Containers are a extremely common pattern, even if you write
them manually in C. I want to see how complex this will be in C.

> This level of complexity in C++ is simply a mess.

The complexity of the shown code is a mangnitude lower than
it would he for the same functionality in C.

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

#151057

* Bonita Montero <Bonita.Montero@gmail.com>:
> The complexity of the shown code is a mangnitude lower than
> it would he for the same functionality in C.

C obviously isn't the language *you* want to use. Your obvious attempt
shifting the interpretation of "complexity" from the language/runtime to
some particular code written won't trigger me repeat myself all over.

-- 
 Dipl.-Inform. Felix Palmen  <felix@palmen-it.de>   ,.//..........
 {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
 {pgp public key}     http://palmen-it.de/pub.txt   //   """""""""""
 {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A

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

#151058

>> The complexity of the shown code is a mangnitude lower than
>> it would he for the same functionality in C.

> C obviously isn't the language *you* want to use.

That's like saying:
"Assembly obviously isn't the language *you* want to use".

> Your obvious attempt shifting the interpretation of "complexity"
> from the language/runtime to some particular code written won't
> trigger me repeat myself all over.

The C-language hasn't the facilities to build such a smart runtime
C++ has.

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

#151081

On Sun, 5 Apr 2020 11:45:05 +0200, Bonita Montero
<Bonita.Montero@gmail.com> wrote:

>The C-language hasn't the facilities to build such a smart runtime
>C++ has.

That's begging the question, considering that it all runs on the same
von Neumann architecture. Or do you suppose the first C++ runtime was
written in C++?

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

#151086

>> The C-language hasn't the facilities to build such a smart runtime
>> C++ has.

> That's begging the question, considering that it all runs on the same
> von Neumann architecture. Or do you suppose the first C++ runtime was
> written in C++?

Of course the C++-runtime is written in C++.
But the first C++-compilers were translators to C (Cfront).

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

Page 1 of 5  [1] 2 3 4 5  Next page →

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

csiph-web