- initialization by std::move(param) - 5 Updates
- Link statically with two versions of the same library - 1 Update
| quanzhou <anhonghe@gmail.com>: Mar 16 11:34PM -0700 Hi Experts, I have a question, for type like: struct A { int num = 0; std::string text {}; }; A a{13, "hi"}; A b = std::move(a); after this, what is the value of a.num? I know most probable answer is 13, since "move of builtin types is copy", but does standard document give any guarantee that b.num are for sure read-accessed? Or unspecified? Thanks, Anhong |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 17 09:26AM +0100 Am 17.03.2023 um 07:34 schrieb quanzhou: > A b = std::move(a); > after this, what is the value of a.num? > I know most probable answer is 13, since "move of builtin types is copy", but does standard document give any guarantee that b.num are for sure read-accessed? The implicit move moves only moveable objects. b.num is still 13. Implicit moves are only generated if all of the following methods are not given: there are no user-declared copy constructors; there are no user-declared copy assignment operators; there are no user-declared move assignment operators; there is no user-declared destructor. (from en.cppreference.com) |
| "Öö Tiib" <ootiib@hot.ee>: Mar 17 03:44AM -0700 On Friday, 17 March 2023 at 08:34:47 UTC+2, quanzhou wrote: > after this, what is the value of a.num? > I know most probable answer is 13, since "move of builtin types is copy", but does standard document give any guarantee that b.num are for sure read-accessed? > Or unspecified? The num is 13, text is in valid but unspecified state. Again one such place where standard could require that text is empty without any harm done to performance of anything as in lot of existing implementations the text member is empty. |
| Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Mar 17 05:45AM -0700 On Friday, 17 March 2023 at 06:34:47 UTC, quanzhou wrote: > after this, what is the value of a.num? > I know most probable answer is 13, since "move of builtin types is copy", but does standard document give any guarantee that b.num are for sure read-accessed? > Or unspecified? You're abusing the system by accessing a.num after the move, except for the purpose of destroying a. However it's not C-style "undefined behaviour". std::move converts an l-value to an r-value, which esnures that the move constructor, if it exists, is called. That's all it does. Whilst for commonsense purposes you can say "a is invalid because of the std::move", this isn't actually what happens. |
| Andrey Tarasevich <andreytarasevich@hotmail.com>: Mar 17 02:17PM -0700 On 03/16/23 11:34 PM, quanzhou wrote: > after this, what is the value of a.num? > I know most probable answer is 13, since "move of builtin types is copy", but does standard document give any guarantee that b.num are for sure read-accessed? > Or unspecified? Yes, it is guaranteed to be 13 post-move. The language guarantees that move-semantics for scalar types boils down to classic copy-semantics. -- Best regards, Andrey |
| Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Mar 17 10:20AM -0700 On Wednesday, March 15, 2023 at 11:22:29 PM UTC, Frederick Virchanza Gotham wrote: > I bet I can get this working. I've prefixed all the symbols exported from the wxGTK3 library with '[b]wxGTK3_[/b]', and I've prefixed all the symbols exported from the wxX11 library with '[b]wxX11_[/b]', as follows: [code] #!/bin/sh echo - - - - Deleting all files rm -rf *.o *.a echo - - - - Copying intact .a files /usr/local/lib/wx/config/gtk3-unicode-static-3.2 --libs all | tr ' ' '\n' | sort | uniq | grep "\.a$" | xargs -i -r -n1 cp "{}" ./ echo - - - - Extracting .o files from .a files find -name "*\.a" | xargs -i -r -n1 ar -x "{}" echo - - - - Deleting all .a files rm -rf *.a echo - - - - Compiling an exhaustive list of exported symbols nm *.o | grep -E "^[0-9a-f]{16} T " | cut -d ' ' -f 3 | sort | uniq > exported_symbols.txt echo - - - - Adding a prefix to all the exported symbols find -name "*\.o" | while read objfile; do cat exported_symbols.txt | xargs -i -r -n1 objcopy --redefine-sym {}=wxGTK3_{} ${objfile}; done [/code] Next in the [b]Makefile[/b] for my program, I compile all the GUI-related files twice, once for wxGTK3 and once for wxX11: [code] wxwidgets/%.cpp.x11.o: wxwidgets/%.cpp $(wildcard wxwidgets/*.h wxwidgets/*.hpp) $(CXX) $(CXXFLAGS) $(CPPFLAGS) -c $< -o $@ $(wxwidgets_cxxflags_x11) cat wxwidgets/x11/exported_symbols.txt | while read symbol; do objcopy --redefine-sym $${symbol}=wxX11_$${symbol} $@; done wxwidgets/%.cpp.gtk3.o: wxwidgets/%.cpp $(wildcard wxwidgets/*.h wxwidgets/*.hpp) $(CXX) $(CXXFLAGS) $(CPPFLAGS) -c $< -o $@ $(wxwidgets_cxxflags_gtk3) cat wxwidgets/gtk3/exported_symbols.txt | while read symbol; do objcopy --redefine-sym $${symbol}=wxGTK3_$${symbol} $@; done [/code] When I link my program together, the object files seeking symbols from wxX11 should find them all prefixed with "wxX11_" in the altered wxX11 static library files, and the object files seeking symbols from wxGTK3 should find them all prefixed with "wxGTK3_" in the altered wxGTK3 static library files. I might have this finished today. It's taking ages to rename all the symbols in static library files -- it's still not finished doing that. So the finished product will be an executable file which links dynamically with glibc, but has no other dependencies. You'll be able to run it in 3 modes: (1) Simple console program (2) GUI program using GTK3 (on top of either X11 or Wayland) (3) GUI program using X11 directly |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment