profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/joaquintides/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

joaquintides/cpp14monadworkshop 99

Material for a workshop on monads with C++14

joaquintides/transrangers 88

An efficient, composable design pattern for range processing

joaquintides/usingstdcpp2015 83

"Mind the cache" presentation at using std::cpp 2015 and associated material

boostorg/poly_collection 56

Fast containers of polymorphic objects.

joaquintides/usingstdcpp2019 20

"Some fun with Reactive Programming in C++17" presentation at using std::cpp 2019 and associated material

joaquintides/usingstdcpp2017 10

Presentations from Joaquín Mª López Muñoz at using std::cpp 2017 and associated material

joaquintides/usingstdcpp2014 8

Presentaciones de Joaquín Mª López Muñoz en el using std::cpp 2014 y código fuente auxiliar

joaquintides/boost_epoch 6

Proposal for an epoch-based organization of Boost libraries

boostorg/flyweight 5

Boost.org flyweight module

Manu343726/cpp-dod-tests 5

Performance tests for an encapsulation-enabled Data Oriented Design implementation

issue commentboostorg/poly_collection

test_construction failed on Dinkumware

Ok, looks like this a pretty stable library. Will ask back in a year if you don't mind.

BinCaoWR

comment created time in 9 days

issue commentboostorg/poly_collection

test_construction failed on Dinkumware

Hi, a year has passed and I'd like to ask again to see if things have changed:

  • What is the value of BOOST_DINKUMWARE_STDLIB in your current environment? (It used to be 804.)
  • If this value has changed, would you mind re-running tests with the macro BOOST_DETECT_OUTDATED_WORKAROUNDS globally defined? This will tell us if the underlying Dinkumware problem has been fixed.
BinCaoWR

comment created time in 13 days

delete branch joaquintides/iterator

delete branch : patch-2

delete time in 16 days

PR closed boostorg/iterator

split advance_impl for bidirectional iterators

Split according to signedness/unsignedness of Distance, as the checks "if (n >= 0)" and "while (n < 0)" produce type-limits warnings in GCC 4.6-7 when n is unsigned.

+30 -2

6 comments

1 changed file

joaquintides

pr closed time in 16 days

PR opened boostorg/iterator

supressed spurious type-limits warning

See https://github.com/boostorg/iterator/pull/66 for details.

+11 -0

0 comment

1 changed file

pr created time in 16 days

push eventjoaquintides/iterator

joaquintides

commit sha 6dfb175cefd9b53f9da905bdaf75a621821e39f2

supressed spurious type-limits warning See https://github.com/boostorg/iterator/pull/66 for details.

view details

push time in 16 days

pull request commentboostorg/iterator

split advance_impl for bidirectional iterators

This is also a possibility. Do you want to me to change the PR so as to use pragmas instead?

joaquintides

comment created time in 16 days

pull request commentboostorg/iterator

split advance_impl for bidirectional iterators

To add more context, the extension of boost::advance to allow for arguments other than the difference type was made by you on July 2017, with the following rationale:

"Use a separate template parameter for distance in advance(). This follows std::advance interface and also allows to use distance types other than iterator's difference_type (if the iterator supports that)."

joaquintides

comment created time in 16 days

pull request commentboostorg/iterator

split advance_impl for bidirectional iterators

boost::advance does not require that its Distance argument be of the same type as the iterator difference type. For the record, neither does std::advance. The libc++ implementation of std::advance also allows unsigned arguments.

joaquintides

comment created time in 17 days

PR opened boostorg/iterator

split advance_impl for bidirectional iterators

Split according to signedness/unsignedness of Distance, as the checks "if (n >= 0)" and "while (n < 0)" produce type-limits warnings in GCC 4.6-7 when n is unsigned.

+30 -2

0 comment

1 changed file

pr created time in 17 days

push eventjoaquintides/iterator

joaquintides

commit sha 2f345fff771cb19614129cbf769bf30bc61131b5

