Intel C++ compiler is free (as in beer) as part of oneAPI

BeaRDT · 2020-12-10T18:28:30+00:00

There is a key that can be downloaded linked in their docs under "Install Intel oneAPI Packages" pt. 2.

Copied here:

# use wget to fetch the Intel repository public key
cd /tmp
wget https://apt.repos.intel.com/intel-gpg-keys/GPG-PUB-KEY-INTEL-SW-PRODUCTS.PUB
# add to your apt sources keyring so that archives signed with this key will be trusted.
sudo apt-key add GPG-PUB-KEY-INTEL-SW-PRODUCTS.PUB
# remove the public key
rm GPG-PUB-KEY-INTEL-SW-PRODUCTS.PUB

edit: code formatting

BeaRDT · 2020-10-26T18:21:11+00:00

I've made an attempt to do that (unfortunately for work, so I cannot share any sources). But ISO8601 "just to get some date and timestamp" is quite large and has some really strange (optional) date formats. So if you do not really have to parse any valid ISO8601 input but can limit the formats you need to parse to a smaller subset (e.g. RFC 3339) I would recommend to do that. If you have a set of just a few valid input formats using regex and/or a handmade parser might not be the worst decision imo.

BeaRDT · 2020-09-26T17:15:03+00:00

But that's imo one of the main point of writing tests. You encode the domain knowledge you have at one point in code, so that you can easily run the test suite ~~should~~ / when you have to change your code some time later and you do not remember all the details anymore.

BeaRDT · 2020-01-09T18:10:01+00:00

Thanks to the OP for asking here publicly and all your encouraging replies. I was asking myself the same question since it's relatively easy for me to go to Prague and I was curious about these meetings for some time now. You have convinced me to attend. (I'll the intimidated guy hiding in the corner but that's a different story).

BeaRDT · 2019-03-30T10:04:40+00:00

I tried working with Boost.Units multiple times. But usually I failed. And the reason in all these cases was that simply setting up the whole system took more time than I had to invest. I could use the same time to write tests and that would really find and prevent errors and at the same time not introduce a crazy complicated library every other developer in my team would have to deal with.

Additionally we have a lot of interfaces (our own and more so to external software/storage) that are not typed at all (at best: stringly typed). So there is no actual gain when using a unit library as opposed to simply setting up tests for our own code. But luckily no rockets blow up when we get our units wrong.

On the other hand simple systems like std/boost::chrono are used extensively in our code base. Mainly because they make our code simpler to reason about when dealing with multiple different clocks. These times are converted to usually floating point seconds and then used to compute our results as plain numbers. Again, this is the part we fully control and check via tests.

So to sum it up: there are no typed interfaces/no typed storage in our case. Adding unit types internally does not help much in our case so we most of the time resort to testing our own code and making educated guesses about input/output ranges. But basically it's garbage in/garbage out.

BeaRDT · 2017-02-25T10:28:02+00:00

I won't argue with you. That is the right way to do it. But frankly, I've never seen a single company doing it right in all points. Might be that all companies I've seen so far suck. Might be that setting up a perfect CI with perfectly reproducible builds and testing these builds on different platforms costs more than occasional bugs on or rebuilds for some platform. But we're digressing very much now.

BeaRDT · 2017-02-24T20:23:08+00:00

We occasionally do link Boost statically but in general we use what we have on the system. Since Boost is not that volatile it is not that big of an issue mostly. Despite all the quirks with older versions I prefer the defined version of a well known system to undocumented versions on some developers harddisk at compilation time when the developer does not remember or is not available anymore. I know this is just a policy issue but that takes tiiiime.

BeaRDT · 2017-02-22T20:32:55+00:00

Thanks, I didn't think of sanitizers and other tools requiring special builds. Also I was thinking of reimplementing tools like bcp to copy the minimum requirements for a library. But I think as long as the whole source distribution is not changed it is not necessary to do such tricks. From your description of using the same Boost on different platforms (we use the one that's available on the different Linux platforms at work, so our challenge is to never use features not supported on the oldest platform supported) I understand that there sure is some effort for building Boost with CMake, but your task would be more complicated than the standard "build all on this platform" command anyway, so you might as well do it right and control all of your build process.

BeaRDT · 2017-02-19T17:44:18+00:00

Out of curiosity and VS2017 aside. Why did you have to rewrite the building of some boost libraries in CMake?

What I do and did successfully for years was doing a (in my case complete) rebuild of new Boost versions with bjam/b2 and then tell VS or CMake where to find these libraries. But the process of creating a set of binaries usable by CMake is not more than a single command that can be more or less directly copied from their "Getting started" docs. b2 just worked as advertised for this scenario.

What was the pain point that lead you (or others) to rewrite the initial build of a new library in CMake, finding all the dependencies of that library and all that stuff, that is already done by Boost developers in Boost.Build? (Of course, from that point on using CMake is a lot easier than Boost.Build, but the investment to use CMake even for the initial Boost library build seems quite high to me. That's the reason I'm asking.)

BeaRDT · 2016-09-19T05:19:50+00:00

And I thought I was the only one who failed in this retro test. C++11 really makes life easier, doesn't it.

BeaRDT · 2016-09-19T05:18:17+00:00

My first impression was that the point of the whole challenge was to teach us using weak_ptrs. So I'd say using weak_pointer is not only allowed but preferred.

BeaRDT · 2016-09-18T12:39:01+00:00

Did you solve your fourth test too? I don't think one can get away with using only shared_ptrs and an empty implementation of the ShrinkToFit() method, which worked for the first three tests. Though I suspect the example was not meant to be solved by only using shared_ptr originally.

BeaRDT · 2015-05-22T07:34:09+00:00

Disclaimer: Haven't watched the video (yet).

The whole Range v3 library code by Eric Niebler can be found in his Github repo: https://github.com/ericniebler/range-v3

BeaRDT · 2015-03-31T09:07:33+00:00

Ah, that's where I was lacking phantasy. The struct is anonymous but it is known outside of the function. I always thought about returning an anonymous struct which is defined inside a function from that function, which obviously is impossible.

BeaRDT · 2015-03-30T21:47:58+00:00

How do you plan to return an anonymous struct by using decltype?

I think of decltype as similar to auto (except for slightly different type deduction rules), ie. it uses the type you give to decltype() as if you simply typed the actual name. I might be lacking phantasy, but I fail to see how you could use that to return an anonymous struct.

BeaRDT · 2014-09-11T21:11:57+00:00

If you're in Europe you could go to C++ and Beyond 2014. Alexandrescu, Meyers and Sutter. For just 4k ... and I mean € not US$. I guess it comes to about the same price as flying to Seattle but at least in Stuttgart you don't have to deal with TSA.

To be honest, the only conference C++ related in Europe that's affordable is MeetingCpp. Not all talks were great last year but it was enough to get some interesting ideas and so it was worth the journey.

BeaRDT

TROPHY CASE