The cop's behavior was inexcusable. Even if he had those orders, he could have informed her and arrest her calmly without unecessarily escalating the situation. The loss of temper is a clear sign of him being unfit for duty.
I'm also using (for now) something based on these time checks (also pure posix + local, but local is extremely portable (tests well on 7 shells), though mine's a little more involved (automatic build job timing, controlled concurrency, robust failure/cancellation with autodeletion, fancy logging, filterable implicit dependencies, dependency + counting). It scales well to about 1000 source files. Then the lag starts to feel noticable.
I once benchmarked reads with `mmap` vs `read` (http://stackoverflow.com/a/39196499/1084774) . mmap starts winning big time once the file is >= 16KiB. Copying should have similar performance characteristics.
I haven't seen it in practice, but OOM is conceivably recoverable in certain cases (e.g., exponential vector growth with large capacities fails on a 32 bit system, but switching to linear growth as a recovery strategy succeeds in allocating sufficient additional memory). But OOM errors aren't the only type of errors that you can get in ctors. Disabling exceptions makes all those errors either fatal or your class invariants become silently broken, which makes exceptions and RAII kind of a package deal in robust software.
It's a common (gcc/clang/tcc) compiler extension (chapter 6.1 of the gcc manual) that allows you to use parentheses around a compound statement to turn the compound statement into an expression whose value is the last statement in the compound statement. For example `({ int _r; if((_r=foo())) bar(); _r })` behaves like an inline function that returns `_r`. If you want to do generic vector ops purely with macros and you want to do it robustly, you effectively need for the macros to "return" a value signalling whether the potential realloc that might have happened inside the macro succeeded or not. It's a very powerful feature because it allows you to have macros that behave like ducktyped, value-returning inline functions. (Sometimes you'll need to tone down the ducktyping a little, like it's probably a good idea to use some __typeof__-based typechecks (http://stackoverflow.com/questions/41250083/typechecking-in-...) to make the compiler warn you if you attempt to memcpy doubles into an int vector from your vector__insert method.)
True. However, I think in the case of the dynamic array, this effect is minor. The macros are small, and most of the time, they end up wrapped in a function anyway. But, admittedly,it doesn't scale well to very big generics, which should be always wrapped in a function. (Eventually I plan to shove a simple transpiler in front of all my C code and do this, along with namespacing, how I think it should be done.)
Expression macros `({, })` aren't standard either. But I sort of go with, if all gcc/clang/tinycc support it and it's a highly useful feature, then it's part of C as far as I'm concerned. It would certainly be nice if ({,}),__typeof__, and __label__ became part of the C standard, though.
__typeof_ is a compile-time feature. It's like C++'s decltype. (You can make C++'s auto out of it too.) There's is a potential for code size increases with this approach, that's true. But the potential also exists with inlinable vector methods.
I like my C alternative better. I pass growth factors/increments as parameters to the vector macros so that I can affect how it grows on capacity exhaustion during each call and I have macros for creating and closing uninitialized gaps. C++ loses on many potential optimizations by insisting that its types always be in fully well-defined states except inside methods. Moreover the particular GNU implementation of the STL on Linux completely fails to turn certain vectors methods into memsets, memcpies and memmoves where it could, which pesimizes those particular ops by like two decimal orders of magnitude. The insistence on using new/delete based allocators instead of reallocs is a significant pessimization too. Reallocs perform, on average, several tens of percents better than new allocs followed by copies. An even more noticable pessimization is in the compilation times. Including `<vector>` adds good chunks of a second to the build time of an average-length translation unit. In comparison, working with C, even with all my generics included, on top of a good build system makes me feel as if I was working with a scripting language. No lags.
In my codebase, I use expression macros (with a little bit of __typeof__-based type checks) to do it fully generically. Much of what you think you need C++ for can be done almost just as succinctly on top of plain C (I'm talking automated scope cleanups, semi-automated error handling, many generic things) and the compile times fly. I agree C++ has had some good ideas. In fact, I originally wanted to use it. But I came to the conclusion that it's too bloated, and more importantly, fundamentally broken in certain ways (RAII, exceptions, even templates and namespaces), and I ended up emulating what I think the good parts of C++ are on top of plain C. When C++ programmers think C, they usually think lack of generics and lots of explicit manual, micromanagement and pointer arithmetic, but it can be a lot more than that.
A very smart programmer who's made a large contribution to society decides not to have kids while people of which neither can be said breed like rabbits. Looks like we'll be watering crops with Brawndo pretty soon.
Czech (his passport) changes endings all over the place. It's how our grammar works. Nouns and adjectives have different endings depending on their contextual gender associations. Czech last names are either adjectives (rarer), in which case the male form ends with ý and the female form ends with á (the latter generally denotes femininity), or nouns, in which case the female form gets turned into an adjective with the ová ending. For example, if your last name is Kovář == Smith, your wife's or daughter's last name would be Kovářová, which could be loosely translated as "of Smith" or "of Smith material" (Kovářka would be the Czech noun for "a female Smith", but female noun surnames don't turn up in formal Czech -- though they make reasonable abbreviations/nicknames among friends). Czech has also the very similarly sounding ova ending (as opposed to ová) which literally denotes possession in addition to the female gender (Kovářova == a (male) Smith's). This doesn't turn up in Czech last names, but it does in other Slavic last names (notably in Russian last names), which makes it sound familiar. Whether it also denotes possession in those languages, I don't know.
I appreciate your appreciating my jibe. Good luck with your suite and sorry for the little bit of negativity. Command line apps are my favorite type of apps.
I'm quite unfond of this command suite pattern that seems to be popular in cli apps lately. It's a very git thing to do. Why not just mac-whatever1 mac-whatever2? It has less coupling, basic autocompletion out of the box, and generic autocompletion very easily generatable in a context-free fashion, but less coupling alone should be enough of a reason.
Technology may well bring about a collapse of democracy as we know it. No longer are the mediocre and the below mediocre insulated from actual decision making for reasons of impracticability. In this day and age, letting everyone vote o anything is quite realistic and as democratic as it gets.
I don't understand why someone thought it was a good idea to require that POSIX stdio should lock the thread. It slows down stdio several times compared to the nonlocking version, and it completely goes against "don't pay for what you don't use" as single threaded programs have to pay the cost too. And locking and unlocking the stream manually is like two lines of code, which a person writing MT code should be well capable of writing.