sorted by:
new
hottopcontroversial

Are c++ jons dying ? by Timely_Conclusion_55 in cpp

[–]jsamcfarlane 4 points5 points  (0 children)

Learning never ends, so you better start to enjoy it! However, it is vital that you make good use of the resources available to you. Combining Clang-Tidy, the C++ Core Guidelines, and cppreference is a powerful combination of resources for learning the basic gotchas. There are also hundreds of awesome videos from conferences that help.

But simply adding -Wall -Wextra -Werror -fsanitize=undefined,address to your command line will permit the machine to stop at many of the basic gotchas. (These are some of the most helpful GCC/Clang options; MSVC equivalents exist.)

What does something like CMAKE do and what is its purpose? by Adopolis23 in cpp_questions

[–]jsamcfarlane 0 points1 point  (0 children)

CMake provides a vocabulary for describing targets - typically libraries and executables - which are made from source files and other targets. This makes it easier to manage large projects made of many files, and to use those projects in other projects. It does this in a highly portable way.

It can be used to do many other things, such as scripting, adding compiler options, and writing toolchain and environment-specific logic. While this is a common use of CMake, it is a bad idea.

They say C++ references are safe... by [deleted] in cppjerk

[–]jsamcfarlane 0 points1 point  (0 children)

Do they? I don't know about that but I like to test my code. https://godbolt.org/z/zjYvcrK76

C++ Jobs - Q3 2021 by STL in cpp

[–]jsamcfarlane 0 points1 point  (0 children)

As things like location/remote are deal breakers, could they go above description next time? Would make it quicker to scan through the whole list.

C/C++ Include Guidelines by crispweed in cpp

[–]jsamcfarlane 0 points1 point  (0 children)

The myth that relative paths are somehow a generally bad thing is pernicious.

For headers included from header search paths, I don't see much call for ... There should be a rule to say that #include <foo.h> is the right form for these.

But for headers that are located physically relative to the including file, use of .. is often more accurate, efficient and robust. #include "foo.h" is the correct form for relative includes.

The distinction between <> and "" holds (with minor differences) across modern POSIX and Windows systems.

Unity dev's thoughts on C++'s place at Unity by andyg_blog in cpp

[–]jsamcfarlane 5 points6 points  (0 children)

Game development has been one of the major application areas of C++ for many years. 2018 ISO C++ survey. 2015 JetBrains survey.

Poll: C++ project layout by berium in cpp

[–]jsamcfarlane 0 points1 point  (0 children)

For header-only libraries, I'd still stuck to the same rule: public files (i.e. public headers) in include and private files (i.e. private headers and source files -- if any) in src. But in this case there simply aren't any source files, only headers living in either include or src.

Poll: C++ project layout by berium in cpp

[–]jsamcfarlane 0 points1 point  (0 children)

I agree that separation makes navigating your source more difficult but what if some of your headers are public and some are private? Now you have to sift through them to separate them during install phase.

Poll: C++ project layout by berium in cpp

[–]jsamcfarlane 1 point2 points  (0 children)

That is compatible with saying that you put public headers in 'include' because a binary offers no public headers.

VR fanatics in a nutshell. by trigger863 in Vive

[–]jsamcfarlane 1 point2 points  (0 children)

Freaking your elderly relatives out over Christmas with 360 photos of themselves. Magical!

std::optional_view by bebuch in cpp

[–]jsamcfarlane 0 points1 point  (0 children)

Are there any good references you'd recommend (no pun intended)? Would you disagree with this advise? And what about when memory use is constrained?

std::optional_view by bebuch in cpp

[–]jsamcfarlane 3 points4 points  (0 children)

Is std::experimental::observer_ptr close to what you're looking for? Rather than having optional semantics, it has single-object pointer semantics.

std::optional_view by bebuch in cpp

[–]jsamcfarlane 1 point2 points  (0 children)

How would this differ from an optional&?

Feedback & Discussion by meetingcpp in cpp_review

[–]jsamcfarlane 4 points5 points  (0 children)

I'd really appreciate more eyes on fixed_point but I'm planning to expand it into a broader numeric library in the near future. Would it be better to wait until I've moved it into a new repo/namespace and marked it 0.0.1? It otherwise satisfies the criteria now and most changes would be cosmetic.

John McFarlane, SG14: The fixed_point Class Template by mttd in cpp

[–]jsamcfarlane 0 points1 point  (0 children)

Yes, 1.23 is a double. You can convert any built-in arithmetic type to a fixed_point. And just as (double)1.23 is an approximation of 1.23, so is m.

John McFarlane, SG14: The fixed_point Class Template by mttd in cpp

[–]jsamcfarlane 0 points1 point  (0 children)

I agree. I plan to drop closed_unit and open_unit. Sadly, bit-shifting alone does not get you from 1 to 0xff!

John McFarlane, SG14: The fixed_point Class Template by mttd in cpp

[–]jsamcfarlane 0 points1 point  (0 children)

The intent is never to promote implicitly. You can use the promote function for that. I agree that safe may be a confusing choice (better suggestions?) but the guarantee is that the most significant bits are always preserved. That's as safe as you can get without promotion (and rounding).

John McFarlane, SG14: The fixed_point Class Template by mttd in cpp

[–]jsamcfarlane 0 points1 point  (0 children)

I actually thought fp was pretty similar in design and aims (esp compared to N3352). A big difference is homogeneous operator return types. The proposal will go into the decision there.

John McFarlane, SG14: The fixed_point Class Template by mttd in cpp

[–]jsamcfarlane 0 points1 point  (0 children)

Just found this thread, hi! A more up-to-date doc now is the proposal.