11 ms·
C++ Initialization Story
- deleted 4y ago[deleted]
- mmkos 4y agoHa. I'm quite happy that I started off my career coding in C++ and then subsequently moved away towards web tech. It's nice having appreciation for the lower-level aspects of PLs, but I feel more comfortable working at higher levels of abstraction and being able to make full-featured products with less effort, thanks to an abundance of computing power in most computers.
- atahanacar 4y ago>abundance of computing power in most computers. [citation needed]
- mmkos 4y agoMaybe I overgeneralised - I had most personal computing devices in mind, which I'm most interested in developing for. I appreciate that there's orders of magnitude more computing devices that do not fall into that category.
- atahanacar 4y agoIn my opinion as a non-professional hobbyist developer and a software "consumer", the main problem of current software trends is that they rely on computing power too much. I understand why a developer might want to quickly implement and test an idea using high level languages and no optimization. However, it feels like nowadays, developers are not moving on from the "rapid prototyping" stage to the "optimization" stage, almost like abandoning a project, yet they always keep adding new stuff. We are heading for a personal dystopia of mine everyone's attention spans are too short in every aspect of the life. People are addicted to new stimuli, whether it be the next 1 minute video in the timeline, or a new feature for the software that will never be "mature" due to all the other new features.
- mmkos 4y agoI think there's value in taking a balanced approach to writing software - use high level PLs and their frameworks but use them well (i.e. take the time to learn them and their patterns, and not just hack away). This way we're not excessively wasting resources doing redundant processing and we're not stuck for hours trying to squeeze every last bit of performance out of the cpu. I get your point about not advancing from the prototype stage in terms of the codebase, but if it's 'good enough', then there are always more important problems to tackle. As for your second point, it's already been happening for quite some time. Can we blame people though? Every product we use is engineered to perfection to beat human psychology and make us indulge more and more. It's hard to protect yourself against something like that if you realise this is a problem, let alone if you don't. It doesn't just apply to technology but other areas too, take food for example.
- afr0ck 4y agoI can't believe a 300 pages book is needed to just talk about initialisation in C++!!! Now I understand why Linus refused this craziness in the Linux kernel. I genuinely believe that C++ is just a toxic wasteland of time. It's not even that productive, fun to work with or secure. I would take C, Rust, Golang, Python anywhere, anytime.
- qwerty456127 4y agoIt's not to just talk about initialisation in C++, it's to to just talk about modern initialisation in C++! Imagine how much more ther is if you wanted to know everything about initialisation in C++ not limited to the modern things.
- nikbackm 4y agoIt's not needed. There's a lot of extra fluff like examples and such beyond the basics of C++ initialization. Also seems to have relatively little text per page in the Amazon preview [1]. [1] https://www.amazon.com/dp/B0BW38DDBK?asin=B0BW38DDBK&revisionId=&format=4&depth=1 https://www.amazon.com/dp/B0BW38DDBK?asin=B0BW38DDBK&revisio...
- ModernMech 4y agoSure but at the same time, the author says the book started as a blog and some examples, and “before you know it” was 150 pages. To me, you should have been able to write all that needs to be said about initialization several times over with that much space, let alone 150 pages more!
- dgellow 4y agoYou don’t need these 300 pages. It’s not because a book is that long that it is needed. It’s a niche book for C++ enthusiasts, like the book on std::move (one that I personally enjoyed greatly)
- mvuksano 4y agoWhich one is that? I'd like to check it out.
- keithalewis 4y agoThe reddiputians are invading HN!
- zabzonk 4y agoas someone that has been using c++ since the late 1980s, can i observe that about 75% of c++'s features are aimed at library writers? most people writing application code simply do not need to know the syntax or the semantics of this stuff - these are all features that make c++ libraries simpler, easier and more efficient to use, mostly transparent to the library user.
- FpUser 4y agoAgree 100%
- IshKebab 4y agoYeah this is definitely true. C++ clearly doesn't like "special" features like Go's map, which only the Go authors can implement. As a result it has a ton of features that are extra complicated in order to let you design easy to use APIs.
- nuancebydefault 4y agohttps://images.app.goo.gl/osKiAwVKrqof2DeL8 https://images.app.goo.gl/osKiAwVKrqof2DeL8 Animated image, no more comments needed
- mgaunard 4y agoI keep reading how C++20/17/14/11 is entirely different. I've been programming in C++ since 2004, involved in Boost then the standards committee. For me there hasn't really been such a big change, it's always the same language at core, with a few evolutions, that mostly make it slightly more terse.
- spacechild1 4y agoIMO move semantics, auto, lambdas and smart pointers have changed the way we write C++ dramatically. I work on both old and modern C++ codebases and the difference is like night and day...
- mgaunard 4y agoSmart pointers are not a language feature, and are generally a bad practice (shared ownership is a bad idea to begin with). Lambdas, just syntactic sugar for function objects. auto, you could just spell out the type and provide a mechanism to deduce it (e.g. the old result_of protocol). Move semantics, this is simply distinguishing lvalues from rvalues in overload resolution. There were other ways to do that before albeit not as accessible to the layman.
- spacechild1 4y agoI generally disagree with your assessment, but the following needs to be called out in particular: > Smart pointers are not a language feature, and are generally a bad practice (shared ownership is a bad idea to begin with). Smart pointers don't imply shared ownership, see std::unique_ptr. Or is std::unique_ptr considered bad practice as well? That would certainly be news to me ;-)
- TillE 4y agostd::unique_ptr is of course the opposite of shared ownership, in that it requires you to explicitly transfer ownership if you need to do that. It's a beautiful feature which improves code clarity and reduces bugs.
- Scubabear68 4y agoWhat amazes me about C++ is that the complexity is deliberate. I started learning it voraciously in the early 90s, read Design and Evolution of C++ and many other books. Over and over again the theme was to be broad and deep, multi-paradigm, kitchen-sink approach that should have as much power as possible, with the bizarre caveat that it had to be backwards compatible with C (mostly). I have never understood this POV, but to understand C++ O think you need to grok this key point deeply.
- joebaf 4y agoHere's the direct link to the blog post on the book: https://www.cppstories.com/2023/init-story-print/ https://www.cppstories.com/2023/init-story-print/ And the book at Leanpub: https://leanpub.com/cppinitbook https://leanpub.com/cppinitbook
- heeen2 4y agoThe mention of the number of pages seems passive aggressive. Here's what the book actually covers and it is "initialization and related areas" which you could fill many pages about any language if you include examples, a quiz, some foundational chapters: The book contains 14 chapters in the following structure: Chapters 1 to 5 create a foundation for the rest of the book. They cover basic initialization rules, constructors, destructors, and the basics of data members. Chapter 6 is a short quiz on constructors. You can check your knowledge from the first “part” of the book. Chapter 7 Type deduction: auto, decltype, AAA Chapter 8 describes Non-static Data Member Initialization (NSDMI), a powerful feature from C++11 that improves how we work with data members. At the end of the chapter, you can solve a few exercises. Chapter 9 discusses how to initialize container-like data members. Chapter 10 contains information about non-regular data members and how to handle them in a class. You’ll learn about const data members, unique_ptr as a data member, and references. Chapter 11 describes static non-local variables, static objects, various storage duration options, inline variables from C++17 and constinit from C++20. Chapter 12 moves to C++20 and describes Designated Initializers, a handy feature based on similar thing from the C language. Chapter 13 shows various techniques like passing strings into constructors, strong typing, CRTP class counter, Copy and swap idiom, and more. Chapter 14 is the final quiz with questions from the whole book. And there are two appendices: Appendix A - a handy guide about rules for compiler-generated special member functions. Appendix B - answers to quizzes and exercises.
- deleted 4y ago[deleted]
- jahnu 4y agoC++ is my daily language. Has been for my entire career since the mid 90s. About 10 years ago I gave up trying to understand it all and things have been fine. Good even. Even more so since I pushed warnings to max (where possible), tooling like clang-tidy, -format, and all the other static analysers, multiple compilers on multiple platforms, and extensive use of tests and so on. You know, general best practices. To the extent I've forgotten loads of things. So what I want to say is, it's not necessary at all to understand the language completely or even mostly in order to do good, high quality, productive work with it. Not even close. Maybe with the advent of AI tools like co-pilot I can even start to forget more ;)
- qwerty456127 4y agoReal low-level assembly language probably is easier to really understand and reason about than C++, isn't it? I used to code in C++ with Borland C++ Builder and it felt almost the same like doing WinForms with C# pracrtically but once you want to really understand the language and what's going on the deeper level C++ seems infinitely obscure.
- nuancebydefault 4y agoCode written in the standard of C++ of 20 years ago (pre-c++11) does not even remotely look anymore like today's code conforming c++17. (let alone 20 or 23). Understanding it only got harder over time.
- FpUser 4y agoStd lib level code for sure. Application level is easy to grasp if written by decent programmer.
- badpun 4y agoHowever, Application code is calling all these nightmarish library functions which you don’t understand and have to rely heavily on documentation and experimentation to use. It’s not like that at all in e.g. Java, where reading the standard library code is a pleasant and educating practice.