- Boost-users - lists.preview.boost.org

catmull_rom splines
by Giorgino R 29 May '19

29 May '19

Hi all, I am trying to interpolate some data with a catmull_rom spline available in boost math (interpolation). However, the resulting spline has a strange behavior; especially, at its ends (see the attached image). Just out of curiosity, I also tried to normalise my data to [0-1] range. However, the line has had even worse behavior (see the attached image). Below, the c++ code segment of the interpolation is depicted: std::vector<std::array<double, 2>> points_intr(16); points_intr[0] = { 1.263270, 0.774614 }; points_intr[1] = { 1.876, 2.480 }; points_intr[2] = { 1.651110, 4.550 }; points_intr[3] = { 1.426340, 5.688 }; points_intr[4] = { 1.429, 7.054 }; points_intr[5] = { 2.073220, 8.377020 }; points_intr[6] = { 3.910, 9.140 }; points_intr[7] = { 6.430, 9.537 }; points_intr[8] = { 8.950, 9.859 }; points_intr[9] = { 11.470, 10.317 }; points_intr[10] = { 12.730, 10.6456 }; points_intr[11] = { 13.990, 11.0741 }; points_intr[12] = { 15.335, 11.6928 }; points_intr[13] = { 16.680, 12.5661 }; points_intr[14] = { 18.3538, 14.830 }; points_intr[15] = { 18.700, 16.056 }; bm::catmull_rom<std::array<double, 2>> interpolator_cr(std::move(points_intr)); std::vector<double> x_linspace_cr(100); std::vector<std::array<double, 2>> inter_points(100); linspace(1.263270, 18.700, 100, x_linspace_cr); // evaluation points along the line for (std::size_t i{0}; i < x_linspace_cr.size(); ++i) { inter_points[i] = interpolator_cr(x_linspace_cr[i]); } Should I have to add additional (ghost) points at both ends? If yes, is there any optimum way to calculate where exactly to poisition these points? I understand if I get the derivatives at both end I can calculate a straight line that the additional points should lie within. However, how should I calculate the distance from the end points? I hope I am not doing anything fundamentally wrong. Any help would be much appreciated. Many thanks!

2 1

bug or documentation missing boost posix_time time_duration not_a_date_time
by Erik Thiele 27 May '19

27 May '19

hi please compile this program: #include <boost/date_time/posix_time/ptime.hpp> #include <iostream> #include <vector> using namespace boost::posix_time; using namespace std; #define x(v) cout << #v << " : " << (v) << '\n'; int main(int argc, char *argv[]) { time_duration a(not_a_date_time); time_duration b; x(a<b); x(a>b); x(a<=b); x(a>=b); x(b<a); x(b>a); x(b<=a); x(b>=a); x(a==b); x(b==a); x(a.is_special()); x(b.is_special()); vector<time_duration> v0, v1; v0.push_back(time_duration()); v0.push_back(time_duration(not_a_date_time)); sort(v0.begin(), v0.end()); v1.push_back(time_duration(not_a_date_time)); v1.push_back(time_duration()); sort(v1.begin(), v1.end()); x(v0==v1); return 0; } the output is: a<b : 0 a>b : 0 a<=b : 1 a>=b : 1 b<a : 0 b>a : 0 b<=a : 1 b>=a : 1 a==b : 0 b==a : 0 a.is_special() : 1 b.is_special() : 0 v0==v1 : 0 if the time_duration datatype is a complete partial order which is for example needed for it to be able to be sorted, then the above output is partly illegal: if not a<b and not b<a then must be a=b. but this is not the case. if a<=b and b<=a then must be a=b. but this is not the case. so as expected the two vectors v0 and v1 are not equal after being sorted even though they certainly should be! i do not understand why time_duration is behaving in such a strange way here. I am using time_duration(not_a_date_time) as a SQL-NULL value just like i am using date(not_a_date_time) and ptime(not_a_date_time) as SQL-NULL values. obviously I should not use time_duration(not_a_date_time). maybe this is the reason why time_duration() != time_duration(not_a_date_time)? I don't understand the design here. for example date()==date(not_a_date_time) and also ptime()==ptime(not_a_date_time) but not with time_duration. why??? why is there no documentation that time_duration is not a complete partial order and thus not sortable - at least when using not_a_date_time? cya erik

