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.
The point was that STL is unusable without exception because of OOM. If you're not using exception anywhere in your codebase and you don't plan to recover from OOM, is this still an issue?
(I don't have much experience with exception handling in large codebase, I've mostly worked on codebase that disabled exceptions)
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.
These are fair points and issues like these are why many larger projects have their own custom vector-like classes. One thing I did want to call attention to is your point that C++ best practices require that objects be in well-defined states except inside methods. That's true, although it's not a language requirement, but in many cases you can get the best of both worlds through the use of lambdas. A simple example to give the flavor:
template <typename Function>
void my_vector::munge(Function initialize_gap) {
create_uninitialized_gap();
// Some of our elements now contain uninitialized memory.
// We don't want to expose this to arbitrary code, but
// it's OK to expose this to the function the user
// provided specifically to handle this.
initialize_gap(gap_begin(), gap_end());
// The gap is now initialized, so when we return from
// this method, we'll be in a well-defined state.
}
This is the standard pattern you use for such things in functional languages, and it works very well. The idea is to ensure that intermediate states are only seen by code that explicitly expects to handle them.
Your criticisms of vector are well put, but if anything they're all really problems with a particular implementation of the standard library, not the C++ language. If you make your own libraries you're free to do whatever you want, and template metaprogramming can help you gain even more performance by easily using optimized implementations for specific types, etc.
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.
What is fundamentally broken about RAII? To me that is one of the killer features of C++ over C, which requires manual goto statements to achieve something approaching RAII.
Yes I cannot fathom how you could write successful and maintainable C++ code without using RAII. How can you guarantee safe deterministic lifetimes of objects without using RAII?
If you are writing high-reliability C (think military, aerospace, industrial control systems), early return is usually prohibited by coding standards. Then again, dynamic memory allocation usually is too.
Personally, I think early return is lazy programming because not cleaning up non-RAII objects is only one class of bugs that it can introduce. Things like vector renormalization, update notification and even later sections of algorithms can all be missed by early return. Not having early return means you need to explicitly skip later code if you don't want it, rather than essentially turning on "skip-all".
* (Classic): use goto so that instead of returning directly, all branches jump to a cleanup label. This is tricky to do well, but possible.
* (Nonstandard): GCC offers a nonstandard function attribute to register a function as a destructor for this kind of thing. I'm sure they claim it was inspired by Scheme's dynamic-wind/dynamic-wind concept.
* (Memory pooling): Apache APR relies heavily on memory pools. One feature of APR's memory pools is the ability to register functions to run (in, I believe, non-deterministic order) on data when the pool is eventually destroyed.
Aargh! I should look at nonstandard features that I don't use before I say they solve problems. GCC's construcotrs and destructors (outside of C++ code) are limited to globals and statics. Marking a function a constructor guarantees it's automatically called before main(), and marking a function a destructor guarantees it's automatically called after main() completes.
The difficulty I have with them is they are open, not closed. Any piece of code can crack open a namespace and insert more names into it. Thus, you can have problems with "hijacking", where foo(int) is inserted, while unknown to you someone else inserted foo(unsigned) that does something completely different, and the compiler decides the latter is a better overload match.
Complicating things further, the names visible in a namespace are dependent on where the compiler is lexically in the code - more names can be inserted further down.
As a counterpoint, many have suggested to me that this openness is a critical capability they need for their code. My answer is that using namespaces in that manner offers little improvement over just using a prefix on the identifiers.
Well yes, it is a prefix, but it is a prefix that doesn't need to be used when you are already inside the namespace or if you explicity 'using namespace' it. If I had to type the full namespace of functions and enums all the time I'd go insane.
well yes they are open by design. If you want closed namespaces just put your functions (as statics) inside a struct.
Btw, visibility rules in a namespace (but not in a struct/class) are the same as for the global namespace, so no, a function in a namespace won't see another declared after it.
I'm not familiar with this approach, but I think it would entail code size increase for each use of the macros, and a runtime overhead for the typeof checks, correct?
If so, C++ has a nice advantage in that all the type checks are at compile-time so you don't pay any more for those, and also you don't duplicate binary code with macros.
__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.
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.)
Unfortunately __typeof__ is non-standard. Despite its usefulness it always gets left out of the standard (and with weird excuses, I think last time it was lack of implementations - despite the fact that eg. both GCC and LLVM implement it).
Interestingly, C11 defines _Generic selection, a kind of a switch for types, but its usefulness is hindered by the fact that it cannot be used in conjunction with sizeof.
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.
My Google skills are failing me here. Is `({,})` a special construct, or are the '{' and '}' metacharacters and you're just referring to variadic macros, which are standard as of C11?
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.)
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.
Only the endings, for example the feminine form of Novák becomes Nováková. When moving to a country where there's no distinction, one usually stays by the masculine form in the official documents, regardless of gender. For example, an American-born daughter of Polish immigrants inherits and uses Kowalski as her last name, but if she were born in Poland, she would use the form Kowalska (and her son would be called Kowalski, etc.)
I'm Russian, and it's very jarring sometimes to meet or read about the daughter of immigrants who has a traditionally Russian name, but keeps the masculine last name. (e.g., Katerina Ivanov - which sounds really strange due to the gender mismatch.)
If you come from a place where you surname is simply FathersnameSon or FathersnameDaughter, then yes. Eg: Bjornson or Einarsdottir (sorry Scandi friends for typos)
Well, I actually come from such a place. In Turkey it's not uncommon that a surname ends with "oğlu", meaning "son of X" where surname is the form "Xoğlu". Because of "reasons", there are no surnames ending with "kızı" ("daughter of") though - at least I've never came upon one.
Also, we never change them, even if the holder is not male.
Funnily enough, this is more widespread than one would think. I didn't know about the Turkish example.
In Spanish, all the surnames ending in -ez also mean "son of". Even many Spanish speaking people don't know (or don't care? :)) about it, as they've been used as "normal" (sorry) surnames for long now.
Lopez: Son of Lope
Rodriguez: Son of Rodrigo
Perez: Son of Pedro
Martínez: Son of Martín
etc
> Also, we never change them, even if the holder is not male.
They got "frozen" in most languages once written records got widespread enough that it became common to want to be able to cross-index registers and track family relationships. It varies by country, but often it coincides with the introduction of tax authority registers or other large national databases.
How does this scale?
Because i have never heard of a Bjornsonsonsonsonsonsonsonsonsonsonson, i think you are all called after the first ones who came up with this? What a master plan...!
