Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye C++, Hello C

momentsingraphics.de

Post reply on HN
Print view View original

31–40 of 222 posts

Re: Goodbye C++, Hello C

#31

Post by wyager »

userbinator wrote: post #21
maleldil wrote: post #12

> Where C++ gives you many slightly different takes on the same concept (e.g. unique_ptr, shared_ptr and raw pointers), C gives you one way to go and that one has a conveniently compact notation (such as float ). You use unique_ptr and shared_ptr because float is unsafe. If you don't care about the safety that smart pointers provide, you can use float* in C++ too. > ticking with the example of matrix math, it is baff…

"safety" is really overrated. The paranoia-fueled security industry has turned programming into some sort of weird authoritarian dystopia.

Is this a joke? Do you really think managed pointers are an example of authoritarian dystopianism?

Re: Goodbye C++, Hello C

#32

Post by patrick451 »

jcelerier wrote: post #29
syockit wrote: post #9

Earlier quoted context omitted.

The compiler cannot catch logic or design errors. If you made a mistake when designing the algorithm and implemented it as it is, you'd need to debug anyway. Sometimes it's something as simple as missing a minus symbol somewhere in your equations. Working with Eigen was especially painful. All the template magic it uses means what would have taken 1 second to compile if used BLAS/LAPACK, now takes 10-20 seconds.

> The compiler cannot catch logic or design errors. If you made a mistake when designing the algorithm and implemented it as it is, you'd need to debug anyway But that's the thing, it can. - you can specify compile-time preconditions and use the type system to ensure value are in range (which catches a ton of errors) - you can use constexpr to enforce no UB (UB in constexpr evaluation is a compile error) For instance…

How does the type system catch this bug

double negate(double x){ return x; }

?

Re: Goodbye C++, Hello C

#33

Post by Wowfunhappy »

ninepoints wrote: post #22
AussieWog93 wrote: post #16

Earlier quoted context omitted.

You're right. I did some graphics work in my last job. OpenGL2 is supported by just about every device made in the last 15 years, on every major operating system, including software OpenGL in VMs. Vulkan is not officially supported on OSX (although there is an unofficial port that is quite good, from what I understand) and only runs on modern hardware.

> Vulkan is not officially supported on OSX And neither is OpenGL

Deprecated, not unsupported.

And, like, Apple ported OpenGL to Apple Silicon macs. I suspect it's going to stick around, it's just never, ever going to get updated.

Re: Goodbye C++, Hello C

#34

Post by jcelerier »

patrick451 wrote: post #32
jcelerier wrote: post #29

Earlier quoted context omitted.

> The compiler cannot catch logic or design errors. If you made a mistake when designing the algorithm and implemented it as it is, you'd need to debug anyway But that's the thing, it can. - you can specify compile-time preconditions and use the type system to ensure value are in range (which catches a ton of errors) - you can use constexpr to enforce no UB (UB in constexpr evaluation is a compile error) For instance…

How does the type system catch this bug double negate(double x){ return x; } ?

I'm sure that in 1986, before standardizing ANSI C, someone victoriously typed the same thing in front of his tty in a discussion about using types in declarations and not just doing it à la K&R with just the function name being called cowboy-style.

Just because a system does not catches all bugs does not make it useless - for me, even if C++'s type system had caught only one bug it'd be worth it (and in most of my code, which is mainly about fairly specific domain objects, the compiler saves me from myself pretty much daily).