2 5

[Boost.Build] configure.builds and check-target-builds always build in debug mode
by David Callu 25 May '19

25 May '19

Hi, I try to add icu support in boost conan package, but on windows with msvc, the build never use icu. During icu detection in boost.locale, the has_icu.exe never build because configure.builds try to build in debug mode when I use property "variant=release" in b2 command line. I can see that in config.log written by b2 during build : b2 use icuucd.lib and icuind.lib instead of icuuc.lib and icuin.lib. So icu is not correctly detected, and so never used. If I bypass the has_icu test, boost locale build fine and have icu backend as expected. This behaviors only fail builds that use different library in release and debug mode, like icu build with msvc. Is it the correct behaviors ? - If yes this is a bad news for library with different library name in release and debug mode. - If no ... houston, we have a problem Best regards David

1 0

[asio] example link dead
by Stephan Menzel 21 May '19

21 May '19

This is just a quick heads up. The website link to a file example in asio: https://www.boost.org/doc/libs/1_70_0/doc/html/boost_asio/example/cpp11/non… ... appears to be dead. 404. HTH... Stephan

3 2

Re: [Boost-users] linker error boost with 1.69 and 1.70
by Danny K 21 May '19

21 May '19

I figured out my problem so please disregard my question. My problem was that zlib and bzip2 support was not being included. I developed a perl script that builds everything for me for Windows & Linux and somehow when the Linux script builds 1.69 or 1.70, it turns off zlib and bzip2 support. Not sure the cause but taking the command my perl script executes and running it the shell outside of perl, boost builds with the proper support for zlib/bzip2 in iostreams. Not sure what the change would be but I have a workaround. wr, Danny

1 0

linker error boost with 1.69 and 1.70
by Danny K 20 May '19

20 May '19

So I have been using boost for awhile. I compile boost the same way for all the versions and have been since 1.48. My platforms are CentOS 6 & 7 and Windows 10 vs2017. My code has compiled on all 3 platforms with Boost without a problem. My current version is 1.66 and I wanted to upgrade to 1.69. Under Windows, I build 1.69 with ZLIB & BZIP and my applications have no problems. I use zlib & bzip in the IOstreams library to read & write compressed files. So I built 1.69 under Linux the same way as I always have but I am now getting a linker error that I don't understand and I am stuck. The error starts with: API_utiltyFunctions.cpp:(.text+0x154): undefined reference to `boost::iostreams::detail::zlib_base::before(char const*&, char const*, char*&, char*)' API_utiltyFunctions.cpp:(.text+0x15b): undefined reference to `boost::iostreams::zlib::sync_flush' API_utiltyFunctions.cpp:(.text+0x165): undefined reference to `boost::iostreams::detail::zlib_base::xinflate(int)' API_utiltyFunctions.cpp:(.text+0x177): undefined reference to `boost::iostreams::detail::zlib_base::after(char const*&, char*&, bool)' API_utiltyFunctions.cpp:(.text+0x17e): undefined reference to `boost::iostreams::zlib_error::check(int)' API_utiltyFunctions.cpp:(.text+0x185): undefined reference to `boost::iostreams::zlib::stream_end' The boost portion of my linker line is: -L[ path to boost 1.69] \ -lboost_random-1_69 \ -lboost_program_options-1_69 \ -lboost_date_time-1_69 \ -lboost_chrono-1_69 \ -lboost_regex-1_69 \ -lboost_thread-1_69 \ -lboost_exception-1_69 \ -lboost_filesystem-1_69 \ -lboost_system-1_69 \ -lboost_iostreams-1_69 -lrt -lbz2 -lz -lm Any help would be appreciate. Weirdly if I revert back to boost 1.66, I don't have a problem. I also tested this compilation against boost 1.70 and I get the same problem. I do compile boost statically with shared runtime libraries and threads. Respectfully, Danny K

1 0

[variant2] Acceptance conditions met - Targeted for 1.71.0
by Michael Caisse 16 May '19

16 May '19

