Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Monday October 28 2019, @06:05AM   Printer-friendly
from the evolve-or-die dept.

C++ is a language you should give serious consideration to learning in 2019 (or whenever you happen to come across this article). Rapid language modernization, better tooling, a growing and inclusive community, and a thriving job market are just some of the reasons C++ should be your next language to learn.

Wow, this guy drank too much Kool-Aid ™️️, I'm out.

Yeah, I get it. At least in the communities I've been a part of over the years, C++ has a consistently bad reputation.

...

Modern C++ (versions ≥ 11) is an entirely different beast and should be considered separately.

foreach new_shiny in hackerland
    { import; improve; integrate; }

Plus, importing crusty old code into your projects is fun, well, at least more fun than dissecting them and re-coding in a new language which lacks the libraries they leaned on.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by hendrikboom on Monday October 28 2019, @02:50PM (8 children)

    by hendrikboom (1125) Subscriber Badge on Monday October 28 2019, @02:50PM (#912820) Homepage Journal

    These days I use Go (I've tried Rust) and especially Scheme (sometimes typed Scheme). Scheme is an update on Lisp, for which my usage dates back to the sixties. There are documented histories of huge programs written in C/C++ being converted to Scheme with a resulting *increase* of efficiency.

    Yes, I still maintain some old code written in a C-like dialect of C++. I enjoy the slight edge of security C++ has over C if you don't use most of C++

    What do others use?

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 1, Insightful) by Anonymous Coward on Monday October 28 2019, @04:19PM (1 child)

    by Anonymous Coward on Monday October 28 2019, @04:19PM (#912868)

    I also tend to see performance improvements when I rewrite code with the clarity of hindsight.

    • (Score: 3, Interesting) by hendrikboom on Monday October 28 2019, @04:29PM

      by hendrikboom (1125) Subscriber Badge on Monday October 28 2019, @04:29PM (#912876) Homepage Journal

      Yes, that's probably part of the mix.

      What one such project did is to add a scripting language to their unmanageably huge C/C++ code. The scripting language chosen was Gambit, a Scheme dialect with an unusual affinity to C/C++ because it is compiled to C.

      What they discovered was that it was usually easier to implement new features on their system as Gambit scripts than to write it them in C/C++.

      Then they discovered that when fixing bugs in their code it was often easier to replace parts of their system with scripts than to debug the original.

      And Gambit scripts could be compiled; they didn't have to be interpreted.

      In the course of about two years, the total code size went down by a factor of almost ten and the system got faster (I no longer know by how much).

      The changes were all incremental. At no point did they throw out the whole thing to rewrite it.

      Yes, hindsight probably helped.

  • (Score: 0) by Anonymous Coward on Tuesday October 29 2019, @07:15AM

    by Anonymous Coward on Tuesday October 29 2019, @07:15AM (#913168)

    I use Perl not so much for the code I write but for all the code I don't have to write.

    With Perl I can take advantage of other more hardworking and skillful people to write the bulk of the stuff in C/C++, document and support it (and also make it somewhat cross-platform - funnily Perl is more cross platform in practice[1] than Java since more OSes have Perl in the default install than Java).

    If your use case requires 90% of the stuff to be written by you (e.g. no existing perl libraries and built-ins that will help make your life easier) then you might wish to use a different language.

    Similar if your use case requires higher performance.

    That said some forms of ASM are often better than C++ in some of those cases...

    [1] also stuff like PAR allow you to generate executables for different platforms from the same perl source so that people don't have to install Perl, and in most cases those executables are smaller than a JVM and require fewer permissions to run/install.

  • (Score: 2) by JoeMerchant on Tuesday October 29 2019, @04:57PM (4 children)

    by JoeMerchant (3937) on Tuesday October 29 2019, @04:57PM (#913331)

    There are documented histories of huge programs written in

    Anything, recoded in anything else - if you don't get an increase in performance that's a damning indictment of the new language's performance potential.

    I took a 6 year developed project from C to C++ around about 1997, took about 6 months for the basic port, and lost about 30% "execution speed" while doing so, but this was the '90s, so during those 6 months equivalent cost computers accelerated at least 30% in execution speed. The real payoff was future development speed, mostly due to reusability of existing modules - that resulted in about a 2x speedup for future development, meaning the next 3 years implemented as many new features as the previous 6, which, for an R&D platform, was well worth it. Not to mention, the C++ GUI libraries came with "expected" UI elements like file selector dialogs which took less than an hour to implement, whereas the C GUI libraries just lacked them and it would take days to implement the equivalent.

    --
    🌻🌻 [google.com]
    • (Score: 2) by hendrikboom on Friday November 08 2019, @02:44PM (3 children)

      by hendrikboom (1125) Subscriber Badge on Friday November 08 2019, @02:44PM (#917867) Homepage Journal

      What's significant about the rewrite to Gambit Scheme is that they did not set out to rewrite their system.
      They added a scripting language, and, when maintenance was necessary, they found it easier to use the scripting language than to modify existing code. The rewrite was a consequence of day-by-day incremental improvements.

      • (Score: 2) by JoeMerchant on Friday November 08 2019, @03:03PM (2 children)

        by JoeMerchant (3937) on Friday November 08 2019, @03:03PM (#917878)

        The rewrite was a consequence of day-by-day incremental improvements.

        I liken this to "coral reef design" - layers upon layers built up incrementally. Any kind of change can lead to improvements, but coral reef designed software does tend to be quite difficult to work with. It takes much more discipline to build "Lego" software, discipline that's usually lacking in script language implementations. Not impossible, I use trac, trac is a great system built in mostly Python, but most Python projects I've interacted with started as a one trick demo nugget, which grew, like a coral reef, and somewhere between the 7th and 25th trick, they discovered that every subsequent trick is much harder than it could/should be - like each new trick gets coded almost from scratch. It was the same with my C project: hand coded optimal performance in every little function - but terrible reusability of existing code.

        --
        🌻🌻 [google.com]
        • (Score: 2) by hendrikboom on Friday November 08 2019, @11:50PM (1 child)

          by hendrikboom (1125) Subscriber Badge on Friday November 08 2019, @11:50PM (#918096) Homepage Journal

          In this project it looks more like they were removing and replacing layers of coral incrementally -- presumably the layers they had built years earlier.