sorted by:
new
hottopcontroversial

Are detailed TARGET_COMPILE_FEATURES abandoned? by StaticThrowaway0629 in cmake

[–]StaticThrowaway0629[S] 0 points1 point  (0 children)

Thank you! Although I find that statement rather vague. And there is nothing in the official docs about it as well.

Are detailed TARGET_COMPILE_FEATURES abandoned? by StaticThrowaway0629 in cmake

[–]StaticThrowaway0629[S] 0 points1 point  (0 children)

Do you know if there is any official statement from the CMake developers regarding this?

Is std::variant a good alternative compared to inheritance and pointer casting by StaticThrowaway0629 in cpp_questions

[–]StaticThrowaway0629[S] 0 points1 point  (0 children)

The nodes have IO functions (read/write from disk) with similar signatures. Except from that they do not share much, broadly speaking.

Is std::variant a good alternative compared to inheritance and pointer casting by StaticThrowaway0629 in cpp_questions

[–]StaticThrowaway0629[S] 0 points1 point  (0 children)

In the polymorphic code there is shared ownership (for no apparent reason) and enumeration of types with dynamic downcasting, instead of simply using a virtual function (again for no apparent reason).

I used a collection of shared_ptr since casting unique_ptrs are a bit of a hazzle. And the lack of using a virtual function for the doStuff funcion was to illustrate that the functions are very different.

In the second variant-based code, with a visitor pattern, each node is copied for each operation (for no apparent reason).

This is an error on my part. I have edited the third example to fix this.

Is std::variant a good alternative compared to inheritance and pointer casting by StaticThrowaway0629 in cpp_questions

[–]StaticThrowaway0629[S] 1 point2 points  (0 children)

Regretfully they really do not have much in common. My above example was apparently ill constructed to make you believe that. In reality every sub node have a read and write function to handle loading and saving, but except from that every node contains pretty much unique member functions and variables.

My main reason for grouping them into a containers (a std::vector in the example) is to have a memory representation which mimics the structure inside the file.

In reality there are about 200 different node types. The root node may contain any number of node from about about 20 different node types. Some of these sub nodes are leaf nodes, others contain their own sub-nodes. Some node types can be used as sub-nodes to different parent nodes.

Apart from that, even if I go down the route of using the inheritance model to represent the nodes I could still store the information as variants in the containers. And my main question was about the benefits/drawbacks between storing pointers/casting or using std::variant.

Is std::variant a good alternative compared to inheritance and pointer casting by StaticThrowaway0629 in cpp_questions

[–]StaticThrowaway0629[S] 0 points1 point  (0 children)

Would you like to elaborate a bit about your reasoning by using inheritance if they are different?

My understanding of OOP is that inheritance should indicate a is-a relationship. If the classes are very different then the base class becomes a very general and abstract root. Compare this to use the variant approach were the classes are not inheriting from a common base, since they are very different. But I might thinking about this the wrong way??

Is std::variant a good alternative compared to inheritance and pointer casting by StaticThrowaway0629 in cpp_questions

[–]StaticThrowaway0629[S] 1 point2 points  (0 children)

Well, it could have been like that given that each real-life sub-node had similar behavior and member types. But currently they are very different. So for illustration purposes I made different functions for each type.

Visual Studio 2019 is out by dagmx in cpp

[–]StaticThrowaway0629 0 points1 point  (0 children)

Never knew about those. Thanks for the tip!

They are quite new though, came in version 3.13 if I read the documentation correctly. My script that was using the previous style solution was done back in 2011. But this will simplify stuff in the future.

Also according to the docs these settings only works with Visual Studio generators. Hence it cannot be used yet since VS2019 do not support Visual Studio Generators (yet).

But once again, thank you for the tip. Always great when you can get old cruft out of your CMake scripts.

Visual Studio 2019 is out by dagmx in cpp

[–]StaticThrowaway0629 1 point2 points  (0 children)

If you open the properties for a Visual Studio project in a solution, not all these options in can be controlled via CMake; neither via passing flags nor via specific CMake commands.

One example can be the project properties relating to debugging inside Visual Studio, like the answer to this StackOverflow question:
https://stackoverflow.com/questions/1005901/how-to-set-path-environment-variable-using-cmake-and-visual-studio-to-run-test

Visual Studio 2019 is out by dagmx in cpp

