12 ms·

Modern C++ can be very pythonic. Still not as easy as writing Java in IntelliJ but CLion is becoming quite good (if you succumb to CMake). People write shit cod

• pjmlp 9y ago
  It became my next favourite language in 1993, after I start looking to a Turbo Pascal successor outside MS-DOS/Windows and C failed to impress me. Don't use it as I used to, but the improvements in the last years, specially after the introduction of AST libraries via clang, have done wonders to the eco-system. Now we just need C++ IDEs to catch up with Energize C++ and VA C++ v4, on their Lisp/Smalltalk like experience.
  • ShabbosGoy 9y ago
    The language has definitely come a long way. Coroutines are definitely a useful addition to clang. It was my #2 choice for writing a middleware for Elasticsearch, however I ultimately chose Golang because I didn't want to deal with CMake.
    • pjmlp 9y ago
      CMake isn't the only build system in town, not being able to use an expressive language due to a specific build system seems a bit too much.
      • _ak 9y ago
        The struggle with bad tooling is real.
        • pjmlp 9y ago
          I would understand dropping C++ for Swift, Rust, D ..., not Go. Borland C++ for MS-DOS had pre-processor macros for generic data structures, back when ANSI was still trying to figure out how templates should look like. On those days, Java or Oberon derivatives as alternative made sense, because templates weren't even a workable feature in 99% of C++ compilers, so most of us didn't had real exposure to them.
  • Cieplak 9y ago
    IPython has always been my favorite interactive UI, so if I had a ton of money to blow on tools, I'd love a more polished Cling (syntax highlighting, intelligent auto-completion, inline docs, emacs/vi keybindings) https://github.com/vgvassilev/cling https://github.com/vgvassilev/cling
    • Cieplak 9y ago
      Thinking about it now, I think we could get 90% of the way there just using python-prompt-toolkit. https://github.com/jonathanslenders/python-prompt-toolkit https://github.com/jonathanslenders/python-prompt-toolkit
      • swetabhsuman8 9y ago
        Don’t Be Fooled By Fake facebook Apps http://hackernucleus.com/phishing-dont-be-fooled-by-fake-facebook-apps/ http://hackernucleus.com/phishing-dont-be-fooled-by-fake-fac...
• josteink 9y ago
  > CLion is becoming quite good (if you succumb to CMake) As someone who rarely dabbles in C/C++, but still has some CMake under his belt... What's wrong with Cmake? I must admit for the use-cases I had, I found it quite a improvement over regular make.
  • Cieplak 9y ago
    I'm sorry; didn't mean to imply there was anything wrong with CMake, meant more as a joke and to suggest that CMake is a new tool that requuires a learning curve, like anything new, hence people resist, until it becames so prevalent that one gives up resisting and invests the time to learn it. In my case, it was to get CLion's external library interface working so I could jump to definition in headers in /usr/local/include
  • deleted 9y ago
    [deleted]
  • deleted 9y ago
    [deleted]
  • simias 9y ago
    Nitpick: despite its name CMake doesn't really replace make (actually you can use it to generate Makefiles instead), it's more of a build configuration system like autotools. As for criticisms of CMake, when I used it I thought it worked pretty well but I think its CMakeLists syntax is atrocious. Not that it's not an improvement over the autotools, but at least these ones have the excuse of being built on top of a mountain of legacy subsystems with various quirks.
    • MrUnderhill 9y ago
      I would love it if one day you could put a CMakeLists.xyz in the project instead, where xyz was just a slightly nicer syntax, but with the same semantics, and compatible with regular cmake. Tbh I'm not sure how I would want xyz to look though.
      • 9y ago
• FrancoAustrian 9y ago
  would you recommend a book/resource to learn modern CPP from?
  • FlyingSnake 9y ago
    Effective Modern C++ By Scott Meyers is good for beginners
    • jondot 9y ago
      Please don't. Not for beginners and not for veteran C++ programmers that want a refresher. I've been polyglot for the last 20 years, and as I've expanded my skillset through the years, I've let C++ go 15 years ago. With C++14 popping up, I gave it a try and liked the feeling - so I've decided to first go through the agonizing process of refreshing my memory (agonizing because it hurts to see how much you forget, being once considered "an expert"), and then figure out what's the delta towards C++14 and learn it. Obviously I went straight to the "Effective X" series thinking it should be a no-bullshit intro for an experienced developer. Acknowledging Scott Meyers is a great author, I'd say something morbid happened with this book. It feels that Scott simply bashes the language more than it introduces it - while he's obviously very knowledgeable and in the details he spots out glitches, pitfalls, death traps, and WTFs and keeps throwing these waves of "here be dragons" at you, that half way through I just quit reading it and quit attempting refreshing my C++ knowledge after my 15 year break up from it. You should get Stroustrups' "A Tour of C++" - it is a softer, more cheerful and proud book that'll motivate you (and god knows you need motivation with C++). While everything he says is true, and I don't want to say "it's better not to know these things", since then half a year passed and I gave modern C++ another try _without_ this morbidness to follow my attempt. I've been happy following "soft" intros into modern C++, without the bummer parts. Truth be told I haven't bumped into what Scott has kept highlighting - yet. So I would say Effective Modern C++ is for very experienced C++ developers with fresh memory of how the internals work.
      • falcolas 9y ago
        As someone who tried to bone up on my rusty C++ from this book, I agree with every point jondot made above. It's a disaster to try and understand unless you are already starting from a very strong point in your C++ knowledge.
