101–110 of 259 posts
Welcome! As someone who’s been using C++ pretty much continuously for two decades, I think there has never been a better time to learn it. We finally have compiler competition that has resulted in robust support for the language’s great features.
"To round up, C++ does not dictate about its tooling, which basically gives lot of choices and flexibility. But at the same time it is making it complex for beginners to come in to projects and start projects with it." This was a big problem for me when I first started using C++. I don't remember it being too bad when I was just working on small projects and things I wanted to do at school. The problems started when…
All C/C++ projects I have ever seen used either cmake or autoconf build system. It's pretty standard.
Meson seems to be spreading pretty rapidly. After I was introduced to it a few years ago for work, I started using it as my default build system for C++ elsewhere and more C++ devs I know have started using it. I've seen it replace CMake and make at large companies for C++.
Earlier quoted context omitted.
C++ is commonly used for large complex projects. The problem with opinions is eventually you come across something that the opinion will not allow. For a small project an opinionated build system makes things easier and you essentially never run across something that can't work. For very large projects that is not true and so you end up fighting opinions in some place.
Examples? As a maven advocate I've commonly seen this claimed ("we have to have an ant build because we need to do x/y/z custom thing") but I've never seen an example that held up under scrutiny. E.g. there's no reason any project would ever need a custom source directory layout. No project needs to run tests before compile (and if you really need build step x to happen before build step y, you can always separate th…
Maybe one can't reorganise the source tree layout because to do so would break our custom tooling / integration systems / interface with proprietary vendor tools. We can't change version numbering schemes because our packages already exist 'in the wild' and can't be changed mid-sequence without causing both technical and user pain.
Fundamentally: the codebase has worked perfectly well this way for the last 20 years; what's the business case for changing it (at potentially significant cost) just to be compatible with XYZ new tool that everyone is rallying behind?
"To round up, C++ does not dictate about its tooling, which basically gives lot of choices and flexibility. But at the same time it is making it complex for beginners to come in to projects and start projects with it." This was a big problem for me when I first started using C++. I don't remember it being too bad when I was just working on small projects and things I wanted to do at school. The problems started when…
I ran into this trying to get into it about 3 weeks ago. I'm so used to things like npm, ruby gems, go packages, pip that it felt like a huge task just to get something built or settle on a way for me to build mine. Even grabbing libraries from github, I was unsure if I should grab just the headers and DLLs, or import the entire tree and mashup my build scripts with theirs. I wish I had stayed with it since college b…
Honestly this is something that apt (et al.) make so easy on Linux distros that when you move to Mac or Windows you just have hard time believing people still in 2018 have to _deal with this shit_ (installing libraries and their headers by downloading each one separately and running an "installer" and trying to figure out where it put everything)
Like, why. It's one of the principle things keeping me away from developing on Windows for the last 10 or 15 years, the absolute lack of standards with regards to dev package management. Every time I decide I need to get something working on Windows it's an incredible pain in the ass compared to Ubuntu. Oh, now go to THIS website and download this installer and run it, now this one, now this one. And figure out for each one where it decided to put the headers. Now copy the DLLs around, etc. (Yes, there is system32 and Program Files but installers don't adhere to this by any means, and discovery via a build system is not given.) It's just barely worth it, and people only put up with it because of the huge user base. Honestly, for small projects I've found it easier to install MingW32 under Linux and cross-compile instead of working on Windows, it's that much of a pain.
At least Mac has Homebrew and Windows has a couple of good solutions now I guess (chocolatey, who came up with that name), but they are not officially supported and that is sad. I understand, they don't want to pay an army of people to package open source software full time, which effectively is what keeps Debian and Fedora going.. but they should. I would say it's one of principle reasons then end up doing something like providing an Ubuntu environment on Windows .. it's not just that people wanted a Unix-like environment, it's that they wanted _package management_.
Earlier quoted context omitted.
Things I'd rather be doing: * C++ * Lua .. .. [a thousand other things] .. .. * Node * Javascript __ bottom of the pile.. The Node/JS ecosystem is such a steaming pile of garbage, I can honestly see with great clarity why people should be running from it back into the arms of C++[11,17] ..
You shouldn't make broad statements like that. In my personal experience, I have found Javascript much easier than C++. If I want to install a package, I can just do "npm install Now, I'm sure some people have an easier time with Makefiles, but I've found it even easier to get up and running in Javascript. Most of the tools in Javascript (create-react-app, Webpack, etc.) are very user friendly, making setup trivial.…
https://nbviewer.jupyter.org/gist/ontouchstart/1af198f8535eb...
I like that the author mentions the STL explicitly. The STL is one of the most beautiful libraries ever written. There are few language libraries that are as clear and well designed as the STL. Alex Stepanov is completely underrated outside the C++ community.
Some wouldn't agree: http://wiki.c2.com/?StlSucks Personally, I find Scala standard library much easier to work with and at the same time much more flexible and powerful.
Earlier quoted context omitted.
I think that statement would have to be classified as inaccurate. using C++ teaches you mostly about general purpose programming and it's pretty easy to go from C++ to python to Java to bash, etc.
Nonsense. C++'s template system behaves unlike any other language (things like SFINAE and the techniques that use it do not transfer), C++-style RAII is relatively unusual, I don't think any other language requires the programmer to think about virtual versus non-virtual inheritance, the C-derived sequence point rules are obscure and much looser than most languages' evaluation rules, the exception-safety rules are un…
The complication is C++ specific and moving to java, bash or python is simply removing that complexity. Hence moving to C++ is easier then moving from python or another similar language because in most cases you would be adding complexity.
OCaml and Erlang are too different for me to comment about a transition in the functional direction.
> My quest for relearning C++ started in November 2018. That’s great! I’ve been using it since 2013 and still haven’t learned it!
What language can one say that they fully master? I've been using Python since 2008-ish on and off for various scripting tasks and small tools, I can't say that I've "learned" it. They keep adding new stuff, some things I forgot, others I never needed. I've been using C++ professionally since ~2006 and for similar reasons I won't say that I master it either. Metaprogramming is a clear weak point for me, but OTOH I fi…
Earlier quoted context omitted.
I ran into this trying to get into it about 3 weeks ago. I'm so used to things like npm, ruby gems, go packages, pip that it felt like a huge task just to get something built or settle on a way for me to build mine. Even grabbing libraries from github, I was unsure if I should grab just the headers and DLLs, or import the entire tree and mashup my build scripts with theirs. I wish I had stayed with it since college b…
> Even grabbing libraries from github, I was unsure if I should grab just the headers and DLLs, or import the entire tree and mashup my build scripts with theirs. Honestly this is something that apt (et al.) make so easy on Linux distros that when you move to Mac or Windows you just have hard time believing people still in 2018 have to _deal with this shit_ (installing libraries and their headers by downloading each…
I do agree that there is a lot of room for standardizing tool chain and dependency install workflows, but the tools themselves are of high quality now imo.