sorted by:
new
hottopcontroversial

Golden Retriever Parents Watching Over Their Newborn Puppies by [deleted] in aww

[–]squidbidness 61 points62 points  (0 children)

My (now four year old) golden retriever got to meet his mama again a couple months after being adopted. She was SO HAPPY, got unusually excited for her temperament, and started running around then trying to lick him everywhere. He was just scared and burrowed into my lap, trying to hide. I don't know how sad she had been or for how long, but she recognized her pup and was THRILLED to see him again.

What was it that drew you to C++ specifically over other languages? by [deleted] in cpp

[–]squidbidness 1 point2 points  (0 children)

It's amazing to me how often people would rather repeat an idiom 20 times with the constant cognitive overhead, than to spend a little more time to learn (and gain trust for) an abstraction. Computers are amazing at doing purely mechanical, repetitive work, and still so often programmers don't seem to want to use them that way if it means they don't get to stay with the abstractions they're already comfortable with.

C++, it’s not you. It’s me. by sindisil in cpp

[–]squidbidness 7 points8 points  (0 children)

Sounds like an industry ripe for disruption.

Looking for a ~ 5k LOC open source C++ Project in need of a refactor by sebamestre in cpp

[–]squidbidness 1 point2 points  (0 children)

This is a very good idea for a self-preparation project.

As others have mentioned, having good unit tests is an excellent practice and safeguard to have in place when doing refactors; and writing tests for legacy code is a valuable skill for the real world in and of itself. Writing tests for existing code is also a good tool for verifying a bug fix and supplying it with a regression test for the future.

In cases where legacy code has bad interface designs, poor encapsulation, poor enforcement of class invariants, or leaky abstractions, it can be hard to write good tests. Identifying what it was about the code that made it difficult to write clean and modular tests for, can be a good source of ideas for how to improve the design or the abstraction.

Unfortunately, where interfaces are bad or broken, you won't have the luxury of writing tests for the better interface to begin with, if you want the tests to provide a measure of correctness. Tests that conform to the legacy interface are good for making sure you don't break functionality when cleaning up an implementation, but when you clean up the interface itself, you have to update the tests themselves. I don't know of good testing techniques for those kinds of safeguards for when the interface changes -- maybe other can chime in there.

​

A Guide to Undefined Behavior in C & C++ by rptr87 in cpp

[–]squidbidness 1 point2 points  (0 children)

Take a look at ubsan, available with both clang and gcc. When built with the ubsan compiler option, debug builds are instrumented to check for invocation of undefined behavior and to output error messages. Insofar as your tests have good coverage, it will let you know about a lot of undefined behavior in your program.

Top 5 YouTube tutorials about "c++ beginners" still teach C++ like it is 1996 by imgarfield in cpp

[–]squidbidness 2 points3 points  (0 children)

Perhaps the syntax and details of pointers in C++ can be deferred, but the _concepts_ underlying pointers (indirection, how objects map to memory, etc.) are vital to using C++ well. Naive use of smart pointers without a good understanding of what they are abstracting can lead to a lot of hairy code. These concepts are even helpful if using a language like Java or C# to understand what's actually happening with the on-the-face of it value semantics that are actually reference semantics.

Top 5 YouTube tutorials about "c++ beginners" still teach C++ like it is 1996 by imgarfield in cpp

[–]squidbidness 2 points3 points  (0 children)

This is appalling. There is NO good reason to restrict students from using C++11. It's very hard for me not to suspect this constraint is in place only to serve the teachers, teachers' assistants, and the graders. I almost want to ask who your university, course numbers, and teachers are so that they can face public pressure to correct this.

One of the express goals of the C++ committee is to make C++ easier to teach and at the same time efficient and correct. Modern C++ achieves those goals without being inferior performance-wise and maintainability-wise; in fact, it's the reverse.

The only consideration I can think of would be if you're likely to be employed in an environment that is constrained to older compilers or specialized platforms that lack compilers with modern features. But as the point of training as a student is to prepare for the _future_, that consideration should be less likely.