split advance_impl for bidirectional iterators Split according to signedness/unsignedness of Distance, as the checks "if (n >= 0)" and "while (n < 0)" produce type-limits warnings in GCC 4.6-7 when n is unsigned.

view details

push time in 17 days

issue commentboostorg/multi_index

[Question] Calling modify(iterator position,Modifier mod) with no key updating from shared lock is safe ?

There's two ways to answer this:

  • Official answer: Boost.MultiIndex abides by standard library requirements on data race avoidance, and in particular guarantees [res.on.data.races]/3, by which concurrent access to a container through const functions is safe. As modify is not const, your scenario is not safe.
  • Unofficial answer: if you're not modifying any key and no user specified object (compare object, hasher, etc.) throws, modify does not actually modify anything (other than the element itself). So, yes, the scenario is unofficially safe. In this case, though, I think it's more informative and clear to just const_cast the element and avoid using modify.
redboltz

comment created time in 17 days

push eventboostorg/multi_index

joaquintides

commit sha a52810fc3d246384ca8a74d0f9676bc58e216735

implemented merge operations (#49) * initial draft * modified appveyor.yml for this branch * dropped BOOST_RV_REF as it doesn't handle lvalue refs * befriended index_base from all indices so as to be grant access to final_extract_for_merge_ from an external container * added rvalue ref merge (test expected to fail in C++03) * added explicit boost::move on rvalue ref for the benefit of C++03 compilers * fixed previous workaround * refactored merge algorithm into multi_index_container * added hashed_index::merge * reimplemented sequenced_index::splice(position,x) * added missing this->'s * refactored SFINAEing code * made sequenced_index::splice(position,x) exception robust * reimplemented random_access_index::splice(position,x) * micro-optimized legacy code in random_access_index::splice(position,x) * added missing #include * reimplemented sequenced_index::splice(position,x,i) * reimplemented random_access_index::splice(position,x,i) * reimplemented sequenced_index::splice(position,x,first,last) * reimplemented random_access_index::splice(position,x,first,last) * re-engineered sequenced_index::splice(position,x,i) so that it works when source and destination belong to the same container * stylistic * re-engineered random_access_index::splice(position,x,i) so that it works when source and destination belong to the same container * re-engineered sequenced_index::splice(position,x,first,last) so that it works when source and destination belong to the same container * stylistic * fixed bug in rvalue ref overload of sequenced_index::splice(position,x,first,last) * fixed internal sequenced_index::splice(position,x,first,last) across different indices * re-engineered random_access_index::splice(position,x,first,last) the same way as done with sequenced_index * replaced multi_index_container::merge_ with transfer_range_ so as to refactor some code in non-key-based indices * fixed safe mode check for different-type containers * hardened merge/splice tests * s/BOOST_RV_REF/BOOST_FWD_REF * called the right merge_different overload * fixed problem with Boost.Move C++03 perfect fwd emulation * updated (C) year * allowed intra-container full splice * required position==end() in intra-container full splice * made pointwise splice return a pair<iterator,bool> * added partial merge functionality to key-based indices plus fixed a compile-time error with legacy splice code when applied to different-type indices * suppressed unused variable * fixed wrong signature in splice memfun * made safe-mode iterators SCARY * refactored any_container_view * implemented safe iterator transfer in merge/splice * reorganized internal deps * stylistic * automatically checked iterator invalidation upon merge/splice * removed commented-out code * checked allocator equality * reimplemented random_access_index internal, cross-index splice in linear time * updated docs * reverted appveyor.yml

view details

joaquintides

commit sha 1b38fdcc77c6298a2eb83cb9c7554ad2337b3938

suppressed VS warnings

view details

joaquintides

commit sha 5c8b26cd9bc5f05f7e583ee7e40e9d3325399994

added missing #include's

view details

joaquintides

commit sha d86df5a52f322943a00e5669a37d6407dbc35740

kept max line length below 80 chars

view details

joaquintides

commit sha 0179c2c041f854ec117b4ad5ef9427ba260aeec4

suppressed spurious GCC type-limits warnings

view details

joaquintides

commit sha 2026b94c1284213a4a88c473a13ae7fa0b1212e3

fixed 1b38fdcc77c6298a2eb83cb9c7554ad2337b3938

view details

joaquintides

commit sha 7c3cb660086e752eb827dcddd11cc6618599e5fc

corrected statements on SCARYness

view details

joaquintides

commit sha 6eb3ece5d06551428141045a8c6cd13b34cf8af0

Merge branch 'develop'

view details

push time in 17 days

PR opened boostorg/website

added multi_index release notes
+29 -0

0 comment

1 changed file

pr created time in 17 days

push eventjoaquintides/website

joaquintides

commit sha 2dcd4a49e3cc58fc1a34980f322e41e7ce718879

added multi_index release notes

view details

push time in 17 days

push eventboostorg/multi_index

joaquintides

commit sha 7c3cb660086e752eb827dcddd11cc6618599e5fc

corrected statements on SCARYness

view details

push time in 17 days

push eventboostorg/multi_index

joaquintides

commit sha 2026b94c1284213a4a88c473a13ae7fa0b1212e3

fixed 1b38fdcc77c6298a2eb83cb9c7554ad2337b3938

view details

push time in 18 days

push eventboostorg/multi_index

joaquintides

commit sha 0179c2c041f854ec117b4ad5ef9427ba260aeec4

suppressed spurious GCC type-limits warnings

view details

push time in 20 days

push eventboostorg/multi_index

joaquintides

commit sha 5c8b26cd9bc5f05f7e583ee7e40e9d3325399994

added missing #include's

view details

joaquintides

commit sha d86df5a52f322943a00e5669a37d6407dbc35740

kept max line length below 80 chars

view details

push time in 21 days

push eventboostorg/multi_index

joaquintides

commit sha 1b38fdcc77c6298a2eb83cb9c7554ad2337b3938

suppressed VS warnings

view details

push time in 21 days

issue closedboostorg/multi_index

[Feature request] get element node function for moving an element from the container

Since C++17, associative containers of STL such as std::set have a member function extract(). It returns internal node-handle.

https://en.cppreference.com/w/cpp/container/set/extract https://en.cppreference.com/w/cpp/container/node_handle

If multi_index's containers have the same or similar member function, it is useful especially moving an element from the container. I tried to do that using modify() member function but I couldn't do that. I wrote a move operation in 2nd argument (lambda expression) of modify(). modify() calls the lambda expression and then, does re-arrange process. During the process, the container accesses the moved from object.

Here is a discussion on the stackoverflow: https://stackoverflow.com/questions/57335172/is-there-any-way-to-move-an-element-from-ordered-index-ed-multi-index

I guess multi_index container will be able to have something like extract() member function but I'm not sure it is possible.

closed time in a month

redboltz

issue commentboostorg/config

Wrong CGG expansion of BOOST_ATTRIBUTE_NODISCARD when in -std=c++98 mode

Perfect, thank you! Will keep an eye to this so that I can drop my workaround when your fix gets to release.

joaquintides

comment created time in a month

issue commentboostorg/config

Wrong CGG expansion of BOOST_ATTRIBUTE_NODISCARD when in -std=c++98 mode

No apologies needed :-)