Peter Dimov has updated the Variant2 library based on review acceptance criteria. I have reviewed the changes and "OK" Variant2 to be included as a Boost library. My understanding is that Peter is targeting Variant2 to be available in the 1.71.0 release. Congratulations Peter! Thank you for your quick work in updating the library based on the review feedback. -- Michael Caisse Ciere Consulting ciere.com

1 0

Building boost 1_70_0 with PGI 18.5 on CentOS 7
by Christopher Harrop - NOAA Affiliate 16 May '19

16 May '19

Hi, I am having trouble building Boost 1_70_0 with PGI 18.5 on a Linux CentOS 7 system, and I am wondering if anyone has suggestions about how to get it working. I spent some time searching online for answers, but didn’t find anything recent that applied to my problem. I am a novice with boost, and so am not sure where to start digging for solutions. I have no issues with GCC or Intel compilers. My procedure, after I untar and cd into the boost directory, is as follows: ./bootstrap.sh --with-toolset=pgi —prefix=/path/to/install/boost export BUILD_TYPE=complete export LIBRARY_NAME=versioned export LIBRARY_TARGETS=shared,static ./b2 -j 12 install --build-type=${BUILD_TYPE} --layout=${LIBRARY_NAME} --target=${LIBRARY_TARGETS} This procedure appears to work fine for the intel-linux and gcc toolsets. But, for pgi, I get this: ==================================== +./bootstrap.sh --with-toolset=pgi --prefix=/path/to/install/boost Building Boost.Build engine with toolset pgi... tools/build/src/engine/bin.linuxx86_64/b2 Detecting Python version... 2.7 Detecting Python root... /usr Unicode/ICU support for Boost.Regex?... /usr Generating Boost.Build configuration in project-config.jam for pgi... Bootstrapping is done. To build, run: ./b2 To generate header files, run: ./b2 headers To adjust configuration, edit 'project-config.jam'. Further information: - Command line help: ./b2 --help - Getting started guide: http://www.boost.org/more/getting_started/unix-variants.html - Boost.Build documentation: http://www.boost.org/build/ + export BUILD_TYPE=complete + BUILD_TYPE=complete + export LIBRARY_NAME=versioned + LIBRARY_NAME=versioned + export LIBRARY_TARGETS=shared,static + LIBRARY_TARGETS=shared,static + ./b2 -j 12 install --build-type=complete --layout=versioned --target=shared,static Performing configuration checks - default address-model : none - default architecture : none /scratch4/BMC/gsd-hpcs/Christopher.W.Harrop/bass-develop/build/boost/1.70.0/pgi/18.5/tools/build/src/tools/common.jam:977: in toolset-tag *** argument error * rule numbers.less ( n1 n2 ) * called with: ( 4 ) * missing argument n2 ==================================== Based on some suggestions I found online from others having similar errors, I edited tools/build/src/tools/common.jam to comment out these lines (977-980): # From GCC 5, versioning changes and minor becomes patch # if $(tag) = gcc && [ numbers.less 4 $(version[1]) ] # { # version = $(version[1]) ; # } This results in the following failure, which I’ve truncated because it’s really long: ==================================== + ./bootstrap.sh --with-toolset=pgi --prefix=/scratch4/BMC/gsd-hpcs/Christopher.W.Harrop/bass-develop/opt/boost/1.70.0/pgi/18.5 Building Boost.Build engine with toolset pgi... tools/build/src/engine/bin.linuxx86_64/b2 Detecting Python version... 2.7 Detecting Python root... /usr Unicode/ICU support for Boost.Regex?... /usr Generating Boost.Build configuration in project-config.jam for pgi... Bootstrapping is done. To build, run: ./b2 To generate header files, run: ./b2 headers To adjust configuration, edit 'project-config.jam'. Further information: - Command line help: ./b2 --help - Getting started guide: http://www.boost.org/more/getting_started/unix-variants.html - Boost.Build documentation: http://www.boost.org/build/ + export BUILD_TYPE=complete + BUILD_TYPE=complete + export LIBRARY_NAME=versioned + LIBRARY_NAME=versioned + export LIBRARY_TARGETS=shared,static + LIBRARY_TARGETS=shared,static + ./b2 -j 12 install --build-type=complete --layout=versioned --target=shared,static Performing configuration checks - default address-model : none - default architecture : none error: No best alternative for libs/context/build/asm_sources next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>qcc not matched next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>mach-o <threading>multi <toolset>clang not matched next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>pe <threading>multi <toolset>msvc not matched next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>mach-o <threading>multi <toolset>clang not matched next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>o32 <address-model>32 <architecture>mips1 <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>o32 <address-model>32 <architecture>mips1 <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>n64 <address-model>64 <architecture>mips1 <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>n64 <address-model>64 <architecture>mips1 <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>xcoff <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>xcoff <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>mach-o <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>xcoff <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>xcoff <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>32_64 <architecture>power <binary-format>mach-o <threading>multi not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>intel not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang-win not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>intel not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>msvc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>intel not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>intel not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang-win not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>intel not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>msvc not matched next alternative: required properties: <abi>x32 <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>x32 <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>x32 <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>intel not matched next alternative: required properties: <abi>sysv <address-model>32_64 <architecture>x86 <binary-format>mach-o <threading>multi not matched next alternative: required properties: <abi>sysv <architecture>combined <binary-format>mach-o <threading>multi not matched - C++11 mutex : no - lockfree boost::atomic_flag : no - Boost.Config Feature Check: cxx11_auto_declarations : no - Boost.Config Feature Check: cxx11_constexpr : no - Boost.Config Feature Check: cxx11_defaulted_functions : no - Boost.Config Feature Check: cxx11_final : no - Boost.Config Feature Check: cxx11_hdr_mutex : no - Boost.Config Feature Check: cxx11_hdr_tuple : no - Boost.Config Feature Check: cxx11_lambdas : no - Boost.Config Feature Check: cxx11_noexcept : no - Boost.Config Feature Check: cxx11_nullptr : no - Boost.Config Feature Check: cxx11_rvalue_references : no - Boost.Config Feature Check: cxx11_template_aliases : no - Boost.Config Feature Check: cxx11_thread_local : no - Boost.Config Feature Check: cxx11_variadic_templates : no - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - zlib : no - bzip2 : no - lzma : no - zstd : no - iconv (libc) : no - iconv (separate) : no - icu : no - icu (lib64) : no - Boost.Locale needs either iconv or ICU library to be built. - Boost.Locale needs either iconv or ICU library to be built. - native-atomic-int32-supported : no - native-syslog-supported : no - pthread-supports-robust-mutexes : no - x86 : no - arm : no - mips1 : no - power : no - sparc : no - gcc visibility : no - long double support : no warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. - libbacktrace builds : no - addr2line builds : no - WinDbg builds : no - WinDbgCached builds : no - BOOST_COMP_GNUC >= 4.3.0 : no error: No best alternative for libs/context/build/asm_sources ### similar messages to the above repeat several times and I’ve left it out for clarity and length, then output continues below ### Component configuration: - atomic : building - chrono : building - container : building - context : building - contract : building - coroutine : building - date_time : building - exception : building - fiber : building - filesystem : building - graph : building - graph_parallel : building - headers : building - iostreams : building - locale : building - log : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - stacktrace : building - system : building - test : building - thread : building - timer : building - type_erasure : building - wave : building ...patience... ...patience... ...patience... ...patience... ...patience... ...found 45809 targets... ...updating 17951 targets... gcc.compile.c++ bin.v2/libs/regex/build/gcc/debug/threading-multi/visibility-hidden/posix_api.o /bin/sh: line 1: -fvisibility-inlines-hidden: command not found -fvisibility-inlines-hidden -fPIC -pthread -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_REGEX_DYN_LINK=1 -I"." -c -o "bin.v2/libs/regex/build/gcc/debug/threading-multi/visibility-hidden/posix_api.o" "libs/regex/build/../src/posix_api.cpp" ...failed gcc.compile.c++ bin.v2/libs/regex/build/gcc/debug/threading-multi/visibility-hidden/posix_api.o... gcc.compile.c++ bin.v2/libs/regex/build/gcc/debug/threading-multi/visibility-hidden/c_regex_traits.o /bin/sh: line 1: -fvisibility-inlines-hidden: command not found -fvisibility-inlines-hidden -fPIC -pthread -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_REGEX_DYN_LINK=1 -I"." -c -o "bin.v2/libs/regex/build/gcc/debug/threading-multi/visibility-hidden/c_regex_traits.o" "libs/regex/build/../src/c_regex_traits.cpp" ...failed gcc.compile.c++ bin.v2/libs/regex/build/gcc/debug/threading-multi/visibility-hidden/c_regex_traits.o... gcc.compile.c++ bin.v2/libs/regex/build/gcc/debug/threading-multi/visibility-hidden/instances.o /bin/sh: line 1: -fvisibility-inlines-hidden: command not found -fvisibility-inlines-hidden -fPIC -pthread -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_REGEX_DYN_LINK=1 -I"." -c -o "bin.v2/libs/regex/build/gcc/debug/threading-multi/visibility-hidden/instances.o" "libs/regex/build/../src/instances.cpp" ==================================== Chris ----------------------------------------------------------------------------------------------------------- Christopher W. Harrop email: christopher.w.harrop(a)noaa.gov <mailto:christopher.w.harrop@noaa.gov> Global Systems Division voice: (303) 497-6808 <tel:%28303%29%20497-6808> NOAA Earth System Research Laboratory fax: (303) 497-7259 <tel:%28303%29%20497-7259> 325 Broadway R/GSD2 Boulder, CO 80303

