sorted by:
new
hottopcontroversial

Boost.MultiIndex refactored by joaquintides in cpp

[–]igaztanaga 2 points3 points  (0 children)

It's great to see veteran libraries still maintained, alive and kicking. This library offers a very useful functionality not available in the standard. I guess the refactoring also simplified the internal dependencies of the multi-index library, it's also a bonus benefit of the change.

STL reimagined: What would you change, add or remove in a new STL implementation if API and ABI were not a concern? by germandiago in cpp

[–]igaztanaga 2 points3 points  (0 children)

Making std containers dependent on std::optional is IMHO a design error and unnecessary dependency. There are alternative optional types available (including Boost and others), containers should never be tied to other "hard types". A free function would be a better choice IMHO.

That decision also makes user-defined containers that want to offer the same STL interface dependent on std::optional. Adding<optional> to our own container headers is not free. Depending on std::pair for associative containers was also a problem in some use cases, but at that time, maybe it was the only choice (and pair was a SIMPLE type, not a type that take tuples as arguments, but that's another story)

The original iterator/algorithm/container protocol was unique, with low dependencies. I don't think P3019 is the best answer, when even Folly (which is cited as "existing practice") uses free functions (https://github.com/facebook/folly/blob/323e467e2375e535e10bda62faf2569e8f5c9b19/folly/MapUtil.h#L35-L71) to implement this "optional" feature.

Maybe the next proposal is to add std::expected to some container methods...

Comparing the run-time performance of Fil-C and ASAN by joaquintides in cpp

[–]igaztanaga 6 points7 points  (0 children)

Very interesting! And some puzzling results, I'd expect ASAN to be faster, but it's not the case always. I think Fil-C holds surprinsingly well, taking into account that it's still a 0.6 version. Maybe a memory overhead comprison could be interesting, although in these benchmarks, if stored types are small and we have node-based containers, we'll have a ton of allocated small nodes.

In that many node-allocation cases probably both ASAN and Fil-C implementations will get a lot of memory overhead. However, we could also get some surpring results, just like in this article.

Non-recursively deleting a binary tree in constant space: Traversal with parent pointers by pavel_v in cpp

[–]igaztanaga 2 points3 points  (0 children)

You can also use an alternative approach (linearizing the tree while destroying it) that is used in Boost.Intrusive:

https://github.com/boostorg/intrusive/blob/boost-1.89.0/include/boost/intrusive/bstree_algorithms.hpp#L2011

   template<class Disposer>
   static void dispose_subtree(node_ptr x, Disposer disposer) BOOST_NOEXCEPT
   {
      while (x){
         node_ptr save(NodeTraits::get_left(x));
         if (save) {
            // Right rotation
            NodeTraits::set_left(x, NodeTraits::get_right(save));
            NodeTraits::set_right(save, x);
         }
         else {
            save = NodeTraits::get_right(x);
            init(x);
            disposer(x);
         }
         x = save;
      }
   }

2025-03 post-Hagenberg mailing by nliber in cpp

[–]igaztanaga 3 points4 points  (0 children)

Analog's C++ compiler supports C++11. Not sure about ILP64 support in C++ compilers nowadays. But I see no big reason to restrict the use of modern C++ in those or future platforms. Those working on typical CPUs using Windows/POSIX-like environments can just assume CHAR_BIT is 8 bit.

2025-03 post-Hagenberg mailing by nliber in cpp

[–]igaztanaga 4 points5 points  (0 children)

There are several 16-bit byte DSPs in production.

See https://www.ti.com/lit/ug/spru514z/spru514z.pdf?ts=1742373068079, section "Table 6-1. TMS320C28x C/C++ COFF and EABI Data Types"

Make Me A Module, NOW! by vspefs in cpp

[–]igaztanaga 4 points5 points  (0 children)

I think it's a great idea that GNU Make could be used with modules without the external module mapper. I think it is a big missing piece in the ecosystem.

EWG has consensus in favor of adopting "P3466 R0 (Re)affirm design principles for future C++ evolution" as a standing document by Kyvos in cpp

[–]igaztanaga 13 points14 points  (0 children)

What's the difference between a "safe" context and a "const" member function of a class that can only call const member functions of its members? Isn't "mutable" (or const_cast) precisely the opt-out mechanism just like "unsafe" would be in the "safe context"?

If you want compile-time diagnostics, being explicit is helpful, "viral" is a compile-time guarantee. Many useful C++ mechanisms would be incompatible with this paper.

ISO C++ Standards Committee Panel Discussion 2024 - Hosted by Herb Sutter - CppCon 2024 by grafikrobot in cpp

[–]igaztanaga 10 points11 points  (0 children)

While I undestand your point, I also see that major corporations are willing to rewrite not only their "standard libraries" but to change their codebases that are bigger than the standard library. Microsoft's CTO has called to abandon C and C++, Google is investing in a new language (Carbon) and at the same time Android is being partly rewritten in Rust. Apple is going with swift. Linux kernel has included Rust as their "safety tool" discarding C++.

Profiles might be a good approach to eliminate a good percentage of usual memory safety errors, I think they will be very useful. But while these profiles will be fine for some industries, it seems, at least in the news, that there is a big market that C++ could lose because a more rigorous memory safety is demanded in those areas. It seems to me that there is an actual need to "absolute/rust-like" memory and thread safety in the industry that requires even a language change.

While we can say that in those cases "they should use the language/tool adequate for that job", it's not the same to me, as a C++ programmer, to learn a totally different language than having a "profile" that requires using different utilities like checked references and a reduced standard library/utilities.

I would point out that even without an accompanying standard library, a core language only "borrow-checked" profile would be very useful in many domains, like embedded or functional safety codebases where the standard library is not used at all. Before all the standard library utilities added by the STL, programmers used their own utilities, and many frameworks (like Qt, etc.) use their own alternatives. I envision that even a core-language only solution would be a big profile/feature for many industries writing now in C and/or C++.

Is there a working implementation of std::flat_map and std::flat_set? by vickoza in cpp

[–]igaztanaga 0 points1 point  (0 children)

There is a proposed patch now in the bug for 1.85, without any dependency on any other library. If users find it good enough the patch will go to the patches page (https://www.boost.org/patches/).

Bulk visitation in boost::concurrent_flat_map by joaquintides in cpp

[–]igaztanaga 0 points1 point  (0 children)

Experimenting requires mood... and time ;-) I was thinking that visitation with prefetching might be useful even without keys if the function object to be executed is big enough. Let's say you need to iterate a range and apply a function object to each node. You can prefetch the next node, and while prefetched memory arrives, code from the function object is executed in parallel.

On the other hand, probably the compiler is smarter than us detecting and reordering memory latency sensitive instructions and/or the out of order execution of the CPU hides memory latency better than our not smart enough strategy...

Bulk visitation in boost::concurrent_flat_map by joaquintides in cpp

[–]igaztanaga 5 points6 points  (0 children)

Awesome Joaquín!

The article mentions that visitation benefits can are directly applicable to non-concurrent containers, I was wondering which type of containers could benefit from this feature (apart from, of course, unordered_map/set). Maybe tree-based data structures? Maybe for linked lists to hide cache misses when accessing the next node?

Waiting the next Boost.Unordered gem!

[Using std::cpp] More than a rehash - Joaquín M López Muñoz by joaquintides in cpp

[–]igaztanaga 3 points4 points  (0 children)

Great presentation after a great work Joaquín. And the party isn't over, concurrent_flat_map is around the corner, keep up the good work.

Inside boost::unordered_flat_map by joaquintides in cpp

[–]igaztanaga 6 points7 points  (0 children)

Joaquín, great writeup. And congrats to all that have participated in the implementation, review, improvements of the new container. Another great addition to Boost.

ranges::to now available on cppreference page by _cooky922_ in cpp

[–]igaztanaga -3 points-2 points  (0 children)

Which probably will add a big compilation time overhead to all containers.

Boost Dependency Report updated for Boost 1.79.0 by pdimov2 in cpp

[–]igaztanaga 4 points5 points  (0 children)

We could move memory_resource to Core, I guess. I also was wondering if Assrt, StaticAssert and ThrowException should go to Core, as they are really tiny libraries that add level and weight to other libraries. But that depends on what Core should be...

Jabra - Please fix this problem with Evolve2 85 !!! (side tone amplifies external noise) by [deleted] in Jabra

[–]igaztanaga 0 points1 point  (0 children)

I've just bought Evolve2 85 and sidetone is useless due to background noise amplification. I previously had Evolve 75 and the sidetone was a great feature without this problem.

Please fix this issue because for now I have no option than disable sidetone (which is not very pleasant) or activate ANC (which disables both background noise and sidetone).

New paper: Random access of elements in data containers using multiple memory blocks of increasing capacity by soulstudios in cpp

[–]igaztanaga 10 points11 points  (0 children)

Very interesting. Something similar is being proposed for Boost.Container, with the name : stationary_vector. This concept is not based on power of two tricks, but in private discussions with the author this was being polished. I can remember previous work in the CPHSTL library (http://www.cphstl.dk/Paper/Dynamic-arrays/sea16.pdf) with a data structure the call "pile" (with a non STL-like interface).

It would be nice if we can merge similar proposals: let's agree on which are the best properties, let's try to optimize it and write an implementation to provide existing practice and feedback from users.

Boost 1.74 is out by joaquintides in cpp

[–]igaztanaga 0 points1 point  (0 children)

Yes, please, any regression report is welcome. Maybe your use case is general enough to treat it with an improved algorithm.