3 ms·

That's all fine and dandy. You can quote all the shiny names you want from your domain and write a novel about them as it seems you are in the mood for doing th

by wott 9y ago

That's all fine and dandy. You can quote all the shiny names you want from your domain and write a novel about them as it seems you are in the mood for doing that, it will not change anything to what I witness on each C forum I follow: it is always: 1. young people 2. coming from Javascript 3. coming from the land of IDEs which blur the difference in nature between files, between external and internal files, between copy inside the project and inclusion/linking from outside, etc. 4. who take a try at C, because they have heard C is hardcore or something like that and they want to taste low-level to become real programmers, not just web devs 5. who offer or request single header libraries because they have no idea it could be otherwise, or because they think linking or writing a basic makefile is an issue an enormous amount of work, because they come from the land of language-dependant automatic package managers. That's somehow the same horrible movement that ends up giving us projects which ship with all the dependencies inside the package. Well, not all dependencies, just almost all, because there will always be a random couple of libraries you'll have to install yourself, without knowing why... And then those 'internalised' libraries will never get patched, never get updated, never get fixed, that's wonderful. End of story. I do not even know why, along your text wall, you go on fighting things you pretend I have said, when I haven't. I haven't spoken of this library in particular, I haven't spoken of gamedev (I would not touch that with a 10 feet pole), I have spoken of what I witnessed. And that's a true phenomenon that started only 2 or 3 years ago.

_dcwr 9y ago
You have answered to: > I really do not understand why 'single header' is considered a good thing, but I see this more and more often on libraries. What is the reason all the code is put in the header file? With: > I have mostly seen it done by (young) people who come from web dev. They bring their bad habits together with them. And they usually don't get a very warm welcome for that. (...) And now you ask why I've listed all these libraries to prove otherwise? This is what I'm disproving with this list of old, experienced, non web devs writing good libraries that are well received and reliable. You can't make a sweeping statement about an entire paradigm of writing libraries and then claim you just happened to ignore all of the facts that contradicted it like existence of SQLite, STB and the entire gamedev industry. Your logic is on the level of saying that "most nuclear power plants go boom" and claiming you just don't care about any except Chernobyl personally. Where are your examples of these bad libraries made by young web devs that are not well received? Between few examples I gave you should have at least 10 by now but instead you tell me that some people learn C because it's 'hardcore' and that new C programmers struggle with C linking (both of which are obvious facts to any C or C++ programmer). And there's nothing special with single file libraries about avoiding building or lack of updates, people can (and do) dump entire source trees into their projects to avoid having to build a separate library and it works just as well most of the time. People also do things like ship prebuilt binaries (especially C ones, which have a very stable ABI even on Windows, unlike C++) with their C or C++ project which is just as bad from the update standpoint as embedded source is or it's even worse since it tasks anyone trying to replace these with finding out how to build that library (which between CMake, premake, Scons, even changing compiler defaults - which once bit me when building a project with GCC - and God knows what else might be quite an adventure compared to just dumping the source into the project itself and rebuilding that).

by wott 9y ago

_dcwr 9y ago

You have answered to: > I really do not understand why 'single header' is considered a good thing, but I see this more and more often on libraries. What is the reason all the code is put in the header file? With: > I have mostly seen it done by (young) people who come from web dev. They bring their bad habits together with them. And they usually don't get a very warm welcome for that. (...) And now you ask why I've listed all these libraries to prove otherwise? This is what I'm disproving with this list of old, experienced, non web devs writing good libraries that are well received and reliable. You can't make a sweeping statement about an entire paradigm of writing libraries and then claim you just happened to ignore all of the facts that contradicted it like existence of SQLite, STB and the entire gamedev industry. Your logic is on the level of saying that "most nuclear power plants go boom" and claiming you just don't care about any except Chernobyl personally. Where are your examples of these bad libraries made by young web devs that are not well received? Between few examples I gave you should have at least 10 by now but instead you tell me that some people learn C because it's 'hardcore' and that new C programmers struggle with C linking (both of which are obvious facts to any C or C++ programmer). And there's nothing special with single file libraries about avoiding building or lack of updates, people can (and do) dump entire source trees into their projects to avoid having to build a separate library and it works just as well most of the time. People also do things like ship prebuilt binaries (especially C ones, which have a very stable ABI even on Windows, unlike C++) with their C or C++ project which is just as bad from the update standpoint as embedded source is or it's even worse since it tasks anyone trying to replace these with finding out how to build that library (which between CMake, premake, Scons, even changing compiler defaults - which once bit me when building a project with GCC - and God knows what else might be quite an adventure compared to just dumping the source into the project itself and rebuilding that).