On 08/03/2021 14:36, tylo wrote:
> Ok, last post from me for now because of time:
>
> mandag 8. mars 2021 kl. 11:46:57 UTC+1 skrev David Brown:
>>>> It is more likely that in your C code, you only need one type
>>>> of map, or one type of queue, and then you make it yourself
>>>> with the balance you want between performance, simplicity,
>>>> debugability, thread safety, etc.
>>>
>>> This is the widespread myth.
>> It is not a myth - people /do/ make their own structures as needed
>> when programming in C. It might not be a good idea, or the most
>> effective use of the programmers' time - that's another matter.
>
> Bad wording from me, I think we agree here. I meant people tend to
> think it is best to roll their own "standard" datatypes whenever they
> need them, which I think is unwise for many reasons, unless it is as
> simple as a (fixed size) stack.
Fair enough.
>
>>> lifetime of the objects. The other aspect of this is that you
>>> code is not using standard components, and therefore much harder
>>> to read, maintain and verify correctness of.
>>>
>> There are no standard containers for C - calling your library
>> "standard" does not make it so. If you (or Jacob) gain enough
>> users, developers, maintainers, documenters for your library that
>> it can be called a "de facto" standard and a fair proportion of C
>> programmers were familiar with it, then it becomes "easy to read"
>> and its correctness can be taken as given. But you don't have that.
>> (I realise this is a chicken-and-egg challenge.)
>
> I kind of made the assumption that a library like STC should be a
> sort of "pseudo" standard, it could make C a much more useful
> language than it actually is. C has a lot of attractive properties
> which c++ lost along the way, a few of them are simplicity and low
> resource demands (compile, linkage, size), but can be still as fast
> as c++ code.
Speaking for myself, I think the resources needed to compile and link
code are almost irrelevant. It does not bother me that a toolchain
installation is 700 MB. I have lots of versions of toolchains of that
size on my system. So what? I could install a new toolchain every
week, and never run out of space on even the cheapest of hard drives.
My biggest programs take perhaps 30 seconds to compile and link - /if/ I
do a clean, non-incremental, no ccache, single-threaded build. But I
don't do that for my work - so builds are typically no more than a
second or two.
I fully agree that C has some attractive properties - I am less in
agreement that C++ has "lost" them. They are different languages, with
different balances and different pros and cons. C values stability and
(relative) simplicity over features - C++ is willing to be big and
changeable in order to have more features.
> And let's be honest here, the average C application
> source code looks crap, with tons of casting, anonymous void pointers
> and poor API.
Mine do not. This kind of thing is an indication of bad design, bad
programming style, bad development methodology, bad management. It
certainly occurs in C programming - but it occurs in /all/ programming.
And a containers library will not change that.
> Every application use their own custom structures to
> represent collections of data, and maps are rarely used. Take python
> as contrast: even the simplest program use one or multiple maps -
> because it is availabe - and useful.
Some of that is a matter of using the features that are on hand in the
language you picked - some of it is picking the language with the
features you want.
>
>> If I download your library and use it with my code, it is not
>> easier to read and maintain than my own little list structure that
>> I am trying to replace. It is /harder/ to read, because your
>> library does so much more. It is /harder/ to verify, because I
>> don't know your code, I don't know if it is correct, if it will
>> work with my choice of compiler, flags, target processor, threading
>> system, etc. I don't know if it will work with interrupt functions,
>> with lists in read-only memory, etc. And to find out, I need to
>> look at the code for a dozen different list features that are
>> irrelevant for me but are part of your "standard" list container.
>
> When I talked about my lib as "standard", I referred to that each
> container is mapping c++ standard container classes, and that the
> API's base method names mapped roughly to names used by c++ container
> method.
If I want the C++ standard library, I know where to find it. And I
think that for most people familiar enough with the C++ standard library
for this similarity to be helpful, they will most likely choose C++
instead of C and your new library. But since any C containers library
will need names for types and functions, approximately copying those of
existing libraries is probably as good a choice as any.
> But of course, the challenge is that you cannot and should
> not trust it to be bug-free and to work as you expect before a larger
> community has used and tested it over a period (chicken and egg as
> you said).
Yes.
(And though I am not sure of your library's success in the C community -
Jacob's has not been as popular as he might have liked - don't take my
comments as criticism of your ideas. They are meant to show where I
think you will see challenges.)
>
> I tried to make a very focused lib with only containers. I does add a
> few unneeded "convenience" macros an methods, which could be removed
> to enhance the focus, but it does not add much complexity atm.).
>
>> /If/ you can get your library into common use, then your arguments
>> hold - until then, the opposite is true. This is the reality of the
>> situation, unfortunate and unfair though it might seem.
>
> I accept this. I don't think it is unfair, but admit it may feel like
> casting pearls before swines, because people will continue to hold
> back the C language by either avoiding such containers, or making
> their own poor versions of them, and to program even high-level
> abstractions as it was low-level details. I think this eventually
> will result in that C becomes a marginal language, unfortunately.
>
I also think that C will become a marginal language. But I think it
/should/ become a marginal language. I think C is the wrong choice for
a great deal of code that is written in C at the moment. C has its
place - in some kinds of systems code, in some low-level portable
libraries, in very small embedded systems, and as a common denominator
as an interface between libraries and programs written in different
languages. In my view, its use for applications is in the past. If you
need a container structure beyond what you can easily put together
yourself, and it is not so specialised that you /need/ to create it
yourself, then you should be questioning if C is the right choice of
language for the task. (I don't want to be too general here -
/sometimes/ it will be the right choice.)
Often you see questions about "how to I write a C program that does some
analysis and manipulation of text files?" To me, you first have to ask
"Is this a task to help me learn advanced C programming? Or is this the
kind of challenge I think is fun?" If the answer to these questions is
no, then the answer to the first one is "You don't write it in C. You
write it in Python. Your code will be much shorter, simpler, clearer,
far more likely to be correct, and will probably run faster with any
samples that are big enough for speed to matter."