GCC Developers Look At Transitioning Their Codebase To C++11

[tildearrow]

Really? I figure std::chrono::system_clock::now() should be just a thin wrapper around it:

https://en.cppreference.com/w/cpp/ch...stem_clock/now

If you can quantify any significant overhead, do let us know.

Wow! Actually std::chrono::system_clock::now() was faster than my wrapper: (curTime being it)

~/projects/coder/build$ ./codertest  
clock_gettime: 0.312027334s
curTime: 0.342635608s
std::chrono::system_clock::now(): 0.334109103s

-wait... That's only when unoptimized Doing -O2 results in:

~/projects/coder/build$ ./codertest  
clock_gettime: 0.311301748s
curTime: 0.331342714s
std::chrono::system_clock::now(): 0.333109638s

Insignificant though...

phx::reply::post post << phx::reply::post::contents::hate_rationale(std::string("I dislike the namespacing syntax... (::)"));

[coder]

-wait... That's only when unoptimized Doing -O2 results in:

~/projects/coder/build$ ./codertest
clock_gettime: 0.311301748s
curTime: 0.331342714s
std::chrono::system_clock::now(): 0.333109638s

Cool. Thanks for letting us know.

Insignificant though...

phx::reply::post post << phx::reply::post::contents::hate_rationale(std::string("I dislike the namespacing syntax... (::)"));

Well, you can mitigate that using namespace aliases, the using keyword, typedefs, etc.

Furthermore, you can put your own symbols with private visibility in an anonymous namespace.

[AsuMagic]

Okay, so you mean manual deallocations. You can still use-after-free, with std::unique_ptr<>, but it's certainly a lot less likely.

We're not yet at the point of a true garbage-collected language, but I don't want that. If I want true garbage collection, I'll use something other than C++.

Yeah, that's what I meant.

Well... C++03 has initializer lists - just not if your struct/class has a constructor.

Right, I did not know.

Regarding the requirement of a space between template parameter brackets (i.e. "> >"), that's just silly. After the first time tripping over it, you just learn to put an extra pair of spaces inside your <>'s. Problem solved. It's not ideal, but I don't think it rises to the level of the rest of the items in your list.

Yeah, of course. It's just one of the absurd things of C++03 that were corrected in C++11.

I don't get your point about parent constructors - of course you can call constructors of your baseclasses! What C++11 adds is the ability for derived classes to forward baseclass constructors, or for constructors to explicitly call sibling constructors of the same type.

My bad, I thought it mattered for classes you inherit from too.

If I'm using an initializer list, then std::array<> forces me to redundantly specify the length as a template parameter.

Fair enough. In C++17 you can rely on std::array's template deduction guides. While that works for say

std::array a{1, 2, 3};

It's more of a pain for say a Vector2 class where you would have to do

std::array a{Vector2<float>{1, 2}, Vector2<float>{3, 4}, Vector2<float>{5, 6}};

instead of

std::array<Vector2<float>, 3>{{1, 2}, {3, 4}, {5, 6}};

There is no way to use deduction guides only partially, right?

Heh, you'll never be truly rid of macros. Just try writing assert() without using macros, to give one use case.

IKR. I did not mean that they allow getting rid of all macros, just that you can get rid of the #define SOME_CONSTANT 1234 abomination. Even though there's not much justification behind it compared to `const int something`, granted.

[pal666]

I generally wait ~5 years after a new C++ version before adopting it.

you are 5 years late

[pal666]

Doesn't matter that much for the subset GCC uses, and they need to rely on pretty old versions to be portable.

the whole point is to use better subset. and they can rely on previous gcc version to be portable

[pal666]

Mainly because these language over-consumers then just sit there blaming their tools if they ever have to port the codebase to a slightly more exotic platform with an older standard compiler.

what if exotic platform doesn't have c++ compiler at all? fix your compiler

[pal666]

I personally really dislike 'modern' c++ variations (Program in C++03 as much as i can when deciding to use C++ over C99), and it is sad to see software i use on a daily base are adopting lazyness over function.
Well time to fork i guess.

it seems every phoronix thread has to have some imbecile who knows language better that it's compiler devs. forks made by imbeciles are not viable

[pal666]

rust

isn't portable, it's llvm only. and that is c++14 already btw

[pal666]

I have no idea for most of them, but I am pretty sure that Microsoft tend to keep up with standards quite well

you are pretty wrong. msvc is the worst one. and it has improved recently, some years ago it was like separate language when every crossplatform codebase had to support non-standard prehistoric msvc
and for lulz msvc is still not fully c++98 (though they are getting close)

(AFAIK, they are already using modules in production

that's enterprise. they sell it asap even if it still has rough edges

from what I know - the module proposal is partly designed by them).

modules are jointly designed by all big 3 compiler devs

[pal666]

on my RHEL 6

current rhel is 8. gcc in current devtoolset is 8.3.1 https://developers.redhat.com/blog/2...prise-linux-7/