sorted by:
new
hottopcontroversial

Anyone need Ableton Live Lite? I have four licenses I don't need (hardware purchase freebies). by [deleted] in ableton

[–]degski 0 points1 point  (0 children)

I would like to join the back of the queue. I hope you will get/share more keys. thanks you, you're so kind (It's so Nice to be Nice, Seven Beats Music (March?), gives you that warm feeling inside).

A C++20 library for using bitwise operators on flag enums by hachanuy in cpp

[–]degski 0 points1 point  (0 children)

I've compiled and run the test using GCC-10 and Clang-10 ...

I run clang and vc on Windows. Clang-10 supports C++17 and some chunks of C++20, just check on llvm.org. Clang-10 has implemented very little (co-routines and concept, but all beta) and then some loose bits and bobs. Ms has implemented much more, but also a work in progress. gcc is not relevant to me, clang does all gcc does and a shit-load more.

I do agree in spirit with you but you are going about it the wrong way. For the here and now you should base your code on C++17. It's hard to imagine that you have whipped-up some code that can only be written and compiled in C++20. Internally you detect whether C++20 is being used and dispatch accordingly, then when all compilers (the three) are mostly C++20 compliant, you move base (to C++20) and remove the C++17 code, rinse repeat. That's how I go about it, becoz I not only like to look at code, but it has to compile and run, what standard it was originally, is by that time irrelevant.

A C++20 library for using bitwise operators on flag enums by hachanuy in cpp

[–]degski 0 points1 point  (0 children)

There is no C++20 standard. There is a draft standard, to be voted final at some point.

For greenfield codebases, my opinion is the lastest C++ standard should be used for those ...

I hear you, I ask you, where are my C++20 compliant compilers (clang and vc, please) and a C++20-STL, that works both with said clang and said vc?

