fish2000's comments

Vice has it: https://news.vice.com/en_us/article/qvx3wp/active-shooter-re...

tl;dr this article has no Native American weaponry review nor far-Eastern bear-hate listicles, meh

I know you were probably just throwing out the “90%” statistic, but if you take that as a given, the implication that 10% of the libstdc++ bugs on file are legit is a worrisome notion in and of its own right. I don’t want to be responsible for triaging those bugs (and nor do you, I am guessing; this being why the reports are valueless) but the fact that this is the bug rate in this, a gold-standard library in common, ubiquitous use… well as far as I can see, this is the context in which that the OP’s article should be considered.

… I build all of my C++ projects with Clang and link them against libc++, so I don’t know if I am dodging a very high-caliber bullet (so to speak) or if the other shoe will drop at some point, and I will find myself going down the OP’s rabbit-hole of library-bug investigation.

Do not use magic. — Strongly agree.

Do not use macros. — Absolutely I agree: I involuntarily grimace whenever I look at and/or things like Boost MPL, or the wartier corners of the Python C-API’s underbelly, etc. I only use macros as straight-up batched ⌘-C-⌘-V:

    #define DECLARE_IT(type, value) extern const type{ value }
    DECLARE_IT(int, 0);
    DECLARE_IT(int, 1);
    DECLARE_IT(float, 0.0f); // etc
    #undef DECLARE_IT

Do not use typedefs to hide pointers […] — I cannot stand it when people do this. That asterisk is as syntactically valuable to you, the programmer, as it is essential to your program’s function. If the standard library can slap asterisks on file and directory handles than so can you (and by “you” I specifically include whoever wrote the `gzip` API among other things).

[…] or to avoid writing “struct” — Huh, actually I feel the opposite, I think all those “struct” identifiers are clutterific, much like excessive “typename” id’s in C++ template declarations. But so aside from the points where I totally disagree with the author, I absolutely feel the same way 100%.

Separation of concerns, fungibility, limited exposure, a lower bar on future legal entanglements … I could go on

I haven’t got a ton of experience in this arena, but what I have done in the past is: 1) incorporate the larger venture as an LLC (“My Company, LLC”); 2) incorporate the specific project as a C-Corp (“My Company’s App, Inc.”) – my partners and I own the LLC, which controls the C-Corp, which holds the assets of the project.

Specifically, this makes it easier if we want to sell ”My Company’s App“ to a Facebook- or Google-class buyer entity. The LLC can also incorporate a bank, if ”My Company’s App“ needs to start conducting transactions that necessitate the use of (say) a Federal Reserve client (á la Venmo or Stripe).

The hazy miasma visions of a perfect past can legitimatize themselves, in some, with far far less than 10 to 20 years. Some can do it in a span of weeks – q.v. “Where I Was From,” the memoir by Joan Didion (which specifically is about California, but is quite relevant to these topics to anyone most anywhere in the USA).

Yes, there is a Zen state of C++ programming wherein you, the programmer, surrender to the wisdom of the compiler, and in doing so are liberated from caring about the minutiae of the type system, to be carried forth, skyward, on the twin winds of inference and overload resolution. I do enjoy that. RTTI is nothing like this – it’s a red herring, neither elegant nor powerful… at best it’s a misnomer (it’s more like RTT total lack of I, amirite) and at worst a distraction.

I dislike exceptions too, but in a difference-of-opinion way where I can be like “OK, that otherwise legible and reasonable code uses exceptions, unlike mine” and it doesn’t make me grimace like I involuntarily do for RTTI… I’d love to be mistaken tho, anyone with an inspiring counterexample, do share.

Good start but -- some C++ stuff is wrong, e.g. in the bit on friend functions, a member function prototype is written with an empty block instead of a terminal ";". Subtle, but you know. Also, more subjectively, std::string is described as immutable, but with no further discussion about what that means or how that might work.

Just sayin. Frankly I like how it's not Wikipedianishly drowning in citations and/or demands for same -- but how does it get updated? I immediately tried to expand on those two issues I mentioned but there was no sort of UX recourse for my pedantic urges (FWIW)

Wow this takes me back – 2007, those were the days. Back before so many flagship projects had frankensteined libLLVM into their innards; before every single JavaScript framework was required by law to include at least one CLT whose executable name ended in 'c'; back when GCC on Apple was just a matter of /usr/bin, and not a parade of endless Homebrew formulae PRs… srsly dogg this is an excellent article, a product of its time but a bonafide bulwark, presciently on the precipice of paradigm. I +1'ed.

… also one of the forthcoming Clang projects is a static-analysis tool (á la `clang-format`) for replacing any `auto` decls with the actual typename, so you can write lazy code without appearing unscrupulous at code reviews

These are good rules – as in liquor advertisements, it’s advisable to always accompany a declaration that uses `auto` with a rejoinder in the comments to Please Enjoy Responsibly

“A Variadic Template A Day Keeps The Job Security In Play”

OP I believe you meant to say “q.v.” instead of “e.g.”

I am really into C++ but it has the same problem that Perl has – it does not try to stop anyone from using it to express themselves in an ugly or inscrutable fashion – and this is a frustrating aspect of dealing with the C++ ecosystem/community.

Personally I spent enough time writing Python to acquire significant coding OCD about things like whitespace, file/directory layout, documentation. When I write C++ I have two prime directives: 1, keep it compulsively tight and legible; 2, use the idioms of C++ to sort out other peoples’ APIs (as opposed to reinventing wheels). I stick to these rules like they’re a diet, it is easy to let your mind wander and find that you’ve spent half the day writing a framework instead of solving your problem; metaphorically this is the equivalent of forgetting to go to the gym and then ordering pizza for dinner. Along these lines I give myself one premature optimization a week, like as a cheat.

I find it is most productive when you are using C++ “against” something. For example I just wrote a bunch of templates that eliminate like 90% of the requisite API boilerplate the Python C API calls for – that was simultaneously satisfying in both the “I totally solved that specific problem” and “dogg check out this clever snippet I wrote” senses of ‘satisfying’. Contrastingly, the last time I created a class hierarchy it was a sprawling regrettable mess – I am more “structure-oriented”, versus “object-oriented”, but still.

q.v. another blog by a fantastic marketer-who-codes, Cody Boyte: https://medium.com/@codyboyte

Naturally, this articles’ photo of the mud-slaked Rubenesque woman was the image on my screen when my new co-worker dropped in on me… calling this piece NSFW feels a bit prudish but let my experience be your warning

q.v. The Manifesto of the Futurist Programmers, 1991 (linked) – based on the Futurist Manifesto, signatories include one Milanese painter, and 5 noteworthy denizens of Silicon Valley…

In the interest of not spoiling I leave it as an exercise to the reader to click through and scroll down

This is indeed a great intro article.

For those interested in seeing examples of LLVM hacking in action, I would recommend reading the source for Halide – https://github.com/halide/Halide – which is an image-processing DSL implemented in C++ and piggybacking on LLVM. I myself learned a lot about LLVM this way.

    holler ("Preposterous fd value %d", fd);

(I just had to debug a descriptor mess and this style of freewheeling 90’s-style documentation rejuvenated me w/r/t all of that, hah)