In any case, I'd likely have this somewhere

    constexpr double negate(double x) {
        return -x;
    }
  
    // example implementation for the sake of the comment, there are much more exhaustive libs out there
    constexpr bool sample(auto func) {
        bool ok = true;
        double x = -1000.;
        while(x
this way I'd get a compile error if my cat walks on my keyboard and inadvertently removes the - (also a relatively common occurence)

Re: Goodbye C++, Hello C

#35

Post by greesil »

wyager wrote: post #31
userbinator wrote: post #21

Earlier quoted context omitted.

"safety" is really overrated. The paranoia-fueled security industry has turned programming into some sort of weird authoritarian dystopia.

Is this a joke? Do you really think managed pointers are an example of authoritarian dystopianism?

unique_ptr is a conspiracy, man. You see, the people who make money off of mallocs (those corrupt DRAM manufacturers) want it to stay that way. Just follow the money.

Re: Goodbye C++, Hello C

#36

Post by taneq »

userbinator wrote: post #21
maleldil wrote: post #12

> Where C++ gives you many slightly different takes on the same concept (e.g. unique_ptr, shared_ptr and raw pointers), C gives you one way to go and that one has a conveniently compact notation (such as float ). You use unique_ptr and shared_ptr because float is unsafe. If you don't care about the safety that smart pointers provide, you can use float* in C++ too. > ticking with the example of matrix math, it is baff…

"safety" is really overrated. The paranoia-fueled security industry has turned programming into some sort of weird authoritarian dystopia.

Yeah man bring back peek() and poke() haha live life on the edge!

Re: Goodbye C++, Hello C

#37

Post by TwoBit »

userbinator wrote: post #21
maleldil wrote: post #12

> Where C++ gives you many slightly different takes on the same concept (e.g. unique_ptr, shared_ptr and raw pointers), C gives you one way to go and that one has a conveniently compact notation (such as float ). You use unique_ptr and shared_ptr because float is unsafe. If you don't care about the safety that smart pointers provide, you can use float* in C++ too. > ticking with the example of matrix math, it is baff…

"safety" is really overrated. The paranoia-fueled security industry has turned programming into some sort of weird authoritarian dystopia.

You forgot to add /s to the end of your comment.

Re: Goodbye C++, Hello C

#38

Post by aksss »

wyager wrote: post #31
userbinator wrote: post #21

Earlier quoted context omitted.

"safety" is really overrated. The paranoia-fueled security industry has turned programming into some sort of weird authoritarian dystopia.

Is this a joke? Do you really think managed pointers are an example of authoritarian dystopianism?

Thread safety is like bicycle helmet laws, discuss..

Re: Goodbye C++, Hello C

#39

Post by Santosh83 »

wyager wrote: post #31
userbinator wrote: post #21

Earlier quoted context omitted.

"safety" is really overrated. The paranoia-fueled security industry has turned programming into some sort of weird authoritarian dystopia.

Is this a joke? Do you really think managed pointers are an example of authoritarian dystopianism?

He is talking (I believe) about the general trend of nudging, cajoling more and more coders into using managed, very high level, safe languages and runtimes, and in general discouraging peeking under the hood, at the hardware level, as something raw, wild or unsafe. Yes you can still do it on a RPi, but perhaps in another decade or so, you might not be allowed to program in 'unsafe' languages on all other mainstream platforms, unless you register for a driver/system developer license or something, or not even that.

The tinkerer/hacker ethos is disappearing slowly from PCs. It never caught on in the mobile world. It may perhaps only survive as a remnant in specialised chips and boards designed for learning.

Re: Goodbye C++, Hello C

#40

Post by jcelerier »

I wonder what kind of hardware OP runs on, and which compiler is used.

Here on my laptop (Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz), on linux, compiling an eigen example takes 0.7 seconds

    clang++ -fuse-ld=lld eigen.cpp -I/usr/include/eigen3/  0,66s user 0,07s system 100% cpu 0,728 total
if I put the eigen header in a PCH this drops to 0.1 seconds

    clang++ -fuse-ld=lld eigen.cpp -I/usr/include/eigen3/ -include-pch   0,08s user 0,02s system 104% cpu 0,099 total
I have a hard time seeing how 300 lines of code (vs the 10 lines of the example) would multiply compile times by 300 - here's the example I used

    #include 
    #include 
 
    using Eigen::MatrixXd;
 
    int main()
    {
      MatrixXd m(2,2);
      m(0,0) = 3;
      m(1,0) = 2.5;
      m(0,1) = -1;
      m(1,1) = m(1,0) + m(0,1);
      std::cout
I develop a GUI software with boost, Qt, and a fair amount of TMP and my average turn-around time from a change in the average file to the program running is between in and 2 seconds. Maybe it could get down to 0.1~ seconds if using C, but there would be so many less checks and guards !
Post reply on HN