I see otherwise: https://godbolt.org/z/P4dnd4T8q

joaquintides

comment created time in a month

delete branch boostorg/multi_index

delete branch : feature/merge-ready-for-merge

delete time in a month

create barnchboostorg/multi_index

branch : feature/merge-ready-for-merge

created branch time in a month

issue commentboostorg/multi_index

[Feature request] get element node function for moving an element from the container

Hi Takatoshi, Michael,

I completed the job and implemented merge (and extended splice accordingly), see a52810fc3d246384ca8a74d0f9676bc58e216735:

  • Added merge operations to key-based indices. The functionality goes beyond the standard specification for (unordered) associative containers in a number of ways, most notably:
    • The source index can be of any type, including non key-based indices.
    • Partial merge is provided: for instance, x.merge(y,first,last) merges only the elements of y within [first,`lastp ).
  • Previous versions of splice for sequenced and random access indices were destructive, i.e. elements were copy-inserted into the destination and then erased from the source. Now, splice is based on node transfer much as merge in key-based indices, and has been similarly extended to accept source indices of any type: in fact, splice can be regarded as a frontend to the same functionality provided by merge in key-based indices. For reasons of backwards compatibility, the destructive behavior of splice has been retained in the case that the source and destination containers have unequal allocators.
  • The fact has been documented that index iterator types do only depend on node_type, (except for hashed indices, where uniqueness/non-uniqueness is also a dependency). This has implications on the validity of iterators to elements transferred by merge or splice. This property is a variant of what has been called SCARY iterators in the C++ standard mailing lists. SCARYness is currently (August 2021) not mandated for standard containers.
  • Iterator SCARYness is now also preserved in safe mode.

I'd be great if you could play a little with this new functionality and report anything strange you see.

redboltz

comment created time in a month

delete branch boostorg/multi_index

delete branch : feature/merge-ready-for-merge

delete time in a month

push eventboostorg/multi_index

joaquintides

commit sha a52810fc3d246384ca8a74d0f9676bc58e216735

implemented merge operations (#49) * initial draft * modified appveyor.yml for this branch * dropped BOOST_RV_REF as it doesn't handle lvalue refs * befriended index_base from all indices so as to be grant access to final_extract_for_merge_ from an external container * added rvalue ref merge (test expected to fail in C++03) * added explicit boost::move on rvalue ref for the benefit of C++03 compilers * fixed previous workaround * refactored merge algorithm into multi_index_container * added hashed_index::merge * reimplemented sequenced_index::splice(position,x) * added missing this->'s * refactored SFINAEing code * made sequenced_index::splice(position,x) exception robust * reimplemented random_access_index::splice(position,x) * micro-optimized legacy code in random_access_index::splice(position,x) * added missing #include * reimplemented sequenced_index::splice(position,x,i) * reimplemented random_access_index::splice(position,x,i) * reimplemented sequenced_index::splice(position,x,first,last) * reimplemented random_access_index::splice(position,x,first,last) * re-engineered sequenced_index::splice(position,x,i) so that it works when source and destination belong to the same container * stylistic * re-engineered random_access_index::splice(position,x,i) so that it works when source and destination belong to the same container * re-engineered sequenced_index::splice(position,x,first,last) so that it works when source and destination belong to the same container * stylistic * fixed bug in rvalue ref overload of sequenced_index::splice(position,x,first,last) * fixed internal sequenced_index::splice(position,x,first,last) across different indices * re-engineered random_access_index::splice(position,x,first,last) the same way as done with sequenced_index * replaced multi_index_container::merge_ with transfer_range_ so as to refactor some code in non-key-based indices * fixed safe mode check for different-type containers * hardened merge/splice tests * s/BOOST_RV_REF/BOOST_FWD_REF * called the right merge_different overload * fixed problem with Boost.Move C++03 perfect fwd emulation * updated (C) year * allowed intra-container full splice * required position==end() in intra-container full splice * made pointwise splice return a pair<iterator,bool> * added partial merge functionality to key-based indices plus fixed a compile-time error with legacy splice code when applied to different-type indices * suppressed unused variable * fixed wrong signature in splice memfun * made safe-mode iterators SCARY * refactored any_container_view * implemented safe iterator transfer in merge/splice * reorganized internal deps * stylistic * automatically checked iterator invalidation upon merge/splice * removed commented-out code * checked allocator equality * reimplemented random_access_index internal, cross-index splice in linear time * updated docs * reverted appveyor.yml

view details

push time in a month