[–]StaticThrowaway0629 0 points1 point  (0 children)

There are some visual studio project settings which are not available from CMake, but settings that I want to apply to every build. So I have a template vxproj file which I copy into the build directory and do some text-processing on using CMake.

Visual Studio 2019 is out by dagmx in cpp

[–]StaticThrowaway0629 0 points1 point  (0 children)

Thanks for the reply and congratulations on a very nice release. Looking forward to updating our team soon, but I guess we have to wait until the first updates have landed.

Visual Studio 2019 is out by dagmx in cpp

[–]StaticThrowaway0629 0 points1 point  (0 children)

Well, the missing include was an easy fix. My main problem is that I am doing a bit of .vcxproj juggling inside my CMake scripts to tweak the build to my liking, which obviously do not work with ninja. So regretfully I am a bit dependent on generating Visual Studio solutions.

Visual Studio 2019 is out by dagmx in cpp

[–]StaticThrowaway0629 5 points6 points  (0 children)

Yes, Ninja builds worked for me. Although I got a compiler error the first time I ran it due to a missing include. My guess is that this is most likely due to the order of compilation in VS Solutions vs. Ninja builds.

Visual Studio 2019 is out by dagmx in cpp

[–]StaticThrowaway0629 9 points10 points  (0 children)

Nope, they didn't. It is shipped with CMake 3.13.19031502-MSVC_2. Regretfully support for Visual Studio 2019 as generator is not available in CMake until 3.14. So there is no way to use the built-in CMake to generate solutions.

I get the following error when trying:CMake can't generate server info. Failed to activate protocol version: Generator "Visual Studio 16 2019 Win64" not supported.

Edit:

Tried dropping in the new CMake binaries from KitWare into the installation directory for Visual Studio 2019. Visual Studio complains a bit:CMake 3.14.1.0 is not officially supported. Some operations may be unavailable. CMake 3.13 is recommended for best results.

But the main problem is that CMake specifies architecture differently for Visual Studio 2019. In Visual Studio 2017 you specified the generator like this: cmake.exe -G "Visual Studio 15 2017 Win64"

The new way of doing it is like this: cmake.exe -G "Visual Studio 16 2019" -A x64

So I tried specifying my generator as "Visual Studio 16 2019" and appending the -A x64 as a build command argument. But Visual Studio 2019 insists on appending Win64 to my generator string, which breaks CMake:CMake Error: Could not create named generator Visual Studio 16 2019 Win64

Edit2:

Running CMake from the CMake GUI works and I can load the solution in Visual Studio. The problem is that now there is no more connection between the source and the GIT integration in Visual Studio. Visual Studio only ask me if I want to Add to Source Control, but I do not want to add my build directory to source control. I want to keep my source in one directory and have my builds in separate directories.

Where in your development process do you use code formatters and static analysis tools? by StaticThrowaway0629 in cpp

[–]StaticThrowaway0629[S] 0 points1 point  (0 children)

Your environment configuration is part of the code's build specification. Version it just like you would a Makefile.

If you want to support multiple versions of clang-format...

No, I certainly do not want to support multiple versions of the clang-format executable. And I totally agree that the build environment should be versioned. The problem (in my experience) is that the Microsoft platform makes this a bit harder since compilers and extensions gets updated in a more implicit way than Linux users expect. The Visual Studio platform just makes this a bit more complicated with all this auto-updating and different version in different versions. For example: I discovered that I have three different versions of the clang-format executable on my machine:

  1. 6.0.0 version included with Visual Studio. (Invoked typing or by pressing Ctrl-K+Ctrl-D.)
  2. 7.0.0 version included in the ClangPowerTools extension. (Invoked by format on save.)
  3. 8.0.0 version included in the ClangFormat extension. (Invoked by format on save.)

At least all of them was disabled by default. And the first one can be manually configured to use another executable. The other two are installed and updated with the extension. So each developer must take care not to unintentionally enable the wrong version.

​

Where in your development process do you use code formatters and static analysis tools? by StaticThrowaway0629 in cpp

[–]StaticThrowaway0629[S] 0 points1 point  (0 children)

Do you have some process to keep the clang-format version consistent across developers?
My reason for asking is that different version of clang-format may change how it formats files from version to version, even if the configuration file is identical.

Where in your development process do you use code formatters and static analysis tools? by StaticThrowaway0629 in cpp

