Re: [ft-devel] Patch to fix the ttsubpix implementation

[Dmitry Timoshkov]

Behdad Esfahbod <address@hidden> wrote:

> >>>> Guys, I'm not a hardcore C coder, and don't know about private RAM
> >>>> allocation per-process, and how that's impacted by putting structs
> >>>> inside of .c files instead of .h files.  Of course, I'm willing to
> >>>> understand why that's the case, I just don't necessarily know some
> >>>> of that stuff.  So, likely all code that I write is going to have
> >>>> the potential of being implemented more efficiently by people with
> >>>> more experience in coding.  I don't really want to burden you guys
> >>>> with "babying" me through the best way to implement code, but if you
> >>>> can nudge me in the right direction sometimes that would be helpful.
> >>
> >> If you have some time to read, this is a good place to start:
> >>
> >>   http://www.akkadia.org/drepper/dsohowto.pdf
> > 
> > Reading that paper made my head hurt :) It's full of descriptions of
> > various tricks and jumps through the hoops how to avoid limitations of
> > dynamic libraries implementation under Linux which is based on old,
> > questionable and inefficient design. This really has nothing to do
> > with the problem David has fixed.
> 
> There's an expression that programmers use: "think low-level, write
> high-level".  The point being that to write good code one has to understand
> how the compiler and the machine work, but then write high-level code that
> translates to good machine code.  What David found was indeed different:
> defining variables in a header file is a basic mistake of C / C++ programming,
> but when you get past that, making sure that your variable don't end up
> consuming private per-process memory (specially when dealing with strings) has
> a lot to do with understanding how the linker works, and what is dealt with in
> the mentioned paper.

I'd argue that this document is hightly gcc/ELF/Linux specific, and may not
apply to other platforms, so it can't be considered or even recommended as
a general set of rules for a programmer, especially since Freetype is a
library that's used on many different platforms.

A programmer doesn't need to know about flawed dynamic linker design when
his mistake is just in placing a relatively large data structure in a shared
.h file instead of the .c file it's actually being used.

-- 
Dmitry.