5 ms·

>CIDLib is the product of decades of work by the author Shame to see it spent on this instead of virtually anything else. After skimming this a bit, I feel tha

>CIDLib is the product of decades of work by the author Shame to see it spent on this instead of virtually anything else. After skimming this a bit, I feel that realistically no company, organization, or individual should rely on this codebase due to its license and contribution by only one individual. I'd rather use Boost or well-established and popular third-party libraries to solve the problems this repo attempts to solve. What if you're delivering software to a client and they find an issue with the JSON parser? HA! Time to switch libraries, because you legally can't fix the issue for them. What a horrible idea.

ktpsns 8y ago
While that is a quite negative comment, it was also my first though. Even worse, I've seen another codebase veeery similar to this one, implementing all kind of stuff which is part of the standard library in "sane", I e. more higher level programming languages (thinking of "batteries included" Python). It looks like a trap where decades long C++ programmers go into: Programming basic libraries which where done by other people so many times. My assumption is that this happens because C++ libraries in general have a steep learning curve (thinking of some templated boost libs) and the obvious missing standard dependency management in CPP.
- dleslie 8y ago
  In no small part it's because C++ has lacked a package manager. The barrier for a library to become common and canonical is much larger as a result.
  - rienbdj 8y ago
    We also see remarkably shallow dependency graphs in the C++ world. Many projects are only a few layers on top of Boost! I made a few dot graphs if people are interested.
    - asveikau 8y ago
      How many layers atop boost would satisfy you? Boost seems pretty high level to me, and not like it needs a lot of abstraction atop its ... abstractions. This is where I see this weird disconnect between communities. A C person doesn't want layers.
      - dleslie 8y ago
        C++ is not C. For that we have C.
        asveikau 8y ago
        I know C++ is not C, I have worked in both on both distinct and common occasions, and if you know what I mean by that shorthand, you know that the point stands. C++ people aren't superfans of layers upon layers for no reason either. Boost doesn't need a wrapper.
      - ktpsns 8y ago
        > A C person doesn't want layers. Really? So why are C persons then using formatted output libraries (printf, part of the standard library), libraries for regular expressions (PCRE), GUI toolkits (Gtk+, sitting ontop of Glib)? I absolutely second that in the C/C++ world, we see shallow layers of abstraction, but nevertheless they are there. In my experience, the seperation happens frequently because people seperate basics from their code, such as in the given Glib/Gtk+ example.
        asveikau 8y ago
        The sense I mean this in is "layers for no reason". In GTK+ everything has a clear purpose: * glib: Portable OO and data structures for C * gdk: Interaction with the windowing system * cairo: Drawing * gtk+: widgets An application touches each of these directly according to its needs. Nobody in their right mind would say "we need a wrapper to abstract glib". Which is a suggestion here for boost. Pretty senseless. But I think the subtext of this discussion is that all the javascript kids expect 20 layers deep and the top ones get rewritten every year or they're considered obsolete, meanwhile the bottom 18 or so are "too close to the metal" for a reasonable person to work with. A C and C++ person of a particular mindset will seek to avoid such a thing. You want to be able to have the whole picture in your head. From this angle it's a very weird complaint to say "I counted how many layers there were and it was too small!"
f-jin 8y ago
This is honestly one of the most bizarre projects I have seen. I fail to understand the "open-source-but-not-quite" attitude of the author.
gok 8y ago
It's funny you mention JSON parsers and Boost in particular. The Boost JSON parser is an abomination. It's written as a parser generator in template code, so any file which includes it gets about 10 seconds of compile time just for that. It also blatantly violates the JSON spec and gives little to nothing in terms of parse error messages. Oh and until recently it was neither thread safe nor reentrant (you could not parse two JSON files on two different threads in the same process because it used shared global state for all parsing). I remain baffled that anyone uses boost for anything in production.
- AboutTheWhisles 8y ago
  I'm sure there are good parts to boost. I have no idea what they are, but just by sheer quantity, something must be worth using.
  - stochastic_monk 8y ago
    You’re right. For a few examples: Smart pointers (unique, shared, auto), now part of the standard <random> The new Filesystem TR unordered_{map,set} enable_if/type_traits Some is probably less important, but they’ve been instrumental in moving the C++ standard library forward.
    - AboutTheWhisles 8y ago
      Those were influential and have a had a very positive effect on modern C++ without a doubt. Now that they are part of the standard though there are fewer reasons to use anything from boost, largely because it is a double edged sword of compile times and dependencies.

