Ask HN: Who is using C++ as the main language for new project?
181–190 of 199 posts
Re: Ask HN: Who is using C++ as the main language for new project?
#182I am (new as in 3-4 years old) - a shared library compiler for a text language, CLI for easy access to compiler and a visual editor for a graph/node-based representation of the text language, used for audio programming primarily in games - built on LLVM (For the compiler) and JUCE (for the graphics). The shared library has few dependencies outside of LLVM so that it can be as portable as possible, and the runtime hoo…
There is no C++19. What do you mean?
Re: Ask HN: Who is using C++ as the main language for new project?
#183Started a new job which requires me to know c++ so I’m learning that. Half c# and half c++. Bought some books. - Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14 - C++ Concurrency in Action - C++ High Performance: Master the art of optimizing the functioning of your C++ code If anyone has any recommendations would love to hear them.
if you are into videos, there's the back to basics from cppcon which is an absolute god send when you are just starting out.
Re: Ask HN: Who is using C++ as the main language for new project?
#184Re: Ask HN: Who is using C++ as the main language for new project?
#185Earlier quoted context omitted.
Don't know your use case, but C++ for a REST api seems extreme overkill. Any performance benefits would most likely be nullified by network latency
> Don't know your use case, but C++ for a REST api seems extreme overkill. Any performance benefits would most likely be nullified by network latency It seems you're mistakenly confusing the time a request takes to be fulfilled with performance. In the server, performance means throughput. If means nothing if a task handler stays ages waiting for IO. What matters is that once a task is ready to run, the code that nee…
Re: Ask HN: Who is using C++ as the main language for new project?
#186Earlier quoted context omitted.
I think I got the right one. https://www.amazon.com/Effective-Modern-Specific-Ways-Improv... Was printed in 2014. The older one which is `effective C++` is printed in 2005.
yeah maybe my message wasn't clear, i was trying to say that you should read both, the old one is still valuable
I thought it might be wasted money to get the old one but if its still worth it Ill definitely consider it!
Re: Ask HN: Who is using C++ as the main language for new project?
#187Starting a new side project, no platform-specific functionality needed. Tried out a few relatively "new" languages (more like new to me) and experienced severe frustration from bugs and spotty documentation, lack of proper IDE/debugger support. So, I figured, better the devil you know. And of course: choice of compilers, choice of FOSS libraries, my own libraries and workarounds to various well-known annoyances and,…
Have you tried GO with GoLand IDE?
What are your favorite features?
Re: Ask HN: Who is using C++ as the main language for new project?
#188Earlier quoted context omitted.
Exactly, and the Rust version will "mysteriously" turn out to have fewer security vulnerabilities, scale beyond 1 CPU core, and have a nicer CLI interface :-)
Because a rewrite in the original language never sees improvements like that...
1) Global state is discouraged by the Rust compiler: You have to explicitly put code which modifies global state inside unsafe blocks, to alert you that you have to manually ensure thread-safety for that state. gcc, for example, is infamously reliant on global state, to the point where it's impossible to have two targets within the same binary.
2) The compiler prevents you from sharing non-thread-safe data structures across thread boundaries (again, unless you explicitly use unsafe blocks). As a result, if the compiler accepts your code, you can be reasonably sure that the third-party library you're using to compress your data in parallel is also thread-safe and doesn't trigger concurrency bugs. Anecdote: Recently I wanted to use LLVM's new JIT infrastructure – which was re-designed with the explicit goal of being thread-safe! It worked fine when single-threaded, but resulted in weird errors when running in two threads in parallel. It turned out that the optimization passes used by the JIT weren't thread-safe after all... Of course, this wasn't documented anywhere. I guess I could count myself lucky that I discovered this problem so quickly, instead of hard-to-debug errors in production. Rust, in contrast, would've rejected that program outright.
Re: Ask HN: Who is using C++ as the main language for new project?
#189Earlier quoted context omitted.
I assume this is a command-line application? c++ does have a cross-platform GUI problem, unless you pay for the Qt license that is, which is itself a heavy ecosystem to master.
No, it's a GUI application. There are ways of making the GUI parts cross platform, like webview and such. But the GUI parts in this application are native to the OS. "Only" the core functionality is shared between platforms. This is also something I have been battling with in the past. All the cross GUI platforms have their quirks and problems and varying OS dependencies you are then married to. Since this is my own…
Re: Ask HN: Who is using C++ as the main language for new project?
#190Earlier quoted context omitted.
I think the RTOS side is being addressed pretty well for rust, which libraries do you feel are missing now?
Last time I looked, RTIC was the most complete RTOS implementation, but it lacked some functionality related to timeout actions in the network stack that I needed (and was provided by FreeRTOS). Functionality appears to be increasing fairly rapidly though, so I might take another look soon.
Stack sizing is hard. Stack swapping kills caches. Stack overflows can be very infrequent and hard to debug. Thread priority doesnt always do what you think. Even with threads not every RTOS does time slicing.
So right is there a complete network/usb/ble stack in rust today? Not that I’ve seen. So I can understand needing those and thinking maybe it’s not quite there. I do think though that some really interesting and cool ideas on scheduling, device Hal’s, and state machinery has been pretty well explored at this point. It’s still young but evolving and maturing quickly.