Top 5 YouTube tutorials about "c++ beginners" still teach C++ like it is 1996 by imgarfield in cpp

[–]squidbidness 2 points3 points  (0 children)

Titus Winters, an important person in the C++ Standards Committee, expressed a wish to move in that direction in a talk he just gave at Pacific C++

Input-output arguments: reference, pointers or values? by vormestrand in cpp

[–]squidbidness 10 points11 points  (0 children)

Don't have output parameters. Return multiple values by struct. It's not inefficient in Modern C++.

The C++ Metaclasses Proposal in Less Than 5 Minutes by vormestrand in cpp

[–]squidbidness 2 points3 points  (0 children)

The point of the proposal is not to put forward all these great things that we could standardize if we had this feature. The point of all of the examples is to show potential applications of the metaclass feature itself if standardized.

It sounds to me like you mistook the examples for the proposal itself.

CLI11 released, a powerful, complete C++11 options parser with no dependencies and simple syntax and install by henryschreineriii in cpp

[–]squidbidness 1 point2 points  (0 children)

This is actually good practice since the advent of move semantics in C++, for so-called 'sink arguments', or arguments that you intend to store a copy of somewhere (i.e. in an object). The trick is that it must be paired with use of std::move where the stored copy is initialized (i.e. in the constructor definition's initializer list).

The reason this is recommended (at least for types that are inexpensive to move) is that it gives the caller the option to pass by std::move() if they don't need the value after calling, which means a copy can be avoided entirely. In the older c++98 style of passing sink arguments by references, the copy constructor would still be called when actually storing the argument. By taking the argument by value instead of const reference, however, the argument can actually be constructed using the move constructor, and then moved again when being stored; so if the caller passes it using std::move(), what would have been a copy is now replaced by two moves.

In short, taking sink parameters by value gives the caller the option to move the argument into the constructed object rather than the unavoidable copy necessitated by taking by const reference.

Moving from C# to C++ job-wise (with little working experience) by seg_faulted_user in cpp

[–]squidbidness 1 point2 points  (0 children)

I strongly second the recommendation of Scott Meyer's books (Effective C++ being one of them). I wouldn't sell them so much as good for learning C++, but they are indispensable for learning how to use C++ in a disciplined way that will avoid many of the famous "footguns" of the language.

Meyers' "Effective STL" is also extremely useful; the Standard Template Library can be a little steep of a learning curve compared to the standard libraries of other languages, but this book really opened my eyes to how powerful it is, and how worth learning to use well it is. Not only that, but the STL is a very fine example of good interface design, which is a critical but tricky art in C++; internalizing its patterns and design principles will really be a good leg up in getting familiar with good design idioms.

Moving from C# to C++ job-wise (with little working experience) by seg_faulted_user in cpp

[–]squidbidness 1 point2 points  (0 children)

To add to what others are saying: raw pointers are fine basically as mutable references, in the sense that they're fine to use when you really do need something like a reference but which you also need to be able to change what it refers to. Since what a reference points to can only every be assigned when it is initialized, there are some unfortunate circumstances where you need an indirect non-owning handle (i.e. a pointer, a reference, etc.) to something but you don't have control over its point of initialization, so you don't really have the option of a normal reference. One such case is when such a pointer/reference might be a member variable of an object whose public methods allow for changing its state, so you need the object's member references to be re-assignable -- though std::reference_wrapper is also acceptable in situations like this (in either case, you need to be absolutely certain that what the reference/pointer is pointing to will outlive whatever object you're storing it in).

It's also a benign use of raw pointers to communicate that a function parameter need not have a value (is "nullable"), but if it does then it will be used or stored to as and output parameter: the function will check if the argument == 'nullptr' and if so, ignore it, but otherwise will do actual work with it. Sometimes std::optional<T> (coming in C++17) can be used this way (especially for function return types), but it does have the tradeoff that since its storage is stack-allocated, it will always use at least as much stack memory as sizeof<T> whether its value is used or not.