Typical project memes

>we need to have a file for every little block of code
>..and a separate makefile per directory
>plus a dozen of config files and crap that get written in .gitignore
>pull dependencies straight from github
>author creates issues as to-do list
>Last updated 3 years ago, but 120 pull requests not answered
>400 forks with minor differences because programmers are naturally autistic and can't stand others code

:/

Who are you quoting?

we need to have a file for every little block of code

I much prefer this to the alternative. plus it makes version control easier

>>3
Nigel Farrage

>>5
Tsk.

>>6
Nigger.

>>7
*African-American. Tsk.

>>8
N I G G E R
N I G G E R

>>1
Overdesigned, native code pulling dependencies from Shithub is typical? Do you only look at crap used by no one?

My typical native project is has source files with line counts that make a fresh grad blush (headers are a pain and LTO is hard, let's just put it all in one file!) and bundles source for all its dependencies (integrating version control is painful, just untar the upstream source, commit and forget it for years!). Oh, and it's part of a product that makes money and has no automated tests so don't you dare refactor it.

>>10
Typical github project has tons of tests, actually with dynamic languages you will need them eventually.

>>11
it's time consuming enough writing C spaghetti code. if they had to write tests for segfaults and buffer overflows, they would never get anything done.

>>12
real programmers write C code
toodles!

>>12
Segfaults and overflows are the low hanging fruit really. The bigger problem is that you've often balls deep in a larger system that's outside your control (think of kernel drivers or utility libraries - without somebody else's application, or worse, somebody else's hardware, your code doesn't even run).

You can talk all day about mocking things for tests but the reality is this almost never happens. C is not like JavaScript or Java where most functions are dynamically dispatched and implementation data structures are hidden. You can't even sprinkle virtual over things like you can in C++. You basically have to add a whole new target to rebind things at build time for every test, or rewrite your code to support dynamically rebinding things in ways the production version will never do. Both are expensive in terms of development time and can impact performance adversely if you take the latter approach.

>>14
Imagine that, C++ helps people refactor and reuse code in ways that's far more work in C.

>>15
If using virtual is an option in C++, you can do the same with an explicit vtable in C. It's not a huge difference in difficulty really. If it isn't, neither language can save you from adding a separate build type for tests.

The main advantage of C++ here is that it saves you from having to invent your own object system, and train new developers to use it.

>>14
Well, yeah. That's why people don't use C.