ktpsns 8y ago

While that is a quite negative comment, it was also my first though. Even worse, I've seen another codebase veeery similar to this one, implementing all kind of stuff which is part of the standard library in "sane", I e. more higher level programming languages (thinking of "batteries included" Python). It looks like a trap where decades long C++ programmers go into: Programming basic libraries which where done by other people so many times. My assumption is that this happens because C++ libraries in general have a steep learning curve (thinking of some templated boost libs) and the obvious missing standard dependency management in CPP.

dleslie 8y ago
In no small part it's because C++ has lacked a package manager. The barrier for a library to become common and canonical is much larger as a result.
- rienbdj 8y ago
  We also see remarkably shallow dependency graphs in the C++ world. Many projects are only a few layers on top of Boost! I made a few dot graphs if people are interested.
  - asveikau 8y ago
    How many layers atop boost would satisfy you? Boost seems pretty high level to me, and not like it needs a lot of abstraction atop its ... abstractions. This is where I see this weird disconnect between communities. A C person doesn't want layers.
    - dleslie 8y ago
      C++ is not C. For that we have C.
      - asveikau 8y ago
        I know C++ is not C, I have worked in both on both distinct and common occasions, and if you know what I mean by that shorthand, you know that the point stands. C++ people aren't superfans of layers upon layers for no reason either. Boost doesn't need a wrapper.
    - ktpsns 8y ago
      > A C person doesn't want layers. Really? So why are C persons then using formatted output libraries (printf, part of the standard library), libraries for regular expressions (PCRE), GUI toolkits (Gtk+, sitting ontop of Glib)? I absolutely second that in the C/C++ world, we see shallow layers of abstraction, but nevertheless they are there. In my experience, the seperation happens frequently because people seperate basics from their code, such as in the given Glib/Gtk+ example.
      - asveikau 8y ago
        The sense I mean this in is "layers for no reason". In GTK+ everything has a clear purpose: * glib: Portable OO and data structures for C * gdk: Interaction with the windowing system * cairo: Drawing * gtk+: widgets An application touches each of these directly according to its needs. Nobody in their right mind would say "we need a wrapper to abstract glib". Which is a suggestion here for boost. Pretty senseless. But I think the subtext of this discussion is that all the javascript kids expect 20 layers deep and the top ones get rewritten every year or they're considered obsolete, meanwhile the bottom 18 or so are "too close to the metal" for a reasonable person to work with. A C and C++ person of a particular mindset will seek to avoid such a thing. You want to be able to have the whole picture in your head. From this angle it's a very weird complaint to say "I counted how many layers there were and it was too small!"

f-jin 8y ago

This is honestly one of the most bizarre projects I have seen. I fail to understand the "open-source-but-not-quite" attitude of the author.

gok 8y ago

It's funny you mention JSON parsers and Boost in particular. The Boost JSON parser is an abomination. It's written as a parser generator in template code, so any file which includes it gets about 10 seconds of compile time just for that. It also blatantly violates the JSON spec and gives little to nothing in terms of parse error messages. Oh and until recently it was neither thread safe nor reentrant (you could not parse two JSON files on two different threads in the same process because it used shared global state for all parsing). I remain baffled that anyone uses boost for anything in production.

AboutTheWhisles 8y ago
I'm sure there are good parts to boost. I have no idea what they are, but just by sheer quantity, something must be worth using.
- stochastic_monk 8y ago
  You’re right. For a few examples: Smart pointers (unique, shared, auto), now part of the standard <random> The new Filesystem TR unordered_{map,set} enable_if/type_traits Some is probably less important, but they’ve been instrumental in moving the C++ standard library forward.
  - AboutTheWhisles 8y ago
    Those were influential and have a had a very positive effect on modern C++ without a doubt. Now that they are part of the standard though there are fewer reasons to use anything from boost, largely because it is a double edged sword of compile times and dependencies.