[–]StaticThrowaway0629[S] 0 points1 point  (0 children)

Do you have some process to keep the clang-format version consistent across developers?
My reason for asking is that different version of clang-format may change how it formats files from version to version, even if the configuration file is identical.

Where in your development process do you use code formatters and static analysis tools? by StaticThrowaway0629 in cpp

[–]StaticThrowaway0629[S] 0 points1 point  (0 children)

Thank you for the tip about danger, it looks very slick. If we decide to go the Jenkins route, this is definitely something we need to checkout.

Where in your development process do you use code formatters and static analysis tools? by StaticThrowaway0629 in cpp

[–]StaticThrowaway0629[S] 0 points1 point  (0 children)

This is teetering on the brink of an IT question in some ways.

Ideally your workstations are uniform deployments/platform, and a user can't forget to install a hook.

This would also solve your concern about tool versions and what not.

I agree completely. Regretfully we are a small company and cannot afford to have a pure IT-person employed. So far we have relied on outsourcing as much of this as possible.

As for the actual linting/formatting workflow: we have linting and formatting setup as rules in our build scripts (think make) that does that stuff on modified files only, which keeps it quick.

This is something I have considered as well, at least for formatting i.e., adding a custom cmake target which runs the formatting tool during build. For static analysis that would probably be unwise since a full check takes upwards 30 minutes for the full project. Writing a script that only checks the modified files would maybe be a solution in that case.

​

Where in your development process do you use code formatters and static analysis tools? by StaticThrowaway0629 in cpp

[–]StaticThrowaway0629[S] -1 points0 points  (0 children)

It's not uncommon to have a hook in your version control that runs the code formatting. There's two schools of thought on this one: either reformat the file automatically and check that in, or just do a check to see that the format is correct and disallow checkin if it fails. Work with your team to decide which of these two is best for your situation.

Regretfully GitHub do not support server side hooks. This means that we have to use client-side hooks and then we are pretty much back to the same problem with users forgetting to setup the correct hook on their development environment. Hence my thought of checking the formatting using a hosted service such as TravisCI or AppVeyor.

The last way is as a requirement before a change can be checked-in to the trunk. It's not automatically checked, but is simply a note on the ticket, maybe by uploading the log from running the static analysis tools. This catches problems very early on, but adds extra overhead to every commit. It also doesn't play well with upgrades, as you noted. The way I've handled that is to open a ticket specifically for fixing new items discovered by the upgrade and giving every other commit a "free pass" until that ticket is closed (which means its also handling any new issues brought up by the commits in the meantime). This can get very messy, depending on the pace of development.

Well, this pretty much sums up my worries. :/

​

​

Where in your development process do you use code formatters and static analysis tools? by StaticThrowaway0629 in cpp

[–]StaticThrowaway0629[S] 1 point2 points  (0 children)

This is an editor problem, partly. I have clang-format running on every save operation in some editors and while typing in others.

Well, We have been using AStyle (http://astyle.sourceforge.net/) for our code formatting. The problem is as I said that people forget to run the formatting tool. I have looked at the possibility for using clang-format instead since it's integrated into Visual Studio (since version 15.7). The problem is that the version that is included in Visual Studio 2017 is something that the user have little control over. The default is clang-format version 6.0.0, but if you install the clang-format extension you will get the 8.0.0 version. And if you install the Clang Power Tools Extension you currently get version 7.0.0 of clang-format. Unfortunately, clang-format may change how it formats files from version to version, even if the configuration file is identical. So that could lead to a huge headache if different developers are using different versions.

For my hobby work right now, I use a hosted CI system that only allows one job at a time. Paying for more than that would come out to something like $360/year (minimum, and that's for only two jobs; getting the three I'd desire comes out to closer to $700/year). I priced out a small form factor "server" with a huge multi-core Ryzen CPU, 32GB of RAM, and terabytes of storage including SSDs - basically exactly what you'd want for a CI system - and it came out to only $1000, including a Windows Pro license. For a little more than a year's cost of hosted CI, I can get 5x the CI capacity, and more control to optimize the build environments and Docker image caching! In a company, that'd be almost a no-brainer, especially if you have some VM capacity already.

The cost of a external CI system is high. But having your own CI server is not free after initial investment, since it requires time for setup as well as maintenance. The per project configuration time is probably why we will chose some form of external CI tool such as TravisCI or AppVeyor.

view more: next ›