On 13-01-17 11:03 PM, Dmitry Timoshkov wrote: > Behdad Esfahbod <beh...@behdad.org> 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. -- behdad http://behdad.org/ _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