• oblio 9y ago
  As a non-C++ coder there are two things that "scare" me about C++ (ok, maybe not scare, but are definitely big turn offs): - lack of a proper, cross platform, package manager: I know the history, I know that C/C++ are basically embedded in the system and they use the system package manager, but in this age it just doesn't fell right... I've been spoiled by many years of using Maven and other similar tools - template meta-programming plus the C++ legacy features which are probably lurking in many third-party libraries (simpler languages have fewer features to abuse and even when for whatever reason you have to use a relatively subpart third-party library, you know they can't do that much damage) There's also the compilation speed, but as far as I know there are workarounds for that. These things are, if not unsolvable in C++, at least many years away from being available. Maybe an experienced C++ coder can destroy my preconceptions :)
  • entelechy 9y ago
    there is the https://buckaroo.pm https://buckaroo.pm package manager.
  • hellofunk 9y ago
    Template meta programming is unnecessary to use C++, even in its most complex of applications. It's nice if you can do it, but a lot of companies don't like developers to use TMP too much because it's not expected everyone will know or understand it. I consider it an extension to the language that is cool but not necessary for most of the work you do. It's great that it is there, and great that your compiler and library authors use it to make the tools you use very fast, but for your own code, it's just not a gripe you need to worry about.
    • jackcviers3 9y ago
      I see this sentiment all the time, in every programming language - x feature is for library authors, but it is bad for application devs because we cannot understand it. It's a terrible notion. Royal you and we below, not specifically hellofunk or op. You use the libraries, so your application uses the feature already. You should understand one layer of code beneath yours. You should have an interface layer between your code and the library. By not doing either ( because libraries use magical features ) you are coding yourself into a corner with a feature you don't understand. The libraries use it so that their code can be more general and well-specified. The libraries are used by thousnands more developers than your code. Your code probably could also be easier to maintain if it was more general and well-specified. Imagine if thousands of people could reuse your authentication interface at your company! Think of the money you will save. All it takes is time to learn a feature you must partially understand because you are using the library built ON that feature. EITHER learn the feature, or use libraries that only use features you understand. If you can't use the language without the feature, you can't use the language without understanding the feature. If you allow libraries that use the feature in your app code, you should allow app code that uses the same feature.
• EricWF 9y ago
  If you understand the internals they're anything but pythonic. Coroutines can be a zero overhead abstraction in the some cases. For example here is a test that verifies the optimized output for a simple (and misnamed) integer generator compiled at -O2. Notice the arguments to `print` are integer literals. (https://github.com/GorNishanov/clang/blob/Experiments/test/CodeGenCoroutines/O2-generator.cpp https://github.com/GorNishanov/clang/blob/Experiments/test/C...) I'm no python expert, but I suspect C++ optimizes this code better.
  • yzmtf2008 9y ago
    I think the point of being pythonic is that it's more friendly to the programmers. Bonus point if it's also optimized :)
    • electrograv 9y ago
      I love seeing the difference between Python and C/C++ coder cultures: To a Python'er, bonus points are given for performance and friendly coding is nearly assumed. To a C++'er, bonus points are awarded for friendly coding, and performance is nearly assumed. (Even more, I love how we're seeing some convergence here: no-compromise improvements to weak spots on each "side" of the programming language spectrum.)
• Veedrac 9y ago
  C++ is one of the least Pythonic languages I know. It clashes with nearly every point on the Zen of Python[0], and C++'s "modern" libraries do nearly nothing to change that. [0]: https://www.python.org/dev/peps/pep-0020 https://www.python.org/dev/peps/pep-0020
  • dmix 9y ago
    > Beautiful is better than ugly. This one is the most apparent. Almost every example in the C++ v. Python in the article above the C++ version is notably uglier. Just look at Lambda expressions: Python def adder(amount): return lambda x: x + amount C++ auto adder(int amount) { return [=](int x){ return x + amount; }; } I'm assuming [=] is used to represent Lambda here? That seems like a strange syntactic choice to me. Edit: turns out there are various forms of Lambda (of course there wouldn't just be one in C++), for ex: [a, &b], [this], [=], [&], [] Depending on how the variables are captured. Capturing that additional complexity in a tight space is the cause of the ugliness here. http://en.cppreference.com/w/cpp/language/lambda http://en.cppreference.com/w/cpp/language/lambda
    • gpderetta 9y ago
      Also note that C++ needs the curly brackets because, differently from python, lambdas can contain arbitrary statements, not just one expression (one would use a local function in python). There have been discussions about adding a lighter syntax for single expression lambdas that doesn't require the curly brackets and the 'return' keyword, but so far no actual progress.
    • swordfeng 9y ago
      [] marks the beginning of a lambda. In which declares whether variables are passed by value(=) or reference(&).
    • marcosdumay 9y ago
      That C++ line is very C++nic... It's much better specified, gives you much more power than the Python one, tells you exactly what is happening, is so short it's cryptic, and is ugly as hell.