Timeline for Should we "balance" the amount of codes between .h and .cpp?
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 23, 2017 at 12:40 | history | edited | CommunityBot | replaced http://stackoverflow.com/ with https://stackoverflow.com/ | |
| Mar 29, 2016 at 11:52 | comment | added | Basile Starynkevitch | I agree and I know that (I sometimes contribute to GCC). But I was talking about practical performance (of GCC & of Clang), while you are talking about standard legalese. | |
| Mar 29, 2016 at 11:51 | comment | added | MSalters | @BasileStarynkevitch: My point there wasn't about an actual implementation, I was taking the ISO perspective. From their perspective, #include <vector> does one thing, and that's adding vector to the symbol table of namespace std. This can be extremely fast as the user isn't allowed to specialize it. What mroe should ISO do to make life easy for the toolchain implementors? | |
| Mar 29, 2016 at 11:37 | comment | added | Basile Starynkevitch | @MSalters: I know that, but it is not the way that GCC or Clang/LLVM currently works. Feel free to contribute to them to add some compiler magic for C++ containers. | |
| Mar 29, 2016 at 11:25 | comment | added | MSalters | @gbjbaanb: It's the ISO C++ committee, literally a global organization. It is onl;y to be expected that their meetings are on average thousands of kilometers away. If you want to campaign for an ABI, don't start with Bjarne but with Microsoft. But note that your argument is a bit weak. There is no fundamental reason why vector has to be 10K lines. it could be one line, __magic vector, and still be conformant. | |
| Mar 29, 2016 at 7:49 | comment | added | Basile Starynkevitch | Yes, that are the issues. Contributing to standardization or to compiler implementation practically requires at least a half-time job. Do you have the time & resources for that? If you don't, perhaps try to respect the work of those who do... And I don't understand why an ABI would be a good thing... | |
| Mar 29, 2016 at 7:48 | comment | added | gbjbaanb | The committee doesn't meet anywhere near me. I was referring to modules support. I don't think standardising things like that would affect much legacy code at all, but easier compilation and "packaging" would make a huge difference. I did once try to explain why an ABI would be a good thing to Bjarne but he simply dismissed it as difficult to get the compiler makers to co-operate. | |
| Mar 29, 2016 at 7:42 | history | edited | Basile Starynkevitch | CC BY-SA 3.0 | added 219 characters in body |
| Mar 29, 2016 at 7:39 | comment | added | Basile Starynkevitch | @gbjbaanb: What are you referring to? BTW, you might consider helping the C++ committee (and perhaps becoming part of it), but that takes a lot of your time. Are you willing to spend it? I won't dare criticizing the C++ standard committee. It is a difficult job and they have a lot of legacy constraints. | |
| Mar 29, 2016 at 7:37 | comment | added | gbjbaanb | extremely disappointed the C++ committee doesn't want to look at the toolchain over obscure language features. | |
| Mar 29, 2016 at 7:23 | history | edited | Basile Starynkevitch | CC BY-SA 3.0 | added 128 characters in body |
| Mar 29, 2016 at 7:12 | history | edited | Basile Starynkevitch | CC BY-SA 3.0 | added 76 characters in body |
| Mar 29, 2016 at 7:07 | history | answered | Basile Starynkevitch | CC BY-SA 3.0 |