3 4

[stacktrace]stacktrace print nothing on x86.
by Hao Jiang 16 May '19

16 May '19

Hello everyone, I found boost::stacktrace print no information on my machine in RELEASE mode when target is x86, i.e. the size of stacktrace is zero. But if target switched to x64, stacktrace worked fine. Is anyone knows the reason? OS: Windows 7(64) Compiler: MSVC 14 Boost ver. :1.67/1.69 Stacktrace config: BOOST_STACKTRACE_USE_WINDBG(_CACHED) Thanks, Hao Jiang.

1 0

Boost Graph write_grahml - wrong source- and target-ID's in edge of XML-File
by lila 13 May '19

13 May '19

Hi there, I want to create an xml-file out of my Graph... So I'm using the write_graphml Function with dynamic_properties. Everything is fine, I get a file, but there are wrong source- and target- ID's in the edge structs ... Here an example: <node id="n1"> <data key="key0">vertex_7</data> <data key="key2">bf88aa63-bff1-5c04-8daf-37a5e31981f6</data> <data key="key6">12.5</data> <data key="key7">7.5</data> </node> <edge id="e1" source="n1" target="n2"> <data key="key1">edge_4_5</data> <data key="key3">26c512cb-46d8-5eb5-8021-2aac9f492227</data> <data key="key4">45844430-f1ea-5355-b7ce-eb566fe89256</data> <data key="key5">ecac63d6-e531-5ce8-9578-13cb63d040de</data> </edge> In the edge there is the wrong source-ID - it should be the ID of Vertex 4 (source="n0") not 7 (source="n1") My Graph: struct vertex { float x; float y; string name; string uuid; }; struct edge { string source_v_uuid; //startpoint uuid string target_v_uuid; //endpoint uuid string name; // name - edge_from_src-Vertex_to_dest-Vertex string uuid; }; typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, vertex, edge> myGraph; And my Properties: boost::dynamic_properties dyn_p; // fill vertex properties dyn_p.property("name", get(&vertex::name, graph)); dyn_p.property("x-value", get(&vertex::x, graph)); dyn_p.property("y-value", get(&vertex::y, graph)); dyn_p.property("uuid", get(&vertex::uuid, graph)); // fill edge properties dyn_p.property("name", get(&edge::name, graph)); dyn_p.property("v-src-uuid", get(&edge::source_v_uuid, graph)); dyn_p.property("v-dest-uuid", get(&edge::source_v_uuid, graph)); dyn_p.property("uuid", get(&edge::uuid, graph)); write_graphml(ofs, graph, dyn_p, true); I tried to create a property map by myself to set the UUID as the (vertex (source/target)) -ID's, but that changed nothing, there are still wrong source- and target- ID's in the edge struct. auto map = get(&vertex2::uuid, graph); write_graphml(ofs, graph, map, dyn_p, true); Can anybody help me? Or even give me a hint to figure out what is going wrong? -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Users-f2553780.html

1 0