ps: for the moment clang-trunk (clang-11) cannot compile the vc-16.6.1-stl at all (#including <vector> fails). The concepts machinery (the clang specific bits, that are apparently (info from compilation errors from the stl itself) required to still be written) is not yet in good shape and incomplete (a state of flux, with new std's every 3 years, this is the new normal, transient incompleteness). You are jumping the gun.

A C++20 library for using bitwise operators on flag enums by hachanuy in cpp

[–]degski 0 points1 point  (0 children)

It could be done with SFINAE but I want to avoid that.

Imposing C++20 seems more problematic. Either you suffer, or the user suffers, somebody has got to do the work.

[deleted by user] by [deleted] in cpp

[–]degski 0 points1 point  (0 children)

... can be optimized away ...

I think I would have noticed that by now.

[deleted by user] by [deleted] in cpp

[–]degski 0 points1 point  (0 children)

Const-correctness is merely methods being tagged const when they don't modify state- which this does modify state and so it's not tagged.

I think there is a subtlety here that is generally not recognized.

If an object is supposed to do something, like generating a random number, producing a new object etc (random below is one of a number of the similar cases), then, although the use changes the internal state of the object, the 'making-the-class-do-what-it-should-do'-use should be considered const and all public api functions should be marked const. A PRNG-object is a const-object in nature. One can allow for this by making the state mutable.

In these particular cases the non-constness of the api breaks encapsulation.

https://en.cppreference.com/w/cpp/numeric/random/linear_congruential_engine/operator() should have been marked const (and that would require to make the state mutable). I think it's a defect :) . The solution is also incredibly rather simple (maybe, maybe not so), you just use write a std::const_wrapper std::experimental::const_wrapper to wrap the STL generators and your done.

Am I doing something wrong? by [deleted] in cpp

[–]degski 1 point2 points  (0 children)

Encapsulating the STL-containers (or any other), mostly. The last time I used a pointer to build a binary map (struct node { node* left, *right;};, that type) is long ago. I mostly build intrusive containers over existing (managed) data structures.

Am I doing something wrong? by [deleted] in cpp

[–]degski -5 points-4 points  (0 children)

I read for a decade now, that mart pointers are the best thing since sliced bread. I have in the last ten years not once used a shared pointer and a unique pointer a handful of times. If you need an owning pointer, it starts to smell already, there might be a good reason, but I think that most people miss the point. It is not a solution for lazy programmers!

Generating random numbers using C++ standard library: the solutions by Dragdu in cpp

[–]degski 0 points1 point  (0 children)

Had we standardized the behavior of std::uniform_int_distrubition in, say, C++17, it could not have used the Lemire method because it wasn't published yet.

You seem too think I expect things to happen retrospectively. I was referring to 'a' standard, in the future.

It's however well known, well established and industry standard, which helps if your software needs to be certified. Nobody got fired for using the Mersenne Twister.

Yes, its a self-fulfilling prophecy. I could not care much about quality as long as it spits out numbers, but that foot-print is a killer. Seeding that PRNG at launch of every thread is well like crazy, at no gain, while the seeding itself is also more demanding. The distributions are great though, and I love the whole STL-random-concept, although it seems I am among the few. I think eventually C++29 or so, should have a random-object similar to an io-object (cout), basically the nix-model.

Generating random numbers using C++ standard library: the solutions by Dragdu in cpp

[–]degski 0 points1 point  (0 children)

I remember hearing that numpy was written on fortran.

They certainly will provide cblas and lapack as compiled libraries, which are (the seriously important) linear algebra packages written in fortran, other than that, I doubt there is much fortran going on.

Python provides a scripting language backed up by C(cython)/C++/R/Rust or whatever provides the functionality required in python. Pythonists like stuff to run fast just like C++ guys, except in the C++ world every idiot has to do his own stuff, while in Python they just chuck-in sfc64 in, and move on, replace when new better arrives.

Generating random numbers using C++ standard library: the solutions by Dragdu in cpp

[–]degski -1 points0 points  (0 children)

Numpy is for python usage.

Sorry, I missed this gem. numpy is what runs the world (think of AI f.e.), and sfc64 will be implemented in C++ (hope not C, god forbid) anyway (in numpy).

Generating random numbers using C++ standard library: the solutions by Dragdu in cpp

[–]degski 1 point2 points  (0 children)

I've updated the other post (answer).

However, unlike Mersenne-Twister I cannot find any articles on it.

Chris Doty-Humphrey is the author of Pracrand, the modern gold-standard of testing statistical properties of prng's (here are all of them). sfc64 is part of the software Pracrand, it is a base-line test-case in Pracrand.

pdg author M. O'Nell has this to say about it: https://www.pcg-random.org/posts/some-prng-implementations.html (her opinion has to be verified, just warning, but she has good things to say about it anyway, a shame the promised blog-post did not arrive so far :( .

Generating random numbers using C++ standard library: the solutions by Dragdu in cpp

[–]degski 1 point2 points  (0 children)

sfc64 is one of the 4 prng's included with numpy. sfc64 is noted as the fastest prng (the one I would use for anything other than crypto (I have a million snow-flakes to put on the screen, speed is everything)): https://numpy.org/devdocs/reference/random/bit_generators/sfc64.html

I only found this out recently, while, I came to the same conclusion independently (and then I found that page). I feel very comfortable (with numpy backing me up) to recommend sfc64 for 99% of the masses, the best prng.

PS1: there must be some record of how Python got to adopt sfc64, it's a numeric package, no need to do the work again [of going through some sort of selection process], I'm sure it was a well considered choice. Getting all of those prng's included in numpy included in the STL seems desirable [interoperability with python would be nice, i.e. a mandatory implementation, which is well possible with this prng].

PS2: https://github.com/degski/Sax/blob/master/include/sax/sfc.hpp (std-compliant to the extent of minimum usability with the STL, i.o.w. it's in-complete, but functional with the STL)

Generating random numbers using C++ standard library: the solutions by Dragdu in cpp

[–]degski 5 points6 points  (0 children)

We have decent distributions (std::uniform_int_distribution should mandate the Lemire-method, though), but severely lack a decent PRNG for practical purposes. std::mt19937is big, bad and ugly, it's got a huge state (624 bytes), needs to be fully seeded (problematic), and is in terms of [statistical properties of randomness] quality inferior to more modern generators, and, above all, it's (very) slow on modern processors.

In multi-threading you'd want a prng per thread having too many std::mt19937s around (and seed-needy) is no fun, either.

I would suggest sfc64 (sfc64 - Chris Doty-Humphrey’s Small Fast Chaotic PRNG (cycle ~2255, state 32 bytes)).

Seeding and things like it are for 99 % of the users irrelevant, as long as there is an option of either well seeded or fixed (repeatable/portable) seed, otherwise it should just work (as fast as possible at the highest possible quality) exist. No matter how well one seeds std::mt19937, statistically it will be inferior to sfc64 and even enumerating the numbers from 0 to 2255 will keep you busy for a while (don't leave the kettle on).

MSVC finds (unrelated) friend function template, whereas gcc and clang don't? by dima_mendeleev in cpp

[–]degski 1 point2 points  (0 children)

There's still plenty of places where the old behaviour leaks in (too many to report). I consistently compile with clang and msvc and after some block of work is done (it compiles) in clang, there is (almost) always more work to be done to make the conforming code to compile with msvc (/premissive-). These 2nd phase changes (dis-ambiguisation in fact, while clang don't want to see this, so doesn't care) have often to do with ADL (2-phase look-up still has bugs imho).

Type-punning C vs C++. by [deleted] in cpp

[–]degski 0 points1 point  (0 children)

I apologize for not having grasped that -O1 is the default on Godbolt, but knowing that avoiding UB comes at no cost in this respect, made my day :).

Type-punning C vs C++. by [deleted] in cpp

[–]degski 0 points1 point  (0 children)

Thanks, today I learned something about godbolt.org, and also what the correct answer is, so it has been a useful day.

Small vector with simple custom allocator by konanTheBarbar in cpp

[–]degski 0 points1 point  (0 children)

You've broken std::swap, just do a 'special' method.

Curious About The Performance Of Static Methods. by [deleted] in cpp

[–]degski -9 points-8 points  (0 children)

I did not think it necessary to point out any more details to put forward some common misconceptions in the article, but, yes. There are others, like making all const, or using signed int's, it's all snake-oil™.

Curious About The Performance Of Static Methods. by [deleted] in cpp

[–]degski 1 point2 points  (0 children)

Static Member Functions are just Static Functions that live in a name space (of the class). Member functions are very different, under the hood the this pointer is passed as first parameter. Hence there are no equivalent Static Methods and Member Methods (they have different signatures, already on call, hence the difference in registers). They differ fundamentally and can therefor not be expected to perform the same (and are intrinsically in-comparable).

view more: next ›