5 ms·
Most of its in a private GitHub repo but I think I can open a piece of it… here is part of it ... a header only library for computing closest pairs... https://
by waynecochran 4y ago
Most of its in a private GitHub repo but I think I can open a piece of it… here is part of it ... a header only library for computing closest pairs...
https://github.com/wcochran/closest-pairs/blob/main/closest-pairs.h https://github.com/wcochran/closest-pairs/blob/main/closest-...
- mike_hock 4y agoWhy is Eigen/Dense included if you never refer to anything Eigen and just take it as a duck-typed template parameter?
- waynecochran 4y agoTrue.. good eye .. the operations on type P are very Eigen specific, but another type could easily provide those.
- bugfix-66 4y agoAfter giving your code a quick skim, I cannot see any mistakes in your vector indexing. However, your code is full of vector accesses without bounds checking: vec[i] instead of vec.at(i). That's just as "unsafe" as C, so I recommend not bragging about how far you've come. Your code is full of what is essentially unprotected C-style *(addr + i) = ... ... = *(addr + i) You've been writing C++ since the 1980's, but your code is full of raw pointer math, and yet... "No worries about memory safety"? I have a feeling you'll be reaching for Valgrind or address sanitizer someday soon, just like the C programmers.
- waynecochran 4y agoNot bragging at all.. it was just introspection on how different my code looks now… maybe I should find some older code that is fraught was dangerous constructs. In fact, early versions of this were segfaulting for the very reasons you mention.
- bugfix-66 4y agoThank you for being honest. This safe, "no worries" C++ was segfaulting. You've managed to make it correct today but it's still unsafe. Someday one of your coworkers is going to break it and this code will be trashing the heap. Mysterious memory corruption failures are your destiny. That said, Happy Halloween!
- WoodenChair 4y agoYour comments come across as pretty mean-spirited. Let me rewrite one line for you. You wrote: > Someday one of your coworkers is going to break it and this code will be trashing the heap. Mysterious memory corruption failures are your destiny. You could have written something like, "It's possible this code will break in the future and you won't even realize the cause, because it will appear as a mysterious memory corruption failure." See how I left out a word like "destiny" and took out the whole bit about coworkers? Yeah, much nicer and less personalized.
- bugfix-66 4y agoAnd then I said "Happy Halloween". The point was that being a C++ programmer is like being part of a horror movie. I say that as a person who uses C++ in my day job. It's a nightmare.
- waynecochran 4y agoI have a love/hate relationship with C++ ... probably like most C++ programers.
- bugfix-66 4y agoI have no love for C++.
- MikeDelta 4y agoThe point of the post by my fellow HN person was to give you feedback on your communication style. You obviously have interesting things to say and opinion to share with a fair amount of passion, but the tone detracts from the message, which I find a pity.
- deleted 4y ago[deleted]
- pjmlp 4y agoWell, there is always a option to enable bounds checking in operator[](), all major compilers provide defines or compiler switches for that, and I would advise anyone that cannot prove otherwise via a profiler to do just that.
- jcelerier 4y agoUh no, vec[i] may be unprotected in release mode but all three major standard library implementations, MS STL, libc++ and libstdc++ have bound checking in debug mode (along with many other sanity assertions, such as correct sorting predicates, etc) ; this way you get the (horrendous) bound-checked cost when developing and can ensure decent performance in release.
- garaetjjte 4y agoWho really uses debug builds in modern C++? They are just too slow to be usable.
- scatters 4y agoDebug doesn't have to mean unoptimized.
- usefulcat 4y agoA) I do B) plenty of “debug” checks can be enabled in a “release” build, e.g. just don’t define NDEBUG
- jcelerier 4y agoI do as far as is possible all of my development under my stdlib's debug mode with -fsanitize=address and -fsanitize=undefined. If it's slow like this on my 2018 workstation, it'll be slow in release mode on my users's 2011 dual core laptops and on raspberry pis. but if you need a bit more speed you can still build with -O2 -D_GLIBCXX_DEBUG=1 -D_GLIBCXX_DEBUG_PEDANTIC=1 # for libstdc++ -O2 -D_LIBCPP_DEBUG=1 # for libc++ /O2 /D_ITERATOR_DEBUG_LEVEL=1 # for msvc this way you get compiler optimizations but the assertions are still there
- CamperBob2 4y agoThey compile a lot faster.
- gumby 4y agoI do! How do you use a debugger otherwise?
- curiousgal 4y agoYou could have raised any of those technical poitns without coming off as an asshole.
- usefulcat 4y agoTo me the code looks like very reasonable c++, and quite modern. I suspect the comment about memory safety may have been related to leaning heavily on things like iota, copy, partial_sort, lower_bound, etc as opposed to doing those things “by hand”.
- hoseja 4y agoI think it's much better to double-check your i's than to use `vector.at(i)`. Being unchecked at runtime is the benefit.
- Icathian 4y agoMuch appreciated, thank you!