No announcement yet.

C++17 Is Complete, Work On C++20 Is Getting Underway

  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by Kemosabe View Post

    So you blame them both to visit (phoronix) forum flaming abt programming languages? You sir, are a troll!

    ​​​​​​I'm giving you the benefit of the doubt by assuming English isn't your native language. Otherwise, i don't know how I'm supposed to interpret your response.
    I've been on these forums for years (so i didn't "blame then both to visit (phoronix) forum" and i didn't participate in any flaming.
    Now, it's possible i misinterpreted your post to which i responded. I read this section:

    Then some newcomer hipster comes (often without in-depth knowledge of anything with the need to distinguish himself) and tells them it is all unnecessary deprecated and bad ...
    as applying to anyone who thinks the current paradigms are insufficient. That you call such folks "hipsters" adds to my concern that we have a language barrier issue.


    • #32
      Originally posted by patstew View Post
      If you have to support old compilers, you have to write C++ without using the new features - it's unfortunate for you but I'm not sure what benefit you'd get by C++ not being updated for anyone else either? The problem you mention above seems like it would be fixed by just compiling everything on a given platform in the same way.
      Leaving aside the embedded DSP, both of the other platforms I mentioned are current and supported. As you might know, enterprise OS distros tend to lag, a couple years. But the Android NDK release is just weeks old!

      Again, the problem with the frequent standards updates that add lots of new features is that they tempt library authors into using them, leaving everyone who's not on the bleeding edge in the dust. In the world of real products with real customers that expect reliability and support, bleeding edge isn't an option.

      And, as I also mentioned, there are costs associated with transitioning. With a large, real-world codebase, it's often not as simple as updating your compiler and flipping a switch to enable the new standard features. Because of the issues it tends to cause, organizations become more wary of switching to the new standard. We almost had to abort our C++11 transition, when we encountered the incompatible template instantiation problems I mentioned above!

      These concerns might not apply to many of you, but you're just wrong if you're arguing that they're not real issues. By alienating a set of its users, the C++ standards committee risks doing more harm than good to the user community, as a whole.
      Last edited by coder; 26 March 2017, 07:55 PM.


      • #33
        Originally posted by garegin View Post
        For decades, people were stuck with text based shells.

        You make that sound like it’s a bad thing...


        • #34
          Originally posted by coder View Post
          I've used Boost for about 14 years. Most parts of it are pretty great. Many of the good improvements in the language have come from limitations encountered by its authors, and I agree with the idea of migrating some of its most popular and stable facilities into the standard library.

          But I firmly reject the idea that it's a high virtue to write code with no external library dependencies. Yes, you want to keep the number of dependencies low, but it's not worth bloating up the standard just so you can feel "clean". Boost proves that high-quality open source libraries are more than adequate at meeting user needs. All the standard really needs to do is make sure the library authors are unimpeded.
          You are right except about using boost. Boost is experimental and unstable. It is not something you should ever rely on in published code.


          • #35
            Originally posted by ldo17 View Post

            You make that sound like it’s a bad thing...
            Emm. I read the article and it's talking about use of confusing aliases. Nothing to do with the advantages of not scraping text from an output. BTW this issue of text based shells is mentioned in the Unix Hater's Handbook.


            • #36
              Originally posted by mmstick View Post
              This is complete nonsense. The latest Rust nightly from today still compiles code written two years ago for the 1.0
              lol. 2 years ago !!!11111


              • #37
                Originally posted by cl333r View Post
                Great, now C++ is worth a book 900 pages instead of 700.
                so, how does it compare to java or c#? remember, it does not compete with languages for kids


                • #38
                  Originally posted by coder View Post
                  As a practicing C++ programmer, I really fear they're going to keep adding stuff until it becomes unlearnable and unimplementable. C++ already has a learning curve years long, and that's a big impediment to hiring developers.
                  practicing c++ programmers are expected to be better educated. "they" are adding stuff with explicit goal of making language easier to learn. and any non-trivial stuff is added only after working implementation
                  Originally posted by coder View Post
                  IMO, they should just fix stuff that's broken (i.e. not fully usable as intended or as people are trying to use it). Std libraries should focus on portability, abstract data types, and fundamental algorithms.
                  imo if you have no idea what are they doing, you shouldn't give you valuable advice
                  Originally posted by coder View Post
                  And 2D graphics has a scope far too large, and it's difficult to do in a truly one-size-fits all fashion. Another thing that makes it a poor candidate for ISO standardization is the likelihood that you get everything right in the standard. They'll have to do lots of bug-fixing and cleanup. Industry consortia like Kronos are much better vehicles, for things of this sort.
                  competitors(java and c#) have 2d graphics. c++ users(not you, but there are several millions of not you) are asking for 2d graphics. they are not doing one size fits all, they are standardising cairo api. and what makes your think kronos standard will magically become better than iso c++? at least iso c++ has to be implemented by all compiler vendors


                  • #39
                    Originally posted by coder View Post
                    It's not about agreeing whether feature XYZ is an improvement, it's about whether it offers enough benefit to introduce incompatibilities in code.
                    people much smarter than you are making sure that there will be no incompatibilities introduced
                    Originally posted by coder View Post
                    I have already run into a library that I can't use on a particular platform, because its compiler doesn't yet support some of the C++17 feature the author decided to use.
                    think of it as you found library written in rust without support for your platform. or like you didn't find library. compatibility does not work like that, it only allows you to compile old code with new compiler
                    Originally posted by coder View Post
                    We can both agree on ways that a feature could be improved upon, and still disagree on whether it should be added to the language.
                    no, we can't. if you don't like feature - don't use it, don't use new language version, or don't use language. go use cobol
                    Originally posted by coder View Post
                    As for std::byte, there's already uint8_t, and I fail to see the value in pretending that it can't be treated as a signed or unsigned integer.
                    byte does not allow arithmetic. regardless of you failures, new enum in std namespace will not make your life harder
                    Originally posted by coder View Post
                    And if you like Cairo, great - why not keep using Cairo? Why bloat up the standard with it?
                    why bloat your post with bullshit ideas that library addition can bloat standard? competing language have orders of magnitude larger standard libraries. and you can't use cairo because it is not in standard - you can't depend on it. besides, random libraries usually have shitty apis from c++ pov
                    Originally posted by coder View Post
                    There are two major downsides to putting it in the C++ standard. First, it'll inevitably have shortcomings and bugs
                    everything inevitably has shortcomings and bugs. it is not reason to not put into standard
                    Originally posted by coder View Post
                    , which will push library developers to adopt C++23 features, restricting the usability of their libraries on platforms that aren't at the bleeding edge.
                    you have to fix your shitty platform instead of crying. btw, does your shitty platform suport cairo?
                    Originally posted by coder View Post
                    Second, it further raises the bar for any platform that wants to provide a standards-conformant C++ implementation.
                    but it lowers the bar for people who want to do 2d graphics in c++. you see, standard is made to help c++ users, not to help some shitty platforms. btw standard will describe implementation of cairo wrapper, so any shitty platform with cairo could copy-paste it and get standards-conforming implementation.
                    Originally posted by coder View Post
                    I already have to maintain support for one C++ code base on a DSP without a fully-C++11 conformant compiler,
                    nobody cares. nobody is going to stop because of you. you have shitty platform - you will live with your shit. everyone else will move forward. next time select platform with proper gcc or llvm port
                    Originally posted by coder View Post
                    The C++ standards committee should not be trying
                    coach experts should not be trying to think, to avoid overloading of brain
                    Originally posted by coder View Post
                    They should be
                    do you know that participation in committee is free for you? why don't you move your ass and join?
                    Last edited by pal666; 27 March 2017, 03:50 PM.


                    • #40
                      Originally posted by hansg View Post
                      For what it's worth, I agree. It's nice(?) that we now have a binary type that does not support certain math operations - but you know what, you can't use it to implement something like compress() because that _will_ need those math operations internally.
                      first, maybe your compress will need, but my wouldn't. btw, why does your compress need multiplication and division? second, you should think more about functions like memcpy or memcmp (it takes void * and void can do even less than byte)
                      Originally posted by hansg View Post
                      uint8_t would have been more than enough.
                      if uint8_t is enough for you, nobody is forbidding you to use it
                      Originally posted by hansg View Post
                      Moreover, I would like a rule to state that undefined behaviour, _if detected by the compiler_, must actually be an error condition, rather than an excuse to let the optimizer go wild.
                      it does not work like that. program with ub is not c++ program. c++ compiler expects c++ program from you, so he assumes that there will be no ub in it(because some codepath will never be taken at runtime for example). and that assumption is what allows him to generate better code
                      Originally posted by hansg View Post
                      C++ would be better off dropping C compatibility completely, except for those bits that allow it to interoperate with a library written in C.
                      i.e. except all c bits, because all c bits can be found in c library headers
                      Originally posted by hansg View Post
                      At least that would open the door towards fixing or deprecating the worst parts of the C standard library, and remove at least some warts on the language.
                      don't forget that all supported c bits are used by non-c c++ code somewhere