Cairo Proposed To Become Part Of ISO C++

[pal666]

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

[pal666]

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

[pal666]

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

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.

[BlackStar]

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.

[pal666]

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

Toggle a compiler option and passing a std::vector can suddenly cause a crash.

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"

[Vim_User]

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?

[gigaplex]

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.

[LightBit]

iso c targets all systems including windows, while posix doesn't

That is why I think it was mistake.

[LightBit]

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?

[curaga]

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.