<hkaiser>
Yorlik: bulds for me, what error do you see?
<Yorlik>
C:\__A\Arc_Sb\_INSTALL\hpx\5a221c1205dcbe92f8cf9c5c361b9562e3f75ea5\RelWithDebInfo\include\hpx\serialization\access.hpp(71): error C2338: No serialization method found
<Yorlik>
C:\__A\Arc_Sb\_INSTALL\hpx\5a221c1205dcbe92f8cf9c5c361b9562e3f75ea5\RelWithDebInfo\include\hpx/serialization/access.hpp(196): note: see reference to class template instantiation 'hpx::serialization::serialize_non_intrusive<T,void>' being compiled
<Yorlik>
with
<Yorlik>
[
<Yorlik>
T=std::variant<int,double,std::string>
<Yorlik>
]
<Yorlik>
Woops - that was a bit long - sorry
<hkaiser>
does that test compile for you?
<Yorlik>
That was from the test
<hkaiser>
could it be that you have some stale generated header files ?
<hkaiser>
clean your build dir, perhaps?
<hkaiser>
Yorlik: also, what VS do you use?
<Yorlik>
I'll kill it all.
<Yorlik>
2019 latest
<hkaiser>
me too
shahrzad has quit [Ping timeout: 260 seconds]
<Yorlik>
Should I rebuild HPX too, just to be safe?
<hkaiser>
Yorlik: I'm sure you should do that, that will regenerate the headers, so please reconfigure hpx
<Yorlik>
OK - I'll clean it all
<hkaiser>
Yorlik: that explains why it didn't build for you
<Yorlik>
OK - restarting with a fully clean slate
<Yorlik>
install, build, all, ...
* Yorlik
wants a build cluster
<Yorlik>
hkaiser: It stil refuses to build the test. I deleted the entire build directory and install directory and double checked the git status and commit hashes..
<Yorlik>
I used this commit: 5a221c1205dcbe92f8cf9c5c361b9562e3f75ea5
diehlpk has joined #ste||ar
<Yorlik>
I wonder if any CMake Variables I use on my HPX build do something
<Yorlik>
It's built with standard 2017 like always.
<Yorlik>
OOOH
<Yorlik>
HPX_HAVE_CXX17_STD_VARIANT
<diehlpk>
hkaiser, PowerTiger is cool!
<diehlpk>
I could build Octotiger on Daint in one hour
* Yorlik
slaps hkaiser a bit with a big'n fat HPX_HAVE_CXX17_STD_VARIANT
<Yorlik>
It compiles now - lol
ahkeir1 has quit [Quit: Leaving]
<hkaiser>
Yorlik: ok, what did I do?
<Yorlik>
Not tell me I need to define c ertain Macro
<hkaiser>
diehlpk: sorry, I missed the call
<hkaiser>
Yorlik: you shouldn't need to do that
<hkaiser>
cmake should define it for you
<Yorlik>
Well - I did and now it compiles
<diehlpk>
hkaiser, Was a short one
<hkaiser>
grrr, why did it work for me, then?
<hkaiser>
Yorlik: HPX_HAVE_CXX17_STD_VARIANT is defined by a feature test
<Yorlik>
However hkaiser - thanks a ton for the speedy fix - I now just need to fuigure out what's up with the strings in my variant
<hkaiser>
Yorlik: I will check tomorrow what went wrong, then you don't need to define that macro anymore
<Yorlik>
I had to put it in the source / CMake to activate the code in variant.hpp
<Yorlik>
NP
<hkaiser>
strange
<Yorlik>
I am still a bit irritated by the strings not being serialized, but I'll do some more checks to be sure the error is not on my side
<hkaiser>
Yorlik: hmmm, I'll try to check that tomorrow as well
<Yorlik>
That would be great, because the numbers get transmitted correctly in my vector<std::variant<double, int, std::string>>
<hkaiser>
Yorlik: ok, so this vector of variants does not properly serialize strings?
<Yorlik>
Yes
<Yorlik>
It is the container for my dynamic variables given to the custom message handler
<Yorlik>
The message can take a variable number of arguments of variable type and transmit them to a message handler - messages can have several custom defined handlers and thus need dynamic argument lists
<hkaiser>
ok, I forced it to use boost::filesystem
<hkaiser>
let me recompile and check
<Yorlik>
It is probably a simple appending of .generic_string() or a similar function
<Yorlik>
I did this and it compiled - not sure about the runtime behavior ofc.
<Yorlik>
Why did yours compile? Did you override filesystem in your compile somehow?
<hkaiser>
yes, I was forcing it to use boost filesystem in any case
<hkaiser>
fixing things right now
<Yorlik>
:)
<hkaiser>
Yorlik: for now you can add a -DHPX_FILESYSTEM_WITH_BOOST_FILESYSTEM_COMPATIBILITY=On while compiling HPX
<hkaiser>
that will make it fall back to boost::filesystem
<Yorlik>
Allright. Thanks !
<Yorlik>
It might be that my hack just works depending what strings you use.
<hkaiser>
also, see #4450
<Yorlik>
Do you want to to make an issue to have it locked or did you fix the surce of the problem already?
<Yorlik>
OK - checking
DragonMain has quit [Remote host closed the connection]
<Yorlik>
hkaiser: I added the three lines to your PR
<Yorlik>
Or do you want me to make an extra iossue?
<hkaiser>
no, that should solve the problem
<hkaiser>
thanks
<Yorlik>
OK
Hashmi has quit [Quit: Connection closed for inactivity]
iti has quit [Ping timeout: 250 seconds]
Abhishek09 has joined #ste||ar
<Mukund>
@nikunj Hi. What option am I supposed to give in the cmake install prefix. I thought it was supposed to be the build directory path
<zao>
Mukund: The install prefix is where you want the project installed when you invoke the install target.
<nikunj>
Mukund: you seem to be confused with prefix install and prefix path.
<nikunj>
Prefix install is where you want the library to get installed
<zao>
/usr/local, /opt/hpx-1.4.1, $HOME/stuff/hpx; etc.
<zao>
The prefix path is a list of places where CMake can find previously built software to use as dependencies.
<zao>
(and yes, the names are super unintuitive :D )
iti has joined #ste||ar
<Mukund>
I'm not able to fully understand. I have just forked and cloned hpx
<Mukund>
I'll ask in simple terms
<Mukund>
I have the clone in some local folder /home/mukund/hpx (say)
<Mukund>
I made a build directory
<Abhishek09>
Mukund: What u want to do?
<Mukund>
my_build
<Mukund>
I want to build hpx and set hpx-related paths
<Mukund>
basically install hpx on my system
<Mukund>
where do I go from here
<Abhishek09>
Which project?
<Mukund>
I have all the dependencies installed...
<Mukund>
Abhishek09 How about the whole of it?
<Mukund>
Is it not valid?
<Mukund>
I am a big newbie here
<Mukund>
what are the projects that are there?
<Abhishek09>
Refer irc channel description
<K-ballo>
the install prefix is the filesystem directory that will serve as the base path for the installation
<K-ballo>
something like /usr/local, or /opt/hpx-1.4.1
<K-ballo>
oh and I see zao already went over that
<zao>
:D
<Mukund>
ok so I can freely specify /usr/local then?
<K-ballo>
and yes, the install prefix is also added to the find prefixes
<K-ballo>
"/usr/local should bethe default already
<Mukund>
ok so I need not even specify the install prefix?
<K-ballo>
it's interesting that you found a need to specify it at all.. did you see it on some scripts?
<K-ballo>
what made you ask about it?
<Mukund>
damn, yeah. I was thinking about installing it someplace I wouldn't have issue and I could easily find
<Mukund>
I'll try to install it one more time.
<K-ballo>
installing it someplace is a good idea, yeah
<K-ballo>
what are you actually trying to do?
<zao>
There's three folders involved in a build. The source directory, the build directory, and the install directory.
<Mukund>
I was trying to install it someplace where I can find it easily K-ballo
<zao>
When you run CMake, you should stand in a build directory where it will generate the build scripts and the build output; or specify that directory with -B if you have a new enough CMake.
<zao>
When you run CMake, you will specify where the source directory is by plainly stating the directory name, unless you happen to be building in the source directory, which is discouraged.
<zao>
You have the option to specify an installation directory or rely on the system default, which you do with -DCMAKE_INSTALL_PREFIX=/some/where
<K-ballo>
must be something broken on the install scripts then
<nikunj>
K-ballo: simbergm seemed to have run the script to completion. Seems like there's something wrong on his end.
<nikunj>
Mukund: you can start with a basic install at /usr/local. Simply clone the repo, create a build folder and cd into the folder. And run cmake followed by make
<nikunj>
Mukund: if you face problem with this minimal install, please share the error log.
<zao>
You can upload logs to GitHub gists for easy sharing.
<zao>
(or other paste sites)
<K-ballo>
how is one supposed to choose the c++ standard to build with? there used to be some WITH_CXX options
<K-ballo>
could I just use the normal cmake ways to set it up nowadays?
<simbergm>
K-ballo: `CMAKE_CXX_STANDARD` (and another HPX-y option to discourage users from setting it) should work now
<simbergm>
`HPX_WITH_CXXBLAH` should also still work but give you warnings
<simbergm>
let me know if it doesn't
<simbergm>
Mukund: hi, seems like you're already getting some help (I'm msimberg from github), but you can ping me if you're still having trouble
<K-ballo>
what's the "proper" way to ste it thtne?
<simbergm>
`CMAKE_CXX_STANDARD`
<K-ballo>
that tells me not to
<simbergm>
let me check what I named the other variable
<K-ballo>
> You've set CMAKE_CXX_STANDARD manually, which is not recommended.
<K-ballo>
what is the recommended way
<K-ballo>
the other variable is HPX_USE_CMAKE_CXX_STANDARD
<simbergm>
right, it's recommended not to set it at all (at least I recommend it)
<simbergm>
if you must set it it is the recommended way
<simbergm>
maybe the wording there wasn't optimal
<K-ballo>
..?
<K-ballo>
not setting it at all, that can't be a recommendation.. there must be a misunderstanding
<K-ballo>
how do I choose to build hpx for C++17?
<simbergm>
the default is 14
<simbergm>
not setting it at all = use the default of 14
<simbergm>
btw, if you think this is a silly way of handling it please speak up :P
<K-ballo>
no, I must be missing something
<simbergm>
CMAKE_CXX_STANDARD is still the variable you would set it
<K-ballo>
ideally I'd just configure cmake for 17 in the usual way, via toolchain files or other supported ways
<simbergm>
I think the wording in the warning/error message might just be confusing you?
<K-ballo>
but I need to do it in a way that hpx will understand, at least in the past it would skip features for newer standards
<K-ballo>
maybe? discouraging from choosing the standard version makes no sense at all
<simbergm>
we had some newer features (17) that we still had to check with 14
<simbergm>
I've enabled all of them, the 17 ones will just fail rightfully if 14 is chosen
<simbergm>
my reasoning for discouraging them from choosing the standard version was that 14 is the lowest we support anyway, and using that as the default gives dependent projects the freedom to use 14 or anything newer
<simbergm>
I'm sure there would be cases where HPX built with 14 and user code with 17 would still break... but in principle that would be ok
<simbergm>
we can remove the warning though, and then the correct way would just be setting CMAKE_CXX_STANDARD without any caveats
Abhishek09 has quit [Remote host closed the connection]
<simbergm>
does that make more sense? or still silly?
<K-ballo>
CMAKE_CXX_STANDARD is technically for projects (directory scopes), not useres
<K-ballo>
always running feature tests makes sense, and is how it is supposed to be done.. but it was causing some issues in the past
<K-ballo>
I don't recall specifics, something having to do with `is_final` being detected
<K-ballo>
I'm hitting the broken asio issue now that I set cxx=17, what was the fix for that?
<simbergm>
is there value in having the indirection of a HPX_SOMETHING variable just control what CMAKE_CXX_STANDARD will contain?
<K-ballo>
the one where asio tries to use concept-ts syntax on ... wait
<simbergm>
hmm, which broken asio?
<K-ballo>
asio uses concept-ts syntax with 2a concepts, and fails horribly
<K-ballo>
why is asio detecting concept support now that I'm supposed to be targetting 17, but didn't for the default?
<simbergm>
I'd like to stick with our lowest supported standard being the default, but we could go back to having HPX_WITH_CXXAB variables
<simbergm>
although I'd prefer a HPX_WITH_CXX_STANDARD=AB variable instead
<simbergm>
is this a windows thing?
<simbergm>
the asio concepts stuff being broken?
<K-ballo>
no
<K-ballo>
it is a concepts-2a thing
<K-ballo>
my bad, I am actually targetting 2a instead of 17
<K-ballo>
oh look at that, I've reported it and everything
<Yorlik>
hkaiser: yt?
<Yorlik>
I have a weird phenomenon here: It seems my serialize function never gets called. When debugging it never stops at a breakpoint I set. It's same for the intrusive and the nonintrusive version.
<hkaiser>
simbergm: yt?
<simbergm>
hkaiser: here
<simbergm>
just saw your issue :)
<hkaiser>
nod, I have no idea where to even look
<simbergm>
looking through the targets pr to see if there's anything that stands out
<simbergm>
I don't have anything off the top of my head that would cause that
<simbergm>
in principle the underlying targets are more or less the same
<hkaiser>
interesting note: the Debug libraries are correct, the release libraries seem to be inserted as for instance hpx_init which is interpreted by cmake as a library as the target doesn't exist
<simbergm>
the generator expressions could be messing things up
<hkaiser>
(using hpx master)
<hkaiser>
I think this is a very similar issue
<simbergm>
hkaiser: is that with my PR?
<hkaiser>
if I change Phylanx to use HPX::iostream_component instead of the COMPONENT_DEPENDENCIES I get the wrong release library names (even on HPX master)
<hkaiser>
so it's not caused by the PR I commented on, but is a general problem
<hkaiser>
no that's without your PR
<K-ballo>
Yorlik: if you have confirmed you are indeed serializing an object that ought to call your function, that'd mean your function doesn't fit the requirements
<simbergm>
the generator expressions are meant to filter out libraries and definitions that are not needed, but it doesn't seem to work
<hkaiser>
what file is that?
<simbergm>
src/CMakeLists.txt
<simbergm>
not sure if the line highlight works correctly
<hkaiser>
doesn't see any highlights
<simbergm>
sec, I'll get another link
<hkaiser>
see it now
<simbergm>
creating a small sanity check for you
<hkaiser>
simbergm: shouldn't this: $<${_is_executable}:$<TARGET_NAME_IF_EXISTS:hpx_init>>) be this instead: $<${_is_executable}:$<TARGET_NAME_IF_EXISTS:HPX::hpx_init>>)
Hashmi has joined #ste||ar
<simbergm>
well, there's both
<hkaiser>
ahh, right
<simbergm>
hpx_init is not a target in dependent projects, but HPX::hpx_init is
<simbergm>
vice versa within HPX
<hkaiser>
right, but it still somehow gets added as a dependency for me, cmake then interprets it as a plain library
<simbergm>
you can check if hpx_init actually is also a target for you
<simbergm>
exactly, that's the problem, but I don't know why
<simbergm>
but if you have that `HPXTargets.cmake` file that could help
<Yorlik>
hkaiser: Solved the problem of the missing strings yesterday. Its a restriction of my messaging system, which doesn't (yet) allow pointertypes. I need to fix this
<Yorlik>
It's a UB miracle the start of the vector was displayed at all.
<Yorlik>
:)
<hkaiser>
simbergm: just did a full reconfigure, still the same
<simbergm>
you'll need a dummy lib.cpp and main.cpp
<simbergm>
compiling the executable should give you IM_AN_EXECUTABLE and the library should give you IM_A_LIBRARY
<simbergm>
you said you get both HPX_APPLICATION_EXPORTS and HPX_LIBRARY_EXPORTS defined for all targets, right?
<simbergm>
likewise you can try to add a `target_link_libraries(test_executable PRIVATE $<${_is_executable}:$<TARGET_NAME_IF_EXISTS:target_that_doesnt_exist>>)` and see what it does
<hkaiser>
simbergm: yah, those macros are defined
<hkaiser>
no, the macros are ok
<simbergm>
can you try the second one as well, please?
<hkaiser>
target_that_doesnt_exist is not added as a dependency
<hkaiser>
looks ok overall
<simbergm>
grr
<simbergm>
so cmake is not (entirely) broken at least
<simbergm>
and if you grep phylanx there are no stray hpx_inits lying around without HPX:: in front of them?
<simbergm>
or in the hpx install
<simbergm>
this is on my PR, unmodified?
<hkaiser>
simbergm: so if I add HPX::hpx as a dependency to the test project all is fine :/
<hkaiser>
must be a Phylanx problem after all - why I'm not surprised
<hkaiser>
simbergm: I did grep for hpx_init in Phylanx - couldn't find anything
<simbergm>
that would indicate that phylanx is adding hpx/hpx_init somewhere
<hkaiser>
indeed
<simbergm>
:(
<hkaiser>
ok, don't worry about it, it's obviously a Phylanx problem - I'll investigate
<hkaiser>
thanks for your help!
<simbergm>
all targets in phylanx fail?
<simbergm>
bleh, let me know how it goes, sorry for the extra work :/
<hkaiser>
all targets fail, yes
<hkaiser>
all of them have hpx and hpx_init
<hkaiser>
this is on HPX master and Phylanx master, your PR is not involved
<hkaiser>
started to happen after latest HPX target related changes :/
<simbergm>
can you try my PR?
<hkaiser>
id that earlier, same problem
<hkaiser>
*did*
<simbergm>
right, it was expected to break, but not like that...
karame78 has quit [Remote host closed the connection]
<simbergm>
for debugging you could also have a look at the LINK_LIBRARIES (I think it's called that) for some of the targets
<simbergm>
if you have extra standalone hpxs or hpx_inits there that look like they don't come from HPXTargets.cmake that might tell that there still are some around
Abhishek09 has joined #ste||ar
diehlpk_work has joined #ste||ar
<hkaiser>
yah, I replaced those
gonidelis has joined #ste||ar
<Abhishek09>
nikunj97: How do you prefer to install cmake?
<Abhishek09>
by cli or pypa or gui
<nikunj97>
I use my package manager
<nikunj97>
sudo dnf install cmake
<Abhishek09>
which?
<Abhishek09>
on ubuntu?
<nikunj97>
depending upon the os I'm in
<nikunj97>
I don't use Ubuntu
<nikunj97>
I'm using fedora 31 these days, but I switch ever so often
<Abhishek09>
ubuntu more popular most used in linux these days
<nikunj97>
sure, so?
<Abhishek09>
So i giving priority ubuntu rather than ubuntu for pypa package
<Abhishek09>
rather than fedora
<nikunj97>
I'd want that to be generic
<nikunj97>
and not os specific
<nikunj97>
you may start as os specific, but in the end I believe it shouldn't depend on the os underneath
<nikunj97>
zao, what os are you using these days btw?
<zao>
Windows 10 on desktop, Ubuntu 18.04 on build machine, Ubuntu 16.04 on the clusters at work, Arch Linux on my desktop when I bother rebooting it.
<nikunj97>
the variety :D
<Abhishek09>
@zao By which method you install cmake on ubuntu?
<hkaiser>
simbergm: I found it!
<simbergm>
hkaiser: what the devil was it? :P
<hkaiser>
simbergm: hpx and hpx_init were still generated as dependencies for blaze
<zao>
Abhishek09: As we use EasyBuild to build software, it's easiest for me to load both the compiler and cmake via modules.
<zao>
Abhishek09: But the binary download from cmake.org is fine too.
<zao>
Download, extract somewhere, add to path or just point out the location of bin/cmake.
<simbergm>
oh my
<hkaiser>
sorry for all the noise
<simbergm>
I guess blaze needs an update as well ;)
<simbergm>
and, whatever users can get their hands on they will use
<simbergm>
no problem! that's a pretty annoying thing to debug
<zao>
Abhishek09: It matters less if you ruin the OS in a docker container as it's typically rebuilt from scratch when used for CI/CD jobs.
<zao>
There it's less of a problem to install things system-wide or use weird PPAs, while on a machine you use for a long while, be careful :D
<Abhishek09>
@zao i using cli for building
<Abhishek09>
cmake
<zao>
Abhishek09: My point was that the lifetime of the machine might matter a bit when deciding what to install and where.
<zao>
If you're preparing a Dockerfile that does the whole build process from scratch, including installing dependencies and tools - you might have different considerations than if you're working on a shared server or a workstation.
<diehlpk_work>
hkaiser, Octo-Tiger works on PiZ Daint
<hkaiser>
\o/
<diehlpk_work>
I could run the same problem on one node as on Cori
<diehlpk_work>
idle rate is around 30%
<diehlpk_work>
IO ist even more horrible
<diehlpk_work>
208.76 to read 1.1. MB
<hkaiser>
well, 30% is not too bad, actually
<hkaiser>
piz-daint has some staged IO space, node-local
<hkaiser>
that would help
<diehlpk_work>
yes. I will copy the files for the next runs
<diehlpk_work>
hkaiser, I sent an email to Dominic and cc'ed you, so he can look into the results
<hkaiser>
ok
<diehlpk_work>
Cool think is, it took me 1.5 hours to compile octotiger and generate the scripts
<hkaiser>
diehlpk_work: did you use a different version of OT?
<diehlpk_work>
So we are flexible to compile the code on different clusters
<hkaiser>
nice
<diehlpk_work>
I do not hink so, but I will double check
<hkaiser>
well, the output you sent is different, isn't it?
<diehlpk_work>
I thinkthat GPU and CPU counters are handled differently
<diehlpk_work>
Let us wait for Dominics response
nikunj97 has quit [Remote host closed the connection]
<diehlpk_work>
Anayway A woke up and I have to look later into it
<diehlpk_work>
However, we are able to produce the runs on Daint, if we like
<diehlpk_work>
Sorry for all the typos, A is competing with me who is using the keyboard
<hkaiser>
yah, makes sense
<diehlpk_work>
hkaiser, I will come back to you later today
<hkaiser>
sure, no worries
diehlpk_work has quit [Ping timeout: 260 seconds]
Abhishek09 has quit [Remote host closed the connection]
Hashmi has quit [Quit: Connection closed for inactivity]
<nikunj97>
why do you need all the command line arguments this early in execution?
<nikunj97>
you're essentially making it run before main itself
<nikunj97>
looks very much like the init_globally example we have in hpx
<Yorlik>
Is is possible and valid to use a unique_ptr as action argument?
<Yorlik>
So - will it serialize and the managed object (if serializable) also be serialized?
<Yorlik>
I just want to avoid any additional object copies, once the action argument has arrived in the destination function.
<Yorlik>
And I Need to store it temporarily, until an updater has time to work on a mailbox. So I am thinking of changing the mailbox to be a vector of unique pointers to a variant over the different message types.
nikunj97 has quit [Quit: Leaving]
<hkaiser>
Yorlik: should work, yes
<Yorlik>
Thanks. Do you think the it would serve the purpose ? Like copy less and store it for later?
<hkaiser>
Yorlik: action arguments will be moved wherever possible, so you should be fine without the unique_ptr
<Yorlik>
I wanted it to be guaranteed, but if not needed I could just move it to a vector.
<hkaiser>
ideally no copies will be creted at all
<hkaiser>
but for that you need to call async with rvalues
<Yorlik>
I'm just asking myself what happens to the stack where the object lives? Will the portion where it lives be saved until it is deleted?
<hkaiser>
huh?
<Yorlik>
I am thinking about the receiving end
<Yorlik>
Like - messages coming in and I don't want to copy them.
<hkaiser>
vector<variant<...>> v = ...; async<Action>(target, std::move(v));
<hkaiser>
the receiving end should take the message type _by value_, hpx will move the received vector into the parameter
<Yorlik>
And then I could move it into intermediate storage until update cycle (The vector would bve a member of the message)+
<hkaiser>
sure
<Yorlik>
I think I overoptimized something in my system and created a source of UB that is unnecessary dangerous and not really helping.
<hkaiser>
premature optimization is the root of all evil
<Yorlik>
Probably in this case it was premature, indeed. but I'd rather fix a bunch of premature optimizations gone wrong than not optimizing enough. I'm still in the area of the core tight loops of the system.
<Yorlik>
The thinking was to keep all the messages together
<Yorlik>
But for that I'd have to copy them and nothing is really gained.
<Yorlik>
So - I better leave them where HPX drops them and use them from there.
<Yorlik>
If objects have allocation methods - how would HPX recognize these? Custom new?
<Yorlik>
Like asking HPX to drop objects coming in together by some methodology.
<Yorlik>
E.g. a message buffer owned by the receiving object
<Yorlik>
How could I do that without it becoming overkill/more copying?
<hkaiser>
Yorlik: what do you mean by 'objects have allocation methods'?
<hkaiser>
member function operator new() ?
<Yorlik>
Yes, maybe that.
<Yorlik>
Just a way to determine where it gets stored.
<hkaiser>
that will only be used if the object is allocated on the heap
<hkaiser>
I doubt that happens during serialization as you are allocating the object
<Yorlik>
The problem is, I need to extend the lifetime of the object beyond the function where it arrives.
<hkaiser>
well, move it somewhere
<hkaiser>
sorry, I misspoke
<Yorlik>
move implies a memcpy, right?
<hkaiser>
HPX is allocating the object, but not on the head
<hkaiser>
Yorlik: if your type is not movable, then it will copy it, yes
<hkaiser>
but if its movable it usually is a simple pointer copy
<hkaiser>
moving a std::vector is cheap
<Yorlik>
Like for strings or vectors.
<Yorlik>
OK.
<Yorlik>
So - the message struct will probably be copied, but the args in a vector not.
<hkaiser>
you will need to add a move constructor/move assignment to your message struct
<Yorlik>
That shouzldn't be a problem.
<Yorlik>
The messages themselves, the core struct is below 64 b anyways
<hkaiser>
the compiler generated move operators might be sufficient
<hkaiser>
depends on your message type
<Yorlik>
They will be - I have no complicated resources.
<Yorlik>
There might be few exceptions in the future
<Yorlik>
I think I'll rework parts of my messaging system tomorrow - the empty strings and some random crashes should be fixed then :D
<Yorlik>
I was pretty deep in UB land - lol.
<zao>
I'm sad. I need to write parallel C++ code and the standard library is silly.
K-ballo has quit [Remote host closed the connection]