Microsoft arrived in 2020

Microsoft Package Manager

As I had to move some projects to a new PC, I had to install point cloud library. So far there had been two methods

1) executable install package for VS2010

2) release download from GitHub for VS2015 and above

Now, there is a new method:

use vcpkg, the (new) package manager from Microsoft, which "automatically" installs pcl and all bindings.

Automatically means:

a) run the script

b) fix several rename actions, which cannot be done by the script

c) download several files by hand into downloads, so that vcpkg recognizes them (works for sqlite)

d) adapt the script

scripts/vcpkg_download_distfile.cmake

slightly to find the exact filename, that vcpkg expects (additionally need for proj4, pugixml, utfcpp, vtk)

set(downloaded_file_path ${DOWNLOADS}/${vcpkg_download_distfile_FILENAME})
message(">>>>>>>>" ${DOWNLOADS}/${vcpkg_download_distfile_FILENAME})
set(download_file_path_part "${DOWNLOADS}/temp/${vcpkg_download_distfile_FILENAME}")

the whole install procedure is extremely slow, e.g. VTK runs 31 minutes without download, the whole install took me about 2-3 hours.

make libraries available:

vcpkg integrate install

build with pointing to vcpkg bindings

cmake -DCMAKE_TOOLCHAIN_FILE=D:/GIT/vcpkg/scripts/buildsystems/vcpkg.cmake ..

Point cloud library

2do:
- vcpkg didn't install pcl_visualizer directory *), so I copied it from an older pcl 1.9.1 install
- add D:\GIT\vcpkg\installed\x86-windows\include\vtk-9.0 directory to include directories
- SmartPointer.h still doesn't compile

*) https://github.com/microsoft/vcpkg/issues/11601

... in the end this seems way to much effort, i.e. the pcl 1.9.1 libs are x64 whereas the vcpkg ones are x86. task still pending: https://github.com/PointCloudLibrary/pcl/pull/4096

Still way to go

... back again to vcpkg. As the package distribution of pcl didn't fully work yet, I downloaded the GitHub release for 1.9.1. Installing this was magnitudes faster than vcpkg installation. I understand that the future will be managed relations for libraries, at the moment it is still a hassle.

Building the project again, I had to disable vcpkg in building options, the project was rebuilt in a rush.

Reconsidering C++

Last week I worked on zweidee framework, https://github.com/kerm1t/zweidee. This morning I joined LD46, aiming to use zweidee to start off quickly. Upon an initial idea, I started creating a procedural level generator. However I faced some problem calculating a distance between two points. It took me a bit to track this down. It turned out, subtraction of unsigned int variables led to wrong results. So I started to think, what is the good of unsigned at all?

This happens on a lean, quick building project. At work C(++) projects are magnitudes more complex, compile / build times are long and nagging. Data structures are chunked up heavily. Implementing, as well as debugging is orders more tedious. Since some time it bothers me, to simplify. Why use unmaintainable build environments, overloaded frameworks and C/C++? Others are concerned, too: http://number-none.com/blow/, https://www.youtube.com/watch?v=GC-0tCy4P1U&feature=emb_logo

Recently I started a small project using javscript and THREE.js, which was a breeze to implement: https://jsfiddle.net/kerm1t/5Lg1hxfb/. So what are he alternatives to C++? Rust maybe, or Pascal / Delphi, https://www.nerdherrschaft.com/en/delphi-pascal-development.html. Also Swift seems to be evaluated by Google as to replace python. https://tryolabs.com/blog/2020/04/02/swift-googles-bet-on-differentiable-programming/

Unity uses C#, which I never tried, since it is supposed to be a bloated Microsoft Language. Especially being interwoven with .NET. But then it was designed by Anders Hejlsberg, the Turbo Pascal originator and Borland Delphi Architect. Hey, isn't just the idea of Unity to get results fast? Wouldn't then C# just the right language?

C/C++ remains the language for low level coding. On a PC basis, however is seems reasonable to move away from it, as it over complicates debugging. Coming back to unsigned int, why is this needed at all. Meanwhile I found, that Google advises not to use unsigned. s. https://google.github.io/styleguide/cppguide.html

"You should not use the unsigned integer types such as uint32_t, unless there is a valid reason such as representing a bit pattern rather than a number"

Unsigned Arithmetic is error prone. Taking first steps I will consider Googles take on unsigned variables. https://www.learncpp.com/cpp-tutorial/unsigned-integers-and-why-to-avoid-them/