thelink2012 / any Goto Github PK

When using a recent g++ and libstdc++ with -D_GLIBCXX_USE_CXX11_ABI=0, or an older version of g++, sizeof(std::string) is one word. In that case the std::string is placed in stack storage. However, this causes a segmentation fault in some cases.

You can also reproduce this issue with the new ABI and libc++ by increasing the size of stack_storage_t to 4 * sizeof(void*).

Here's a code sample that reproduces the issue:

#include "any.hpp"

#include <iostream>

std::string asString(const linb::any &v)
{
  if (v.type() == typeid(std::string))
    return linb::any_cast<std::string>(v);
  else
    return "";
}

int main()
{
  linb::any a;
  {
    a = std::string("test");
  }
  std::cout << "a: " << asString(a) << std::endl;
}

When storing a type larger than the stack storage, GCC 6 appears to incorrectly warn that the stack storage is too small, even though heap allocation is used.

See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70834

You could maybe disable this warning? That's what the person who reported the issue to us did: http://redmine.webtoolkit.eu/issues/5465

Probably draft was updated since the original implementation. These member functions are very essential AFAIK.

Reference:
http://en.cppreference.com/w/cpp/utility/any

Now that we know LWG Defect 2509 has been accepted and C++17 compilers implement it, is there any reason linb::any_cast should continue adhering strictly to the N4562 proposal and keep opting-in to moving rvalues?

I would prefer to have the move-feature enabled by default and opt-out if at all necessary.

I used any to storage the type of wstring value, when I get the value, any_cast will be failed.

In file included from /opt/local/var/macports/build/_Users_runner_work_macports-ports_macports-ports_ports_devel_any/any/work/any-bfc77f2e4be6e9a093dd645ef3f1aa30620c9205/test_shared_lib.hpp:3:
  /opt/local/var/macports/build/_Users_runner_work_macports-ports_macports-ports_ports_devel_any/any/work/any-bfc77f2e4be6e9a093dd645ef3f1aa30620c9205/any.hpp:279:13: error: no matching 'operator new' function for non-allocating placement new expression; include <new>
              new (&dest.stack) T(reinterpret_cast<const T&>(src.stack));
              ^~~

Full log: https://github.com/macports/macports-ports/actions/runs/3944844343/jobs/6751175466

Is it possible to version this impl of an any? Either with a branch or a tag? I've started using it and we prefer to be using versioned releases rather than the bleeding edge.

Corresponding paper https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1413r3.pdf and discussions cplusplus/papers#197. In short, the recommended replacement is :

std::aligned_storage<sizeof(T), alignof(T)> storage;
// becomes:
alignas(T) unsigned char storage[sizeof(T)];

It looks like the type checking is done by several function pointer comparisons (vtable). I've noticed that if I put a std::string in a linb::any in one dll, and try to extract it in another (even by reference), it always throws a bad_cast exception.

Digging into it, it looks like the vtable pointers are set for the std::string in the dll that sets the linb::any, but when I try to cast the std::string out, it fails because it creatse a new vtable in the casting dll.

Does it make sense to use type_info to compare types?

Update: I have not tested this in linux.

Compilation for embedded platforms is typically missing exception handling and RTTI.
It would be nice to check the availability of those features like gcc does.

Furthermore, a different implementation of any_cast would solve the performance cost incurred by type_id comparisons.

See pull request #8

According to cppreference documentation (can't find the latest draft), the C++17 interface for std::any is a bit different from the one we are basing on, std::experimental::any. Function names changed and a few were added.

What should we do? Migrate to the new interface? Keep this?

Suggestions are very welcome.

Additional Info:

• Before
• After