Announcement

Collapse
No announcement yet.

Cairo Proposed To Become Part Of ISO C++

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

  • #31
    Originally posted by Illasera View Post
    Next thing you know, you will include "boost" as part of the standard
    lol, boost's purpose is to serve as a playground on the way to standard. and some boost libraries are already included in standard, and more willl come

    Comment


    • #32
      Originally posted by Ancurio View Post
      You can use offscreen rendertargers in memory and be completely OS agnostic (ie. pixman).
      not if you want hardware acceleration. and who doesn't, should keep his hands out of programming

      Comment


      • #33
        Originally posted by gigaplex View Post
        STL containers are not safe to pass across DLL boundaries without great care,
        it is only a problem of nonexistent abi on windows, and dlls also are not part of c++ standard, so it is out of scope anyway
        Originally posted by gigaplex View Post
        and are not designed to be inheritable, so they're often not practical to use.
        but it is an advantage. if you need something inheritable(very seldom need), use stl container in it's implementation. you could pass it across dll boundary as a bonus point.
        Last edited by pal666; 01-03-2014, 10:07 PM.

        Comment


        • #34
          Originally posted by pal666 View Post
          it is only a problem of nonexistent abi on windows, and dlls also are not part of c++ standard, so it is out of scope anyway
          It's a problem *everywhere* because C++ does not define an ABI. Toggle a compiler option and passing a std::vector can suddenly cause a crash.

          The C++ committee should focus on real problems, such as proper modules, defining an ABI, creating a test suite for C++ compilers instead of toying around with graphics rendering. It's a waste of everyone's time, since no sane developer is going to use a hypothetical std::graphics that will not be supported by half the compilers and will behave differently on the other half that claim support.

          Comment


          • #35
            Originally posted by BlackStar View Post
            It's a problem *everywhere* because C++ does not define an ABI.
            c does not define an abi either. but g++ on linux does and other compilers follow it
            Originally posted by BlackStar View Post
            Toggle a compiler option and passing a std::vector can suddenly cause a crash.
            Originally posted by BlackStar View Post
            example ?
            The C++ committee should focus on real problems, such as proper modules, defining an ABI, creating a test suite for C++ compilers instead of toying around with graphics rendering. It's a waste of everyone's time, since no sane developer is going to use a hypothetical std::graphics that will not be supported by half the compilers and will behave differently on the other half that claim support.
            committee researches modules among other things, why didn't you show to help, instead of whining ? nobody on the committee is getting paid for it.
            how many features of c++98 library, not supported by half the compilers, do you know ? like "nobody is using iostreams", or "nobody is using strings", or "nobody is using vectors"

            Comment


            • #36
              Originally posted by pal666 View Post
              not if you want hardware acceleration. and who doesn't, should keep his hands out of programming
              So all those people writing software that manipulates images on headless servers, for example on web servers, is written by people that shouldn't program in the first place, because you can't use hardware acceleration in that environment?

              Comment


              • #37
                Originally posted by pal666 View Post
                it is only a problem of nonexistent abi on windows, and dlls also are not part of c++ standard, so it is out of scope anyway

                but it is an advantage. if you need something inheritable(very seldom need), use stl container in it's implementation. you could pass it across dll boundary as a bonus point.
                No, you cannot use STL containers via composition across a DLL barrier either. You need to use the pimpl idiom to maintain ABI compatibility. Which is precisely what Qt does.

                Comment


                • #38
                  Originally posted by pal666 View Post
                  iso c targets all systems including windows, while posix doesn't
                  That is why I think it was mistake.

                  Comment


                  • #39
                    Originally posted by pal666 View Post
                    not if you want hardware acceleration. and who doesn't, should keep his hands out of programming
                    How can you hardware accelerate drawing into file?

                    Comment


                    • #40
                      Originally posted by LightBit View Post
                      How can you hardware accelerate drawing into file?
                      Easily? Blitting that offscreen gpu-accelerated buffer to a file is little different from blitting it into a window.

                      Comment

                      Working...
                      X