Announcement

Collapse
No announcement yet.

Facebook Has Been Working On C++ Modules Support For GCC

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by pal666 View Post
    [..]
    you could just leave your clueless thoughts to yourself.
    [..]
    well, i can tell you that you can't read english,
    [..]
    you fail to understand that c++ standard is different from other "standards"
    [..]
    Can you please stop being personal and be less of a dick when you have to explain why others are wrong (if by any chance they are)? Your attitude is one of the worst we could possibly find on the internet, you dirty little piece of shit. Whether you have some skills or not is completely irrelevant when you start attacking others. This means you are playing defensive or you have had a father who used to make you feel stupid even when you were right. You are not in a mental hospital though, so treat people with respect and you will be respected in turn. I'm sure you're not even 20 and you only have years of Turbo C++ in your background, nonetheless you pretend people should care about your words.

    Comment


    • #22
      Originally posted by kravemir View Post

      Wrong. Java and C# target completely different type of applications, than C++. They are oriented towards stability and safety. But, C++ is oriented towards performance.

      Java and C# is used mostly in business applications (ie. working with money and precious data,... ).

      C++ is used mostly for games, desktop applications, and parts of operating system (ie. desktop environment, data transformation tools and libraries,...)
      Incorrect.

      C++, C#, and Java are all General Purpose Programming Languages of a similar heritage that are trying to support roughly the same feature set as one another to the point where if you are competent in one you're 90% of the way there to the other 2. Just because they've found different niches doesn't mean that they're not competitors however. Both Java and C# have been used in research as systems programming languages with things like JavaOS and Singularity and certainly there are plenty of games done in C# (see the Unity Engine), but the reason that any of those 3 is used in their particular niche is as much for historical reasons as it is for functional ones. Java has a well earned reputation of being a memory hog (which is a problem still today) and the default application toolkit looked out of place and like crap everywhere, both of which help to explain it's minimal adoption for desktop applications or environments, whereas C# actually has very broad adoption under windows, and C++ is of course popular on the desktop because of Qt.

      Comment


      • #23
        Originally posted by Luke_Wolf View Post

        Incorrect.

        C++, C#, and Java are all General Purpose Programming Languages of a similar heritage that are trying to support roughly the same feature set as one another to the point where if you are competent in one you're 90% of the way there to the other 2. Just because they've found different niches doesn't mean that they're not competitors however. Both Java and C# have been used in research as systems programming languages with things like JavaOS and Singularity and certainly there are plenty of games done in C# (see the Unity Engine), but the reason that any of those 3 is used in their particular niche is as much for historical reasons as it is for functional ones. Java has a well earned reputation of being a memory hog (which is a problem still today) and the default application toolkit looked out of place and like crap everywhere, both of which help to explain it's minimal adoption for desktop applications or environments, whereas C# actually has very broad adoption under windows, and C++ is of course popular on the desktop because of Qt.
        I haven't said, that they are used exclusively in specific areas. But, these languages differ hugely in some aspects.

        For example, I would have never used C++ for custom development of business applications. Java has worse efficiency regarding resource utilization (cpu, memory), but it mostly doesn't matter, because Java pros overcome increased cost of hardware (developer time is expensive). And, the application has got usually only one production deployment / usage.

        On the other hand, there is SW, which is used on every desktop, and it doesn't make sense to pick something, which unnecessarily consumes my resources. I would alternative, which uses less resources.

        I don't say it's not possible to use these languages for different things. But, it's like using a hammer to dig a hole into ground, and a bulldozer to put a nail into wall...

        ​​​​

        Comment


        • #24
          Originally posted by pal666 View Post
          modules isn't part of c++20. modules is technical specification. so modules is part of modules ts. after ts is released and experience on using modules is gained, some kind of modules could become part of some future c++ standard. maybe it will be like modules ts, maybe it will be different

          you could just leave your clueless thoughts to yourself.
          modules do not try to replace c preprocessing. there were two competing proposals, one supports macros, one doesn't. current consensus is to do macro-less modules first and maybe add macros in the future. modules try to replace c++ preprocessing i.e. to avoid compiling same template definitions in each translation unit again and again, i.e. to make compile times faster and to avoid odr violations
          lack of modules support is a major drawback of c++
          So it does the same as part of what CPP does, but doesn't replace it. Exactly what I said...

          Comment


          • #25
            At least in C++ modularisation standardisation was strait forward. Happened even after more than 20 years, never to late . But in Java World, modularisation process faced strong opposition from Red Hat and IBM, for the reason, among the other things, that will break backward compatibility, delaying Java 9 release.

            JSR 376 is expected to provide a basis for Java Enterprise Edition 9, due in late 2018. Stark has his doubts, however. “The limitations in Jigsaw almost certainly prevent the possibility of Java EE 9 from being based on Jigsaw, as to do so would require existing Java EE vendors to completely throw out compatibility, interoperability, and feature parity with past versions of the Java EE specification.” Stark said that in some cases, the implementation of Jigsaw contradicts years of modular application deployment best practices already commonly employed by the ecosystem.
            Key design points of Jigsaw are predicated on a reductive approach to forward compatibility, Stark said. This works with modularizing Java itself but becomes “restrictive for broader use cases that application deployments have.”
            JEC participants say modularization will have adverse effects on compatibility and could lead to two worlds of Java development


            Comment


            • #26
              Originally posted by kravemir View Post

              Wrong. Java and C# target completely different type of applications, than C++. They are oriented towards stability and safety. But, C++ is oriented towards performance.

              Java and C# is used mostly in business applications (ie. working with money and precious data,... ).

              C++ is used mostly for games, desktop applications, and parts of operating system (ie. desktop environment, data transformation tools and libraries,...)
              It's obvious. Main competitor for C++ can be considered Rust lang, and not Java. Microsoft has developed his own Edge browser in C++, more precisely HTMLEdge layout engine. And not in C#.

              C/C++ vs D lang, Rust, FreePascal, native code generated, not managed.

              Comment


              • #27
                Originally posted by onicsis View Post
                At least in C++ modularisation standardisation was strait forward. Happened even after more than 20 years, never to late . But in Java World, modularisation process faced strong opposition from Red Hat and IBM, for the reason, among the other things, that will break backward compatibility, delaying Java 9 release.


                JEC participants say modularization will have adverse effects on compatibility and could lead to two worlds of Java development

                One main aim of C++ is to be a superset of C. Since the preprocessor is part of C, C++ will continue to support it, including #include. Compatibility-wise, I don't think it'd become a problem.

                For Java, I'm not so sure about the compatibility problems there. Probably on the platform side of things, I guess.

                Comment

                Working...
                X