[dynamic_bitset] Boost.DynamicBitset is back in business
Hi everyone, I'm happy to share that Boost.DynamicBitset is officially back in business! After some years of relative quiet, I'm resuming active maintenance of the library. My goal is to ensure dynamic_bitset continues to be a reliable and efficient tool for bit manipulation in C++ projects. I'll be reviewing open issues and pull requests, modernizing parts of the codebase where appropriate, and welcoming contributions and feedback from the community. If you've been using dynamic_bitset, have ideas for improvements, or just want to help shape its future, now's a great time to get involved. Feel free to reach out, open issues, or start discussions. Looking forward to collaborating with you all. Best, Gennaro
On 3 Sep 2025 20:15, Gennaro Prota via Boost wrote:
Hi everyone,
I'm happy to share that Boost.DynamicBitset is officially back in business!
After some years of relative quiet, I'm resuming active maintenance of the library. My goal is to ensure dynamic_bitset continues to be a reliable and efficient tool for bit manipulation in C++ projects. I'll be reviewing open issues and pull requests, modernizing parts of the codebase where appropriate, and welcoming contributions and feedback from the community.
If you've been using dynamic_bitset, have ideas for improvements, or just want to help shape its future, now's a great time to get involved. Feel free to reach out, open issues, or start discussions.
Looking forward to collaborating with you all.
One thing I didn't see in dynamic_bitset when I was considering alternatives was the ability to allocate a fixed embedded storage, a-la small_vector. Bitsets are often small, so it makes sense to offer this feature.
On Wed, Sep 3, 2025 at 10:25 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
One thing I didn't see in dynamic_bitset when I was considering alternatives was the ability to allocate a fixed embedded storage, a-la small_vector. Bitsets are often small, so it makes sense to offer this feature.
Should this be the same type dynamic_bitset, or perhaps different types such as static_bitset or fixed_bitset? Thanks
On 3 Sep 2025 22:51, Vinnie Falco wrote:
On Wed, Sep 3, 2025 at 10:25 AM Andrey Semashev via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
One thing I didn't see in dynamic_bitset when I was considering alternatives was the ability to allocate a fixed embedded storage, a-la small_vector. Bitsets are often small, so it makes sense to offer this feature.
Should this be the same type dynamic_bitset, or perhaps different types such as static_bitset or fixed_bitset?
Making it the same type would be a breaking change, so a separate type would be the easiest. They could share internal implementation, apart from storage management. And to be clear, small_dynamic_bitset seems like the proper name, as it would use the embedded storage up to the user-specified limit and allocate dynamic storage beyond that. We already have the full static bitset under the name of std::bitset.
On Wed, Sep 3, 2025 at 1:03 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
...allocate dynamic storage beyond that
I see, so this is a flavor of small buffer optimization. And std::bitset is the equivalent of the fixed_bitset or maybe static_bitset, can't recall which (a fixed number of elements determine at compile-time). What do you call the bitset whose size can change yet the capacity of the bitset is fixed at compile time? Or is that not a use-case typically desired? (i.e. boost::static_string is that container for strings). Thanks
On 3 Sep 2025 23:17, Vinnie Falco wrote:
What do you call the bitset whose size can change yet the capacity of the bitset is fixed at compile time?
Following Boost.Container convention, that would be static_dynamic_bitset, but that sounds silly, so static_bitset.
Or is that not a use-case typically desired? (i.e. boost::static_string is that container for strings).
It would probably offer a some size advantage over small_bitset. Specifically, it wouldn't have to track capacity and pointer to storage.
On Wed, Sep 3, 2025, at 10:36 PM, Andrey Semashev via Boost wrote:
On 3 Sep 2025 23:17, Vinnie Falco wrote:
What do you call the bitset whose size can change yet the capacity of the bitset is fixed at compile time?
Following Boost.Container convention, that would be static_dynamic_bitset, but that sounds silly, so static_bitset.
In counterpoint, Boost.Container also has `flat_map` and friends that take a `AllocatorOrContainer` template argument deciding on the storage. E.g. `bc::flat_set<T, std::less<T>, bc::small_vector<T, 15> >`. I'd prefer `dynamic_bitset<uint16_t, bc::small_vector<uint16_t, 8> >` if possible, preventing a proliferation of storage flavors for the sake of it. Of course, whether this is feasible depends mostly on whether the concerns are (can be) separated. Seth
El 04/09/2025 a las 2:01, Seth via Boost escribió:
On Wed, Sep 3, 2025, at 10:36 PM, Andrey Semashev via Boost wrote:
On 3 Sep 2025 23:17, Vinnie Falco wrote:
What do you call the bitset whose size can change yet the capacity of the bitset is fixed at compile time?
Following Boost.Container convention, that would be static_dynamic_bitset, but that sounds silly, so static_bitset.
In counterpoint, Boost.Container also has `flat_map` and friends that take a `AllocatorOrContainer` template argument deciding on the storage.
E.g. `bc::flat_set<T, std::less<T>, bc::small_vector<T, 15> >`.
Maybe we could add a bitset implementation to the library that could use a user-provided container as data/word storage. A user could use a deque, a custom vector or whatever random-access capable sequence... Best, Ion
Le mercredi 03 septembre 2025 à 23:36 +0300, Andrey Semashev via Boost a écrit :
On 3 Sep 2025 23:17, Vinnie Falco wrote:
What do you call the bitset whose size can change yet the capacity of the bitset is fixed at compile time?
Following Boost.Container convention, that would be static_dynamic_bitset, but that sounds silly, so static_bitset.
That would be consistent with boost::static_string. As noted by others, a fixed-size bitset already existed for ages, i don't think there's a need for one in boost, unless it has some extra features.
Or is that not a use-case typically desired? (i.e. boost::static_string is that container for strings).
It would probably offer a some size advantage over small_bitset. Specifically, it wouldn't have to track capacity and pointer to storage.
+1 For the obvious changes / improvements for any bitset, changing the constructor from std::string to string_view instead is a good starter. Regards, Julien
On 9/4/2025 8:00 AM, Julien Blanc via Boost wrote: [...]
For the obvious changes / improvements for any bitset, changing the constructor from std::string to string_view instead is a good starter.
Yes, I was thinking about that, too. It's a breaking change (think of a type with a user-defined conversion to std::string) but maybe worth it. -- Gennaro Prota <https://prota.dev>
On 9/3/2025 7:23 PM, Andrey Semashev via Boost wrote: [...]
One thing I didn't see in dynamic_bitset when I was considering alternatives was the ability to allocate a fixed embedded storage, a-la small_vector. Bitsets are often small, so it makes sense to offer this feature.
One way to provide this is to allow passing an "allocator or container" template argument. That would allow using boost::container::small_vector as the underlying block container. However, dynamic_bitset needs a container that has reserve() and capacity(), so there are not many containers that could be actually used. -- Gennaro Prota <https://prota.dev>
Hi Gennaro, I use DynamicBitset in several places in OpenMethod. Thanks for creating it! I remember missing two features. 1. Iterators. There was a PR from a user for that (https://github.com/boostorg/dynamic_bitset/pull/73), but I reckon that it was a little naive. 2. A function similar to find_first, but for locating the first "off" bit. J-L On Wed, Sep 3, 2025 at 1:17 PM Gennaro Prota via Boost <boost@lists.boost.org> wrote:
Hi everyone,
I'm happy to share that Boost.DynamicBitset is officially back in business!
After some years of relative quiet, I'm resuming active maintenance of the library. My goal is to ensure dynamic_bitset continues to be a reliable and efficient tool for bit manipulation in C++ projects. I'll be reviewing open issues and pull requests, modernizing parts of the codebase where appropriate, and welcoming contributions and feedback from the community.
If you've been using dynamic_bitset, have ideas for improvements, or just want to help shape its future, now's a great time to get involved. Feel free to reach out, open issues, or start discussions.
Looking forward to collaborating with you all.
Best, Gennaro _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/LUMO6OE2...
On 9/3/2025 9:15 PM, Jean-Louis Leroy wrote:
Hi Gennaro,
I use DynamicBitset in several places in OpenMethod. Thanks for creating it!
Hi Jean-Louis, the library was originally created by Jeremy Siek. But it looked very different from now. I re-implemented it completely, added features, etc.
I remember missing two features.
1. Iterators. There was a PR from a user for that (https://github.com/boostorg/dynamic_bitset/pull/73), but I reckon that it was a little naive.
DynamicBitset doesn't provide iterators, and doesn't pretend to be a container, because of the proxy reference type, which prevents iterators to satisfy the standard requirements. IOW, even if it provided iterators, they wouldn't be usable with the standard algorithms.
2. A function similar to find_first, but for locating the first "off" bit.
Hmm... I'll implement that. Thanks for the suggestion :-). -- Gennaro Prota <https://prota.dev>
1. Iterators. There was a PR from a user for that (https://github.com/boostorg/dynamic_bitset/pull/73), but I reckon that it was a little naive.
DynamicBitset doesn't provide iterators, and doesn't pretend to be a container, because of the proxy reference type, which prevents iterators to satisfy the standard requirements. IOW, even if it provided iterators, they wouldn't be usable with the standard algorithms.
Is this still the case with C++20 ranges? AFAIK the forward iterator requirements were made less strict to support such cases. In gcc 15, the following static_assert succeeds: static_assert(std::forward_iterator<std::vector<bool>::iterator>); And the iterators/ranges seem usable in standard algorithms: https://godbolt.org/z/6P5MYTKG6
On 9/4/2025 1:35 PM, Ruben Perez wrote: [...]
DynamicBitset doesn't provide iterators, and doesn't pretend to be a container, because of the proxy reference type, which prevents iterators to satisfy the standard requirements. IOW, even if it provided iterators, they wouldn't be usable with the standard algorithms.
Is this still the case with C++20 ranges? AFAIK the forward iterator requirements were made less strict to support such cases. In gcc 15, the following static_assert succeeds:
static_assert(std::forward_iterator<std::vector<bool>::iterator>);
And the iterators/ranges seem usable in standard algorithms: https://godbolt.org/z/6P5MYTKG6
Yes. So do you suggest adding iterators only when DynamicBitset is compiled as C++20 or later? -- Gennaro Prota <https://prota.dev>
On Thu, 4 Sep 2025 at 17:35, Gennaro Prota <gennaro.prota@gmail.com> wrote:
On 9/4/2025 1:35 PM, Ruben Perez wrote: [...]
DynamicBitset doesn't provide iterators, and doesn't pretend to be a container, because of the proxy reference type, which prevents iterators to satisfy the standard requirements. IOW, even if it provided iterators, they wouldn't be usable with the standard algorithms.
Is this still the case with C++20 ranges? AFAIK the forward iterator requirements were made less strict to support such cases. In gcc 15, the following static_assert succeeds:
static_assert(std::forward_iterator<std::vector<bool>::iterator>);
And the iterators/ranges seem usable in standard algorithms: https://godbolt.org/z/6P5MYTKG6
Yes. So do you suggest adding iterators only when DynamicBitset is compiled as C++20 or later?
I'd add them unconditionally. C++11 users can use them to iterate, and C++20 users can use them in algorithms, too. AFAIK what changed were the requirements, so no code needs to be guarded with a C++20 guard. Note that I'm not a user of the library, so don't take this as a feature request, but as a mere suggestion. Regards, Rubén.
-- Gennaro Prota <https://prota.dev>
Le 2025-09-05 14:03, Ruben Perez via Boost a écrit :
On Thu, 4 Sep 2025 at 17:35, Gennaro Prota <gennaro.prota@gmail.com> wrote:
On 9/4/2025 1:35 PM, Ruben Perez wrote: [...]
DynamicBitset doesn't provide iterators, and doesn't pretend to be a container, because of the proxy reference type, which prevents iterators to satisfy the standard requirements. IOW, even if it provided iterators, they wouldn't be usable with the standard algorithms.
Is this still the case with C++20 ranges? AFAIK the forward iterator requirements were made less strict to support such cases. In gcc 15, the following static_assert succeeds:
static_assert(std::forward_iterator<std::vector<bool>::iterator>);
And the iterators/ranges seem usable in standard algorithms: https://godbolt.org/z/6P5MYTKG6
Yes. So do you suggest adding iterators only when DynamicBitset is compiled as C++20 or later?
I'd add them unconditionally. C++11 users can use them to iterate, and C++20 users can use them in algorithms, too. AFAIK what changed were the requirements, so no code needs to be guarded with a C++20 guard.
There's still the performance issue, though. I can see some value with const iteration, but anything that is modifying the bitset using iterators is, well, let's say probably far from optimal. I'm not sure encouraging such misuse is a good idea. Regards, Julien
On 9/4/2025 11:33 AM, Gennaro Prota wrote: [...]
2. A function similar to find_first, but for locating the first "off" bit.
Hmm... I'll implement that. Thanks for the suggestion :-).
I'm thinking of a way to avoid introducing a new member function for that. Adding a (defaulted) bool parameter to the existing find_first()'s, like this: size_type find_first( bool value = true ) const; size_type find_first( size_type pos, bool value = true ) const; would make a call like b.find_first( 1 ) ambiguous. An idea could be: enum class bit_value { set, unset }; size_type find_first( bit_value value = bit_value::set ) const; size_type find_first( size_type pos, bit_value value = bit_value::set ) const; but that would be inconsistent with the rest of the library. -- Gennaro Prota <https://prota.dev>
On 4 Sep 2025 18:22, Gennaro Prota via Boost wrote:
On 9/4/2025 11:33 AM, Gennaro Prota wrote: [...]
2. A function similar to find_first, but for locating the first "off" bit.
Hmm... I'll implement that. Thanks for the suggestion :-).
I'm thinking of a way to avoid introducing a new member function for that. Adding a (defaulted) bool parameter to the existing find_first()'s, like this:
size_type find_first( bool value = true ) const; size_type find_first( size_type pos, bool value = true ) const;
would make a call like b.find_first( 1 ) ambiguous. An idea could be:
enum class bit_value { set, unset };
size_type find_first( bit_value value = bit_value::set ) const; size_type find_first( size_type pos, bit_value value = bit_value::set ) const;
but that would be inconsistent with the rest of the library.
Using an argument makes sense when there are use cases when the parameter value is obtained at run time. Then the parameter allows the user to avoid spelling out the branch. My impression is that this is not the case. You almost always know at compile time which behavior you want, as this is usually part of the higher level algorithm. It would make sense to have different names for different operations in this case. Furthermore, find_first (zero or one) is typically implemented using a dedicated CPU instruction, possibly in a loop. I think, such CPU instructions implement only one search (again, either zero or one). If you add the parameter, you would be introducing a branch which would otherwise be not needed. So, my preference would be separate methods.
1. Iterators. There was a PR from a user for that (https://github.com/boostorg/dynamic_bitset/pull/73), but I reckon that it was a little naive.
DynamicBitset doesn't provide iterators, and doesn't pretend to be a container, because of the proxy reference type, which prevents iterators to satisfy the standard requirements. IOW, even if it provided iterators, they wouldn't be usable with the standard algorithms.
std::vector<bool> provides iterators, and it's standard ;-)
On 9/4/2025 11:33 AM, Gennaro Prota wrote:
I remember missing two features. [...] 2. A function similar to find_first, but for locating the first "off" bit.
Hmm... I'll implement that. Thanks for the suggestion :-).
FYI, I've implemented these: size_type find_first_off() const; size_type find_first_off( size_type pos ) const; size_type find_next_off( size_type pos ) const; I think I'll now implement the possibility to change the underlying buffer type ("allocator or container" template parameter). Thanks again. -- Gennaro Prota <https://prota.dev>
On 5 Sep 2025 17:52, Gennaro Prota via Boost wrote:
I think I'll now implement the possibility to change the underlying buffer type ("allocator or container" template parameter).
One downside with the "allocator or container" approach is that you would have to duplicate the size of the container. The embedded container will maintain its size as the number of words, but the last word in the bitset may be incomplete, so the bitset will have to have a size of its own.
On 9/5/2025 5:47 PM, Andrey Semashev via Boost wrote:
On 5 Sep 2025 17:52, Gennaro Prota via Boost wrote:
I think I'll now implement the possibility to change the underlying buffer type ("allocator or container" template parameter).
One downside with the "allocator or container" approach is that you would have to duplicate the size of the container. The embedded container will maintain its size as the number of words, but the last word in the bitset may be incomplete, so the bitset will have to have a size of its own.
That was already the case. So far, dynamic_bitset used a std::vector< Block, Allocator >. Now, it will either use that or the provided container type. -- Gennaro Prota <https://prota.dev>
On 5 Sep 2025 20:22, Gennaro Prota wrote:
On 9/5/2025 5:47 PM, Andrey Semashev via Boost wrote:
On 5 Sep 2025 17:52, Gennaro Prota via Boost wrote:
I think I'll now implement the possibility to change the underlying buffer type ("allocator or container" template parameter).
One downside with the "allocator or container" approach is that you would have to duplicate the size of the container. The embedded container will maintain its size as the number of words, but the last word in the bitset may be incomplete, so the bitset will have to have a size of its own.
That was already the case. So far, dynamic_bitset used a std::vector< Block, Allocator >. Now, it will either use that or the provided container type.
This is unfortunate. I wish this was optimized as well.
No dia 5 de set. de 2025, às 21:51, Andrey Semashev via Boost <boost@lists.boost.org> escreveu:
On 5 Sep 2025 20:22, Gennaro Prota wrote:
On 9/5/2025 5:47 PM, Andrey Semashev via Boost wrote: On 5 Sep 2025 17:52, Gennaro Prota via Boost wrote:
I think I'll now implement the possibility to change the underlying buffer type ("allocator or container" template parameter).
One downside with the "allocator or container" approach is that you would have to duplicate the size of the container. The embedded container will maintain its size as the number of words, but the last word in the bitset may be incomplete, so the bitset will have to have a size of its own.
That was already the case. So far, dynamic_bitset used a std::vector< Block, Allocator >. Now, it will either use that or the provided container type.
This is unfortunate. I wish this was optimized as well.
What kind of optimization do you have in mind? I don’t think using std::vector as the backend can really introduce any performance penalty. Joaquín M López Muñoz
On 5 Sep 2025 23:01, Joaquín M López Muñoz wrote:
No dia 5 de set. de 2025, às 21:51, Andrey Semashev via Boost <boost@lists.boost.org> escreveu:
On 5 Sep 2025 20:22, Gennaro Prota wrote:
On 9/5/2025 5:47 PM, Andrey Semashev via Boost wrote:
One downside with the "allocator or container" approach is that you would have to duplicate the size of the container. The embedded container will maintain its size as the number of words, but the last word in the bitset may be incomplete, so the bitset will have to have a size of its own.
That was already the case. So far, dynamic_bitset used a std::vector< Block, Allocator >. Now, it will either use that or the provided container type.
This is unfortunate. I wish this was optimized as well.
What kind of optimization do you have in mind? I don’t think using std::vector as the backend can really introduce any performance penalty.
If dynamic_bitset managed storage by itself, it could track only the number of bits in the container and derive the number of words from it. This would reduce the size of the container object. Yes, this would be incompatible with the "allocator or container" approach, but it would be more optimal.
El 05/09/2025 a las 22:01, Joaquín M López Muñoz via Boost escribió:
No dia 5 de set. de 2025, às 21:51, Andrey Semashev via Boost <boost@lists.boost.org> escreveu:
On 5 Sep 2025 20:22, Gennaro Prota wrote:
On 9/5/2025 5:47 PM, Andrey Semashev via Boost wrote: On 5 Sep 2025 17:52, Gennaro Prota via Boost wrote:
I think I'll now implement the possibility to change the underlying buffer type ("allocator or container" template parameter).
One downside with the "allocator or container" approach is that you would have to duplicate the size of the container. The embedded container will maintain its size as the number of words, but the last word in the bitset may be incomplete, so the bitset will have to have a size of its own.
That was already the case. So far, dynamic_bitset used a std::vector< Block, Allocator >. Now, it will either use that or the provided container type.
This is unfortunate. I wish this was optimized as well.
What kind of optimization do you have in mind? I don’t think using std::vector as the backend can really introduce any performance penalty.
I think Andrey was talking about a "sizeof(dynamic_bitset)" optimization (optimal when your application has lots many empty dynamic_bitsets, maybe because this bitset is optional). But I might have interpreted this incorrectly ;-) Best, Ion
On 6 Sep 2025 11:42, Ion Gaztañaga via Boost wrote:
El 05/09/2025 a las 22:01, Joaquín M López Muñoz via Boost escribió:
No dia 5 de set. de 2025, às 21:51, Andrey Semashev via Boost <boost@lists.boost.org> escreveu:
On 5 Sep 2025 20:22, Gennaro Prota wrote:
On 9/5/2025 5:47 PM, Andrey Semashev via Boost wrote: On 5 Sep 2025 17:52, Gennaro Prota via Boost wrote:
I think I'll now implement the possibility to change the underlying buffer type ("allocator or container" template parameter).
One downside with the "allocator or container" approach is that you would have to duplicate the size of the container. The embedded container will maintain its size as the number of words, but the last word in the bitset may be incomplete, so the bitset will have to have a size of its own.
That was already the case. So far, dynamic_bitset used a std::vector< Block, Allocator >. Now, it will either use that or the provided container type.
This is unfortunate. I wish this was optimized as well.
What kind of optimization do you have in mind? I don’t think using std::vector as the backend can really introduce any performance penalty.
I think Andrey was talking about a "sizeof(dynamic_bitset)" optimization (optimal when your application has lots many empty dynamic_bitsets, maybe because this bitset is optional).
Yes, correct.
El 03/09/2025 a las 19:15, Gennaro Prota via Boost escribió:
Hi everyone,
I'm happy to share that Boost.DynamicBitset is officially back in business!
After some years of relative quiet, I'm resuming active maintenance of the library. My goal is to ensure dynamic_bitset continues to be a reliable and efficient tool for bit manipulation in C++ projects. I'll be reviewing open issues and pull requests, modernizing parts of the codebase where appropriate, and welcoming contributions and feedback from the community.
If you've been using dynamic_bitset, have ideas for improvements, or just want to help shape its future, now's a great time to get involved. Feel free to reach out, open issues, or start discussions.
Looking forward to collaborating with you all.
Best, Gennaro
Great news Gennaro! Boost has great containers, some based/replacing std components but with better/different features and other new container types with useful use cases. We should probably do some PR effort on this front explaining why Boost containers are great and why/when you should use them instead of std ones in many cases. One related area (maybe another library?) could be to have some bit scanning and manipulation routines or different containers. One (old) library that could be used as inspiration could be Bitscan (now, integrated in BitGraph https://github.com/psanse/BitGraph/tree/master/src/bitscan), which has GNU license. Best, Ion
Hi, following the discussion so far, I've added: - Three new members for zero-bit search: find_first_off(), find_first_off( size_type ) and find_next_off( size_type ). I'm considering merging the first two (and, consistently, the two overloads of find_first(), which search for 1 bits). - Custom container support: You can now specify the underlying container via an `AllocatorOrContainer` template argument. The unit tests exercise this with boost::container::small_vector. - C++20 iterators. The implementation for all of this is here: <https://github.com/boostorg/dynamic_bitset/tree/pr/dynamic_biset_is_back_in_business_mailing_list_discussion_sept_3_2025>. Comments welcome. Unfortunately, the CI shows many failures in seemingly unrelated code. I'll have to look into it. -- Gennaro Prota <https://prota.dev>
On 9/9/2025 7:02 PM, Gennaro Prota wrote:
[...] The implementation for all of this is here:
<https://github.com/boostorg/dynamic_bitset/tree/pr/ dynamic_biset_is_back_in_business_mailing_list_discussion_sept_3_2025>.
Comments welcome. Unfortunately, the CI shows many failures in seemingly unrelated code. I'll have to look into it.
The code is now in the develop branch, and all CI issues have been resolved. Comments still very welcome :-). BTW, would it be OK to merge develop into master at this point? -- Gennaro Prota <https://prota.dev>
On Wed, Sep 10, 2025 at 8:24 AM Gennaro Prota via Boost < boost@lists.boost.org> wrote:
Comments still very welcome :-). BTW, would it be OK to merge develop into master at this point?
I don't think we are in the middle of a release cycle? You can always check the calendar: https://www.boost.org/calendar/ Thanks
participants (9)
-
Andrey Semashev -
Gennaro Prota -
Ion Gaztañaga -
Jean-Louis Leroy -
Joaquín M López Muñoz -
Julien Blanc -
Ruben Perez -
Seth -
Vinnie Falco