4 ms·

As someone with a very casual knowledge of C, I am thankful when people do this. All you need to do is #include "x" and it just works, having to configure the c

As someone with a very casual knowledge of C, I am thankful when people do this. All you need to do is #include "x" and it just works, having to configure the compiler and linking can be painful. Experienced developers might see it as a disadvatage for some reason, but it is a godsend for beginners.

Sir_Cmpwn 8y ago
I think it just trains beginners on how to do things wrong. The basics of linking two pieces of code together aren't terribly complicated and are essential C knowledge.
- microcolonel 8y ago
  > I think it just trains beginners on how to do things wrong. What gives you the impression that this is the "wrong" way to do this? How many beginners are going to be looking to μUBSan for guidance on how to structure their generic library? And it's not like linking isn't involved, you still end up linking the one object that is created from that source file (unless you #include it, which would also probably work).
  - Sir_Cmpwn 8y ago
    >What gives you the impression that this is the "wrong" way to do this? It's far less maintainable and goes against the grain of how people expect libraries to behave. >How many beginners are going to be looking to μUBSan for guidance on how to structure their generic library? Any beginner who uses it. You make a good point, though, this isn't exactly a beginner-tier tool so why is it being distributed like one? >unless you #include it, which would also probably work I think that's what they're expecting you to do. And if you're linking anyway, what does it matter if it's one object or several? Or more realistically, a single archive (built from many objects which are themselves built from many source files)?
    - microcolonel 8y ago
      > It's far less maintainable... How so? What form of maintenance does it prevent or hurt? > ...and goes against the grain of how people expect libraries to behave. You could dynamically link it if you wanted, it's just that there is little reason to. This approach is inclusive: it enables all three major ways people use libraries. Honestly, I don't see what the problem is. You're entitled to prefer dynamic linking or static linking, but how does it hurt you that it can also be used another way?
      - Sir_Cmpwn 8y ago
        I'm not arguing about dynamic versus static linking. In fact, I think dynamic linking is pretty bad. I'm just arguing against distributing libraries all in one big C file. You can statically link against an archive built from several sources.
        microcolonel 8y ago
        But why does it bother you so much? Clearly this is a feature for somebody else, and it's not an issue for you.
        Sir_Cmpwn 8y ago
        As I said elsewhere: >I don't consider open source projects a black box, I evaluate every project under the lens of someone who expects to someday have to work with the code myself and send patches upstream. And I think I'm squarely in the target audience for this tool anyway. What makes you think it's a feature for someone else?
        microcolonel 8y ago
        > What makes you think it's a feature for someone else. The fact that they mention it specifically and proudly on the front page indicates to me that the author, and the NetBSD maintainers who accepted it, consider it good that it is a single, largely self-contained source file. It is only ~1300 source lines, so I don't see why it should necessarily be split out. Something tells me the original authors and the ongoing maintainers of this file have a better idea what value this choice represents than you do (since you haven't said anything particularly compelling in favour of splitting this into several files and objects).
- MaulingMonkey 8y ago
  > The basics of linking two pieces of code together aren't terribly complicated The basics aren't complicated, but doing it correctly requires more than the basics IME. Each platform does it slightly differently, and I support multiple platforms. I've repeatedly seen static libs linked into multiple dynamic libs and cause all kinds of trouble because there's multiple copies of global data, of which only one was probably initialized correctly. I have seen multiple different stdlibs successfully linked into the same program, causing ABI mismatches that compiled, linked, and "usually" ran at runtime - but had some nasty crashes to be debugged, because std::vector<int> was an entirely different type at the call site vs the callee's implementation. Version mismatches of other SDKs are also common. I've had all kinds of weird constraints on what compilation and link flags I could use based on what static libs I've linked (e.g. being unable to link with exception handling enabled because one of my dependencies was built with it disabled) Additionally you don't have libs for all my platforms (or sometimes any of them), so I have to build from source anyways, so I have to write build rules for your lib because the defaults probably don't work, and because build rules are never documented I have to mostly reverse engineer intent to do so - possibly without a viable build in the first place if your only working libs are for platforms I don't use. Or if I'm lucky enough that reusing your build rules is viable, I have to try and sync various flags between my projects written in one build system and your projects written in yet another build system, and prevent these from getting out of sync for the remainder of the lifetime of the project. I likely have to jump through all kinds of stupid hoops like installing the exact right version of python and installing undocumented but required packages just to run the configuration scripts that drive the build. ...or for single-source libs, I can probably just drop a single file into one of my existing projects and have everything work. Okay, so some of that was just because they actually cared about minimizing how painful it is to integrate their library at all, but having a single .c file helped too. I'd only write a single .c library for the simplest of libraries - or as an automatically generated file - but it can help.
- drb91 8y ago
  Linking is only one step in package management. Besides, in this scenario, it may not be viewed as a library a user should manage. The only benefit I can think of from linking is getting security patches without recompiling. That might easily not be a priority. Why is that a problem?
  - Sir_Cmpwn 8y ago
    I'm not talking about package management.
    - deleted 8y ago
      [deleted]
pebers 8y ago
You need to do more than just #include it - it is implemented in one .c file but that is not a header, so you'd still need to compile that separately and link it in somehow.
- mnarayan01 8y ago
  If you include it (possibly indirectly) in a file which you compile, then no, you do not need to compile it separately.
- TeMPOraL 8y ago
  Not really. All you need to do is: #ifndef __onefilelib__ #define __onefilelib__ #include "onefilelib.c" #endif (Also potentially defining "main" as something else, if it happens that the "onefilelib.c" has an entry point for some reason.)
  - abenedic 8y ago
    You should really be careful about c preprocessor macros when you do things like this with .c files. You should always undefine any macros defined in a file which are not properly namespaced(as much as C allows for pseudo namespacing).
  - deleted 8y ago
    [deleted]
  - sigjuice 8y ago
    Is there a prominent C code base that does this sort of thing? I’m sorry this is all very questionable advice IMHO. What would be one word in a makefile (onefilelib.c) is a 4-line jumble of preprocessor macros, names starting with __ are reserved, and the suggestion to redefine main and entry points smells like more #ifdef spaghetti.
    - abenedic 8y ago
      I am not sure of a prominent code base that does this exactly, but some people do similar things with "amalagmated builds". Like https://www.sqlite.org/amalgamation.html https://www.sqlite.org/amalgamation.html

Sir_Cmpwn 8y ago

I think it just trains beginners on how to do things wrong. The basics of linking two pieces of code together aren't terribly complicated and are essential C knowledge.

microcolonel 8y ago
> I think it just trains beginners on how to do things wrong. What gives you the impression that this is the "wrong" way to do this? How many beginners are going to be looking to μUBSan for guidance on how to structure their generic library? And it's not like linking isn't involved, you still end up linking the one object that is created from that source file (unless you #include it, which would also probably work).
- Sir_Cmpwn 8y ago
  >What gives you the impression that this is the "wrong" way to do this? It's far less maintainable and goes against the grain of how people expect libraries to behave. >How many beginners are going to be looking to μUBSan for guidance on how to structure their generic library? Any beginner who uses it. You make a good point, though, this isn't exactly a beginner-tier tool so why is it being distributed like one? >unless you #include it, which would also probably work I think that's what they're expecting you to do. And if you're linking anyway, what does it matter if it's one object or several? Or more realistically, a single archive (built from many objects which are themselves built from many source files)?
  - microcolonel 8y ago
    > It's far less maintainable... How so? What form of maintenance does it prevent or hurt? > ...and goes against the grain of how people expect libraries to behave. You could dynamically link it if you wanted, it's just that there is little reason to. This approach is inclusive: it enables all three major ways people use libraries. Honestly, I don't see what the problem is. You're entitled to prefer dynamic linking or static linking, but how does it hurt you that it can also be used another way?
    - Sir_Cmpwn 8y ago
      I'm not arguing about dynamic versus static linking. In fact, I think dynamic linking is pretty bad. I'm just arguing against distributing libraries all in one big C file. You can statically link against an archive built from several sources.
      - microcolonel 8y ago
        But why does it bother you so much? Clearly this is a feature for somebody else, and it's not an issue for you.
        Sir_Cmpwn 8y ago
        As I said elsewhere: >I don't consider open source projects a black box, I evaluate every project under the lens of someone who expects to someday have to work with the code myself and send patches upstream. And I think I'm squarely in the target audience for this tool anyway. What makes you think it's a feature for someone else?
        microcolonel 8y ago
        > What makes you think it's a feature for someone else. The fact that they mention it specifically and proudly on the front page indicates to me that the author, and the NetBSD maintainers who accepted it, consider it good that it is a single, largely self-contained source file. It is only ~1300 source lines, so I don't see why it should necessarily be split out. Something tells me the original authors and the ongoing maintainers of this file have a better idea what value this choice represents than you do (since you haven't said anything particularly compelling in favour of splitting this into several files and objects).
MaulingMonkey 8y ago
> The basics of linking two pieces of code together aren't terribly complicated The basics aren't complicated, but doing it correctly requires more than the basics IME. Each platform does it slightly differently, and I support multiple platforms. I've repeatedly seen static libs linked into multiple dynamic libs and cause all kinds of trouble because there's multiple copies of global data, of which only one was probably initialized correctly. I have seen multiple different stdlibs successfully linked into the same program, causing ABI mismatches that compiled, linked, and "usually" ran at runtime - but had some nasty crashes to be debugged, because std::vector<int> was an entirely different type at the call site vs the callee's implementation. Version mismatches of other SDKs are also common. I've had all kinds of weird constraints on what compilation and link flags I could use based on what static libs I've linked (e.g. being unable to link with exception handling enabled because one of my dependencies was built with it disabled) Additionally you don't have libs for all my platforms (or sometimes any of them), so I have to build from source anyways, so I have to write build rules for your lib because the defaults probably don't work, and because build rules are never documented I have to mostly reverse engineer intent to do so - possibly without a viable build in the first place if your only working libs are for platforms I don't use. Or if I'm lucky enough that reusing your build rules is viable, I have to try and sync various flags between my projects written in one build system and your projects written in yet another build system, and prevent these from getting out of sync for the remainder of the lifetime of the project. I likely have to jump through all kinds of stupid hoops like installing the exact right version of python and installing undocumented but required packages just to run the configuration scripts that drive the build. ...or for single-source libs, I can probably just drop a single file into one of my existing projects and have everything work. Okay, so some of that was just because they actually cared about minimizing how painful it is to integrate their library at all, but having a single .c file helped too. I'd only write a single .c library for the simplest of libraries - or as an automatically generated file - but it can help.
drb91 8y ago
Linking is only one step in package management. Besides, in this scenario, it may not be viewed as a library a user should manage. The only benefit I can think of from linking is getting security patches without recompiling. That might easily not be a priority. Why is that a problem?
- Sir_Cmpwn 8y ago
  I'm not talking about package management.
  - deleted 8y ago
    [deleted]

pebers 8y ago

You need to do more than just #include it - it is implemented in one .c file but that is not a header, so you'd still need to compile that separately and link it in somehow.

mnarayan01 8y ago
If you include it (possibly indirectly) in a file which you compile, then no, you do not need to compile it separately.
TeMPOraL 8y ago
Not really. All you need to do is: #ifndef __onefilelib__ #define __onefilelib__ #include "onefilelib.c" #endif (Also potentially defining "main" as something else, if it happens that the "onefilelib.c" has an entry point for some reason.)
- abenedic 8y ago
  You should really be careful about c preprocessor macros when you do things like this with .c files. You should always undefine any macros defined in a file which are not properly namespaced(as much as C allows for pseudo namespacing).
- deleted 8y ago
  [deleted]
- sigjuice 8y ago
  Is there a prominent C code base that does this sort of thing? I’m sorry this is all very questionable advice IMHO. What would be one word in a makefile (onefilelib.c) is a 4-line jumble of preprocessor macros, names starting with __ are reserved, and the suggestion to redefine main and entry points smells like more #ifdef spaghetti.
  - abenedic 8y ago
    I am not sure of a prominent code base that does this exactly, but some people do similar things with "amalagmated builds". Like https://www.sqlite.org/amalgamation.html https://www.sqlite.org/amalgamation.html