Can anyone recommend a good book for numerical c++ in 2024?
Maybe Discovering Modern C++ 2nd edition. But check the table of content before buying, it may be too beginner level for you.
3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup
131–140 of 231 posts
Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup
#132This is the book i used to learn programming 10 years ago! After that I never really learnt anything new.. been using the same concepts.
Did you use it to learn programming as a novice to the field? I have always wanted to learn programming as a hobby, but never really found the right entry point. Would you recommend this?
For hobby programming, Python is the best (unless you want to do web development in which case JavaScript is what you want). For Python, a really good book for beginners is Python Crash Course.
Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup
#133Earlier quoted context omitted.
I started because I became interested in graphics and audio programming. Audio plugin development in particular is completely dominated by C++.
Do you have any recommendations for someone interested in audio programming?
The Will Pirkle books are good.
Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup
#134Earlier quoted context omitted.
For the better, with Qt there is QtCreator.
Not sure what you are trying to say here. Qt, the library, and QtCreator, the IDE, are completely separate products. You can use QtCreator without Qt and vice versa. Now, I'm pretty sure you know that, hence my confusion...
Qt Creator makes working with Qt a heck of a lot easier in a way that working with Visual Studio or vim does not. It comes with an integrated Qt form designer, Quick Designer for QML, supports Qt's moc syntax out of the box, integrated support for Qt Test Integration, native support for Qt Assistant and documentation and integration with Qt's internationalization tools.
The idea that "QtCreator" is some totally independent IDE that just coincidentally happens to have the letters Qt at the beginning in the same way that Java and JavaScript are independent of one another, but otherwise has no relationship to Qt the library is just patently absurd HN pedantry.
Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup
#135Earlier quoted context omitted.
I felt some nostalgia for Fortran a while ago. Spent half an hour programming in it, cured. Maybe take a shot at parsing JSON in C++ and see if the nostalgia survives the process.
Let me carefully copy paste my personal stringutils.hpp file of string handling routines and I'll be right up to it!
Gotta have those "readfile()", "replace_substr()", "split()" etc! I do have a copy paste string util header. ..
I really wish there were more string util functions in Cpp. I mean C had strtok()!
Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup
#136Know what I like about Stroustrup's code? "using namespace std;". The typical convention of sticking std:: in front of std::every std::last std::bloody std::thing drives me std::insane.
It depends ... You should NEVER have "using namespace" (for any namespace) in a header file, since that is how you create name clashes, which is what the namespaces are there to avoid. I don't personally like "using namespace std;" even in implementations, since I think it makes code less readable, and the contents of std:: is so large, and growing, that I'd again prefer to just avoid the possibility of name clashes.…
>We write code once, but read it many times, so shorter names (incl. namespaces) seems like a poor efficiency choice.
I think it's fascinating how different people can interpret this so differently. I feel like it's precisely because we read code so much more than we write it that we should prefer using names that get to the point, instead of having so much noise and repetitive boilerplate.
Reading a soup of std::this, std::that, std::foo, std::bar is so difficult to parse through. Especially if you're like me and you sound things out in your head, which I recently learned is not how everyone reads.
The only justification for writing all those std::'s is because compilers can't disambiguate names from their context, but you're not going to find a human who comes across a use of vector, or sort(...) and throw their hands up in confusion wondering what was meant.
>We write code once, but read it many times, so shorter names (incl. namespaces) seems like a poor efficiency choice.
This to me seems like a cargo cult justification, where you've heard the argument that descriptive names are helpful for readability, so we should name our variables in a way that conveys their intention as opposed to 1 letter names or obfuscated abbreviations, but instead of genuinely understanding the principle behind the rule, you think the rule is simply that it's better to have long names over short names.
Descriptive names that can be used to disambiguate variables from one another on the basis of their purpose... yes, please do that. Writing long names just so that they are long, especially by giving everything a shared prefix like std::... no, that's a misunderstanding of the justification behind the rule.
It's similar to that saying along the lines of when a principle becomes a metric, it ceases to be a useful principle.
Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup
#137Earlier quoted context omitted.
QtCreator helps with the learning curve as it‘s a very accessible IDE. One of the first IDEs I used in my career.
Sure, QtCreator is nice and it's actually my IDE of choice. I just wanted to point out that it is independent of Qt, the library.
How it compares to CLion?
Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup
#138Earlier quoted context omitted.
I felt some nostalgia for Fortran a while ago. Spent half an hour programming in it, cured. Maybe take a shot at parsing JSON in C++ and see if the nostalgia survives the process.
>Maybe take a shot at parsing JSON in C++ and see if the nostalgia survives the process. I have used this library in the past and was actually pretty easy https://github.com/nlohmann/json
Your recommended json solution was also my first thought but if you do not have the ability to easily introduce a new dependency then the op is correct.
If I have an existing JSON file that I want to quickly parse for a demo project there is almost zero chance I would pick C++. In comparison, Python is already installed in many environments and has built-in json parsing.
Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup
#139[flagged]
Well, he's articulate and very experienced with software development who invented the original C++ out of necessity. In fact, he sounds like an ideal person to tech good programming practices using the language he helped design.
OP is making a dig at C++ the language. A lot of people, most likely OP included, consider the language to be a monstrosity, so how can the person who developed such a monstrosity possibly share good advice on programming?
That said, I sometimes get the impression that Bjarne recognizes the monstrosity that he created and a large part of his talks and his book is how to make use of the good parts of C++ without making use of the bad parts.
Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup
#140Earlier quoted context omitted.
The idea of using Rust for scripting is bizaar. I can understand not wanting to use Python for everything, but I see the problem being the 'use it for everything' not the language choice. Use the tool that excels at the job. There is no language that is good at everything.
Incidentally, this thing comes up a lot: Python vs Rust for scripts. I wrote a comparison four years ago: https://news.ycombinator.com/item?id=22712441 And updated it six months later: https://news.ycombinator.com/item?id=24595081 That's still how I'd do this task today. Anyway, I don't think that Rust is always a great choice for scripting, but if you already know Rust, it's totally fine at it.
Same for C++ with a good options library and std::filesystem IMHO. You can kind of script with that. I did it and was surprised it did well for some of my engine tooling.