Re: [dev] [libutf] Proposal for additional rune utility functions

From: FRIGN <>
Date: Tue, 10 Feb 2015 21:35:52 +0100

On Tue, 10 Feb 2015 21:21:56 +0100 wrote:

Hey k0ga,

> When you write a library one of the objects is to minimize
> what code is included in the binary when the library is linked.
> When you link with a library you extract object files from the
> archive, so all the functions of the object file are included
> in the program, even if the program don't use them.

first off, you probably are talking about static linking.
Secondly, this may have been true 10 years ago but compilers have
become smarter and cut out unnecessary parts.

> So the common way is to put every function in a different file with
> the name of the function. You can argue that in rune.c there are
> several functions, but if you look them, you will see runetochar calls
> runelen, chartorune calls charntorune, chartorune calls runelen,
> runenlen calls to runelen and fullrune calls to charntorune, so the
> dependences between them are really strong, and they are small
> functions, so it is not a big problem.
> But I think this is not the case of chartorunearr that is a uncommon
> function that has 3 calls to other functions, for example strlen and
> emalloc, so it means you are going to have them in your program even
> if you use only runelen. This is something very bad.

chartorunearr() calls charntorune(), so it fits into rune.c. The above
argument applies, meaning, that compilers cut stuff out it doesn't need.

> With the case of writerune and readrune I don't understand why
> you when them together in a file, and force the linker to include
> them, when they are no any dependences between them.

There is a logical dependency between them, as they are symmetric to
the read() and write() functions from stdio. Above argument applies



Received on Tue Feb 10 2015 - 21:35:52 CET

This archive was generated by hypermail 2.3.0 : Tue Feb 10 2015 - 21:48:03 CET