From 1985 to 2010, any decent run-of-the-mill-general-purpose coding standard worked pretty well for C and C++. But since C++11, every batch of new features also added more tools that were easy to misuse against the spirit if not the letter of said guidelines. Nowadays, the only way to maintain good code with modern C++ is using modern standards following Clean-Code / SOLID principles. I've found the most important thing is keeping classes and functions small: just one purpose is the key. The best way to find out if your function or class is small enough is thinking about a name that describes it well: if a good description requires an 'or' or 'and' or 'then', then your class or function tries to fulfil more than one purpose and should be split!

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

As Richard said, we need more information: - what is "the class parameter"? - what is "the documentation" you are referring to? - what is "the CDialog::Create"? - also: in what way does it "fail"? Is there a compiler, linker or run-time error, and what does it say? Or does you program not behave in the expected way - if so, how, and what did you expect? You are apparently referring to very specific things, but we have no idea what you're seeing or reading. (or whether that is relevant information to start with)

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

I would have to look up some translations to be precise, but it looks like your question is much more general than something about specific types of morphism: First of all, while Mathemtatics is mostly about the art to describe and solve problems separate from concrete examples, examples are still often used to illustrate corner cases, to disprove a false assumption, and occasionally even as a basis for a proof (see Mathematical induction[^]) As for morphisms, concrete examples can only help as counter examples, or to illustrate some behaviour. But morphisms can be very odd, and you can't really make a statement about them by looking just at examples - simply because you can never be sure whether you considered all relevant cases. What you have to do instead is analyze the facts you know about the morphisms in question, and, only based on these facts, consider the logical consequences. I'll give an example of a proof from a mathematical school contest I did 40 years ago. I still remember it because the statement to proof is so beautifully simple, and yet only a few 100 pupils in all of Germany were able to solve it correctly (i hope my translation skills don't let me down: Given is a bijective morphism of the euclidian plane, f : R^2 -> R^2 that projects any circle onto a circle. Prove that f will also project any straight line onto a straight line. A lot of pupils failed on this proof because of one mistake: they assumed that f would not only project circles on to circle, but also the center of the circle onto the center of the projected circle. However, the task does not give that information, and a proof based on that assumption is therefore wrong. The solution takes several steps: 1. consider the method: there are several method to do mathematical proofs, but the only one I could come up with that fits this task was Reductio ad absurdum - Wikipedia[^] : I will assume the opposite of the statement. Then I will disprove this assumption. 2. Carefully formulate your assumption: The opposite of the statement is that not all straight lines are projected onto straight lines, or that there is at least one case of a straight line that is not projected onto a st

If you're looking for work at Google or another international (and especially US-based) company, you should work on your grasp of the english language first.

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

honey the codewitch wrote:

I also don't want end users to have to install it to highlight my files.

I'm not sure I understand this part. Are you saying you have source files with non-standard extensions that your end users are looking at? If so, then maybe the cost or effort to install VA may not be worth it. However, VisualStudio also has the feature to interpret files with custom extensions as C++. Not sure where in the settings this is hiding. But it would at least enable the built-in highlighting capabilities.

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

You can tell VA to interpret files without extensions as C++ headers, or tell it to interpret files with custum extensions as code files. See Custom File Extensions[^]

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

Not sure if that's what you're looking for, and I don't know if it can be used with VS Code, but I'm very happy with the extended coloring and highlighting capabilities of Visual Assist - a Visual Studio extension by Whole Tomato Software[^] But admittedly the main use I get out of it is its outliner and VA View that gives me a host of information about any symbol I'm currently hovering over. You can find references to any symbol, and unlike Intellisense it will distinguish uses of that specific symbol from uses of a same name symbol from another context. Also the code macros and refactoring options are better than anything offered by Intellisense. There are a lot more useful features like renaming: renaming a member variable will show you every affected line as context and lets you disable those you don't want changed, and renaming a class within a file of the same name will offer to also change the file names accordingly, as well as adjust #include statements of renamed headers.

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

Interesting, but I have some doubts it is still relevant with modern compilers and CPUs. Even if it were, a simple lookup table would be faster for the purpose of finding the first estimation. This algortihm reminds me a bit of Bresenham's line algorithm - Wikipedia[^] : extremely clever, but once it was hard-wired in every graphcs chip there was little point knowing about it. Except maybe to apply such principles to similar problems in other areas. E. g. I tend to do calculations with 2D and 3D vectors a lot, and if I were to do these calculations straightforward, then yes, I'd need to do a lot of vector normalizations (i. e. calculations of 1/sqrt(x)). But in about 8-9 out of 10 cases I can avoid normalization alltogether by transforming the expressions. E. g. when I want to know whether a vector length is very small (effectively null), then I compare the squared length against the squared threshold value. Or when I calculate the intersection of a plane with a line, I determine the intersection without normalizing any vector. Instead I transform the equations in such a way that I end up with the squared length of the line direction vector, and the plane direction or normal vectors don't need to be normalized at all. I do agree that the explanations and specifically the animated number representations are formidable, though

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

I've used .Net to open and read from an excel file and also suffered some crashes until I made it work. The main problem was (AFAICT) that once you create an Excel instance, it becomes a sink for input events, and if any other thread in your application also eats Windows events, this can lead to conflicts. I solved these problems by opening the sheet, reading whatever I needed into a data structure, and immediately closing it again. I. e. not just closing the excel file, but also the excel application instance! Put all that into a try ... catch block and you're golden.

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

MFC was developed at a time when documentation was printed out and provided in the form of books. I still remember the thick stack from Visual C++ 3.0 (or maybe 3.1?): about a dozen books with a total of >5000 pages of text. Programmers at the time were required to find out what parts of these books they needed and then actually read it. Better yet: find third party books on specific topics such as MFC UI programming and read those instead, and only use the documentation for reference. Nowadays, programmers expect to use new APIs on the fly: spending more than an hour reading documentation is considered unacceptable, and an API requiring that considered obscure or outright bad. Microsoft doesn't obscure MFC documentation, they just never integrated all that additional information contained in those third party sources - quite possibly in part due to copyrights, but also because they instead focused on .NET as a replacement.

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

The problem isn't doxygen, the problem is people thinking that using such a tool creates useful documentation all by itself. If you can't come up with sensible comments at the right places, sensible function and variable names, and clean code, then no tool in the world will magically turn that code into well documented code!

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

Indeed. Good names and taking advantage of C++'s strong typing is good enough a documentation for 90% of all functions. I've often seen hard to read code that could be improved just by using appropriate names and the correct data types. int is overused - I've seen too many cases where bool or enums would be a much better fit, and increase readability too.

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

If you mean to replace std::cout and std::cin with stdio.h functions, then look up the usage of printf() and scanf(), e. g. at C Library - <stdio.h> - Tutorialspoint[^] If you mean to convert everything to C, you also may need to remove the const qualifiers depending on the exact C compiler (and version) you are using.

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

P.S.: here's a description of the function I mentioned: Change Signature[^]

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

I haven't tried many tools, but VisualAssist for Visual Studio offers a function to change the signature of a function. This will change the function not only in the header and cpp file, it will also rename (if needed) any function calls in the rest of the code, and if you add a function argument, it will insert ToDo comments to help you locate code you need to adapt. Not sure whether there's a version you can use with VSCode.

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

Quote:

CPP files are hateful. You have duplicate too much. Too many potentials for getting that wrong and it's annoying to have to flip back and forth between files if you forget a signature while making the CPP.

With the right tools none of these things ever become an issue. And the advantages of having clean and minimalistic headers easily outweighs the minimal overhead of maintaining additional files and maybe having to actually bind a library to your program rather than just header files. But as I said earlier, you can only start to really appreciate the benefits of cpp files once the projects get bigger, so I guess we'll never share the same view on this. Let's just leave it at that. :rose:

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

Quote:

why everyone doesn't just make C++ libs as pure HPP files is beyond me. The extra build complexity is not worth the little bit of extra code hiding you can get by using cpp files. With an HPP you just include the heckin thing.

There are a lot more reasons to not put implementations into header files than just hiding proprietary code: reducing dependencies, making code more readable and more maintainable, reducing build time. You may not be able to appreciate any of this as long as you work on your own and your projects are small. But I assure you that it's well worth the effort for any project with a lifetime of more than 1 year, even if you're the only one maintaining it. And most certainly for any team project. For example I currently work in plugin development, and our framework to help us create a plugin makes heavy use of templates, so it's header-only. However, these templates force the compiler to pull in pretty much the entire codebase as well as several large third party libraries such as boost, increasing the build time to more than a minute, whereas a simple plugin not using that framework can be built in a second. It's so bad that I'm currently looking into replacing that framework with a different approach that minimizes dependencies (and therefore build-time). The key concept will be moving all the code that depends on third party libraries into cpp files and putting those into a pre-built library. Building the plugin will then no longer require pulling in hundreds of headers from third party libraries!

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

I'm not suer about that, but in totally unrelated news, they say "Hello" on page twelve of the privacy agreement you need to sign before they agree to introduce themself.

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

The short answer is: I always picked my jobs based on what interests me most, not based on the pay checks. That keeps me motivated and open to new things: At 57 I started in my current position as a CAD plugin developer for a startup company(!).

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

A billion of zeroes, of course ;P

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)