Is there a good source of information on C++11 standard support in libc++? Its web site says 98% of the standard is supported but I'd like to know what features the other 2% are.
Something similar to this list for libstdc++ would be nice:
http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011
Edit: From Howard Hinnant's comment below:
The chart is outdated already. I should update it or take it down. The only thing unimplemented in libc++ right now is 20.7.2.5 shared_ptr atomic access [util.smartptr.shared.atomic]. And I hope to get that done this weekend. [atomics] is there now. Oh, quick_exit is missing. I'm going to let the C library implement that.
The most recent and detailed information is already linked from the front page (doesn't mean it is new enough ☺).
The only major missing piece of C++'0x support is <atomic>.
Here is a by-chapter breakdown of what is passing tests and what isn't.
We can see that 76% of <atomic>, 3% of "[language.support]" and 2% of "[utilities]" are missing.
I don't think there would be more updated/detailed break down like the libstdc++ one.
A frustrating side note on std::quick_exit() and std::at_quick_exit() functions. They are still unimplemented in macOS's libc even after several years. Also there is a possible vulnerability in the C++ standard, where it states you can safely call std::quick_exit() from a signal handler, but it doesn't state the functions that are registered by std::at_quick_exit() must also meet the same requirements a regular signal handler does. I believe that might be the reason behind why those functions are not implemented yet.
Related
MSVC 16.6 in C++20 mode removes the result_of that was removed in C++20 standard.
I am all for doing the morally correct thing, but many 3rd party libraries(example) I use fail.
Sometimes MSVC enables users to define a define so that removed features are still enabled.
Is there an option to do that for result_of?
I have tried _HAS_FEATURES_REMOVED_IN_CXX20 and it seems to work, but the fact that macro starts with _ scares me, it suggests it may be internal MSVC mechanism and not something users should set.
Defining _HAS_DEPRECATED_RESULT_OF and _SILENCE_CXX17_RESULT_OF_DEPRECATION_WARNING should more granularly restore result_of and turn off its deprecation warning.
_HAS_FEATURES_REMOVED_IN_CXX20 and _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS should do the same for all C++17 features retired in C++20.
Given past history, these "deprecation overrides" should be relatively safe to use now and for some time coming. Below is an older quote (about VS 2017) from an MS sanctioned blog.
5. (Important!) It’s very likely that you’ll encounter source breaking changes in third-party libraries that you can’t modify (easily or at all). We try to provide escape hatches so you can restore removed features or silence deprecation warnings and get on with your work, but first, please report such issues to the relevant library maintainers. By helping them update their code, you’ll help many more C++ programmers just like you.
As used in this answer, I'm looking for a C++11 compatible code for the same but the usage of std::quoted prevents me from achieving that. Can anyone suggest an alternative solution?
I give my answer assuming that you expect to find a generic approach to handle such situations. The main question that defines the guideline for me is:
"How long am I supposed to maintain this code for an older compiler version?"
If I'm certain that it will be migrated to the newer toolset along with the rest of the code base (even though in a few years time, but it will inevitably happen), then I just copy-paste implementation from the standard headers of the next target version of my compiler and put it into namespace std in a separate header within my code base. Even though it's a very rude hack, it ensures that I have exactly the same code version as the one I'll get after migration. As I start using newer (in this case C++14-compatible) compiler, I will just remove my own "quoted.h", and that's it.
Important Caveat: Barry suggested to copy-paste gcc's implementation, and I agree as long as the gcc is your main target compiler. If that's not the case, then I'd take the one from your compiler. I'm making this statement explicitly because I had troubles when I tried to copy gcc's std::nested_exception into my code base and, having switched from Visual Studio 2013 to 2017, noticed several differences. Also, in the case of gcc, pay attention to its license.
If I'm in a situation where I'll have to maintain compatibility with this older compiler for quite a while (for instance, if my product targets multiple compiler version), then it's more preferable first of all to look if there's a similar functionality available in Boost. And there is, in most cases. So check out at Boost website. Even though it states
"Quoted" I/O Manipulators for Strings are not yet accepted into Boost
as public components. Thus the header file is currently located in
you are able to use it from "boost/detail". And, I strongly believe that it's still better than writing your own version (despite the advice from Synxis), even though the latter can be quite simple.
If you're obliged to maintain the old toolset and you cannot use Boost, well...then it's maybe indeed worth thinking of putting your own implementation in.
According to the gcc docs on extended assembler:
You should only use read-write operands when the constraints for the operand [...] allow a register.
This seems to be to be pretty unambiguous: You cannot use +m for an output.
However, I've seen it being done a number of times. In fact, Linus Torvalds is on record as saying
The gcc docs are secondary. They're not updated, they aren't correct, they don't reflect reality, and they don't matter. The only correct thing to use is "+m" for things like this
I don't want to use +m if the compiler is going to end up screwing up my code. And even examining the output asm to see if it is working doesn't mean that tomorrow when I change some seemingly unrelated thing it will still work. Or that it will still work when I get the next update to gcc.
If the docs are right and I can't depend on this working correctly, I want to know that so I can pursue other options (most of which are unpleasantly painful). If the docs are wrong, please let me know how to get them corrected.
As it turns out, the problem is the docs (see the email). In case the link dies:
That part of the docs has been wrong for a while. The doc was corrected for 4.8, but it was wrong for earlier versions too.
Since I am using rubenvb's x64 compiler which reports version 4.7.2, that's the version of the docs I was reading. However, the actual code checkin was in 2004, so I'm feeling pretty confident that change is included in the code I'm running.
Please, don't cite what Linus had to say on gcc in 2001 (!), when the gcc/egcs rift was just starting to heal (that ended around 2000). Yes, the handling of asm restrictions was a horrendous mess in that timeframe (Alan Cox was sort of head of cleaning the mess up, as the compiler was starting to really heed the restrictions, I added a few patches to that).
The current GCC is a completely different beast, it has undergone extensive reengineering inside.
Believe the documentation, don't write bad constraints. They are constraints, if you lie to the compiler, it might by sheer bad luck select arguments that do work most of the time. It will break some day.
If you have an example that shows that writing an illegal constraint is accepted (that the compiler can check!), please report it.
If you have an example of a constraint that the compiler doesn't consider, please report it.
If you have code that does stuff that might (or not) work depending on options the compiler can legally take according to what ypu told it, and that sometimes works and sometimes it doesn't, OK, chalk it up to your own fault and wise up. Do not lie to your compiler, it will exact bloody revenge.
I've found an odd inconsistency between Rcpp which compiled with and without -std=c++0x.
Consider the expression
Function data_frame("data.frame");
GenericVector a;
a.push_back("17");
return data_frame(a, _["stringsAsFactors"]=0);
(ed. note: coercion to DataFrame in Rcpp actually thunks down to the R function, but doesn't allow the user to set that flag.)
In "old" C++ (w/o -std=c++0x set) this code works. In modern C++ (w/ -std=c++0x set), this fails, saying "cannot coerce class "pairlist" into a data.frame".
Obviously, this isn't the end of the world: I just don't use any newer features. However, I confess to being totally at a loss as to what causes this difference, and how to work around it without throwing C++11 away. Any ideas, anyone?
Code targetting features of the new standard was written in Rcpp about 2 years ago.
But then, later we realized that CRAN did not accept the -std=c++0x flag for gcc (or equivalent flags for other compilers), and forcing the C++99 standard and therefore we cannot realistically use it.
Consequently we pretty much don't maintain the C++11 aware code. That's a shame because we'd really like to, but we prefer the exposure of being accepted in CRAN. Since we don't maintain, there are probably many things that don't work as they should.
This particular issue is probably easy to fix. And this will happen as soon as we get the green light on using C++11.
We love C++11 and cannot wait to use it. But we cannot use it in uploads to CRAN (as per a decree of the CRAN maintainers who consider C++11 "non portable" at this point -- please complain to them, not us, of that irks you).
Consequently it is currently "barred". There is a bit of detection in RcppCommon.h and we define HAS_CXX0X. But we haven't really written code for this, as we can't (yet) per the previous paragraph.
So if you found a bug, please do us the favor and report it where request follow-ups to be sent: the rcpp-devel list. Reproducible is good, patches even better :)
I know that E&C is a controversial subject and some say that it encourages a wrong approach to debugging, but still - I think we can agree that there are numerous cases when it is clearly useful - experimenting with different values of some constants, redesigning GUI parameters on-the-fly to find a good look... You name it.
My question is: Are we ever going to have E&C on GDB? I understand that it is a platform-specific feature and needs some serious cooperation with the compiler, the debugger and the OS (MSVC has this one easy as the compiler and debugger always come in one package), but... It still should be doable. I've even heard something about Apple having it implemented in their version of GCC [citation needed]. And I'd say it is indeed feasible.
Knowing all the hype about MSVC's E&C (my experience says it's the first thing MSVC users mention when asked "why not switch to Eclipse and gcc/gdb"), I'm seriously surprised that after quite some years GCC/GDB still doesn't have such feature. Are there any good reasons for that? Is someone working on it as we speak?
It is a surprisingly non-trivial amount of work, encompassing many design decisions and feature tradeoffs. Consider: you are debugging. The debugee is suspended. Its image in memory contains the object code of the source, and the binary layout of objects, the heap, the stacks. The debugger is inspecting its memory image. It has loaded debug information about the symbols, types, address mappings, pc (ip) to source correspondences. It displays the call stack, data values.
Now you want to allow a particular set of possible edits to the code and/or data, without stopping the debuggee and restarting. The simplest might be to change one line of code to another. Perhaps you recompile that file or just that function or just that line. Now you have to patch the debuggee image to execute that new line of code the next time you step over it or otherwise run through it. How does that work under the hood? What happens if the code is larger than the line of code it replaced? How does it interact with compiler optimizations? Perhaps you can only do this on a specially compiled for EnC debugging target. Perhaps you will constrain possible sites it is legal to EnC. Consider: what happens if you edit a line of code in a function suspended down in the call stack. When the code returns there does it run the original version of the function or the version with your line changed? If the original version, where does that source come from?
Can you add or remove locals? What does that do to the call stack of suspended frames? Of the current function?
Can you change function signatures? Add fields to / remove fields from objects? What about existing instances? What about pending destructors or finalizers? Etc.
There are many, many functionality details to attend to to make any kind of usuable EnC work. Then there are many cross-tools integration issues necessary to provide the infrastructure to power EnC. In particular, it helps to have some kind of repository of debug information that can make available the before- and after-edit debug information and object code to the debugger. For C++, the incrementally updatable debug information in PDBs helps. Incremental linking may help too.
Looking from the MS ecosystem over into the GCC ecosystem, it is easy to imagine the complexity and integration issues across GDB/GCC/binutils, the myriad of targets, some needed EnC specific target abstractions, and the "nice to have but inessential" nature of EnC, are why it has not appeared yet in GDB/GCC.
Happy hacking!
(p.s. It is instructive and inspiring to look at what the Smalltalk-80 interactive programming environment could do. In St80 there was no concept of "restart" -- the image and its object memory were always live, if you edited any aspect of a class you still had to keep running. In such environments object versioning was not a hypothetical.)
I'm not familiar with MSVC's E&C, but GDB has some of the things you've mentioned:
http://sourceware.org/gdb/current/onlinedocs/gdb/Altering.html#Altering
17. Altering Execution
Once you think you have found an error in your program, you might want to find out for certain whether correcting the apparent error would lead to correct results in the rest of the run. You can find the answer by experiment, using the gdb features for altering execution of the program.
For example, you can store new values into variables or memory locations, give your program a signal, restart it at a different address, or even return prematurely from a function.
Assignment: Assignment to variables
Jumping: Continuing at a different address
Signaling: Giving your program a signal
Returning: Returning from a function
Calling: Calling your program's functions
Patching: Patching your program
Compiling and Injecting Code: Compiling and injecting code in GDB
This is a pretty good reference to the old Apple implementation of "fix and continue". It also references other working implementations.
http://sources.redhat.com/ml/gdb/2003-06/msg00500.html
Here is a snippet:
Fix and continue is a feature implemented by many other debuggers,
which we added to our gdb for this release. Sun Workshop, SGI ProDev
WorkShop, Microsoft's Visual Studio, HP's wdb, and Sun's Hotspot Java
VM all provide this feature in one way or another. I based our
implementation on the HP wdb Fix and Continue feature, which they
added a few years back. Although my final implementation follows the
general outlines of the approach they took, there is almost no shared
code between them. Some of this is because of the architectual
differences (both the processor and the ABI), but even more of it is
due to implementation design differences.
Note that this capability may have been removed in a later version of their toolchain.
UPDATE: Dec-21-2012
There is a GDB Roadmap PDF presentation that includes a slide describing "Fix and Continue" among other bullet points. The presentation is dated July-9-2012 so maybe there is hope to have this added at some point. The presentation was part of the GNU Tools Cauldron 2012.
Also, I get it that adding E&C to GDB or anywhere in Linux land is a tough chore with all the different components.
But I don't see E&C as controversial. I remember using it in VB5 and VB6 and it was probably there before that. Also it's been in Office VBA since way back. And it's been in Visual Studio since VS2005. VS2003 was the only one that didn't have it and I remember devs howling about it. They intended to add it back anyway and they did with VS2005 and it's been there since. It works with C#, VB, and also C and C++. It's been in MS core tools for 20+ years, almost continuous (counting VB when it was standalone), and subtracting VS2003. But you could still say they had it in Office VBA during the VS2003 period ;)
And Jetbrains recently added it too their C# tool Rider. They bragged about it (rightly so imo) in their Rider blog.