Opened 13 years ago

Closed 13 years ago

Last modified 12 years ago

#3400 closed Bugs (fixed)

Problem with boost::serialization when only operator new[] is overrided

Reported by: Runar Undheim <r.undheim@…> Owned by: Robert Ramey
Milestone: Boost 1.41.0 Component: serialization
Version: Boost 1.40.0 Severity: Problem
Keywords: Cc:

Description

Compilation error in serialization when only operator new[] is overrided. It should also be possible to set operator new[] as private, but that will give another error.

#include <stdio.h>
#include <tchar.h>
#include <fstream>

#include <boost/type_traits.hpp>
#include <boost/type_traits/has_new_operator.hpp>

#include <boost/archive/binary_oarchive.hpp>
#include <boost/archive/binary_iarchive.hpp>
#include <boost/serialization/export.hpp>
#include <boost/serialization/shared_ptr.hpp>

class A {

  friend class boost::serialization::access;

  template<class Archive>
  void serialize(Archive & ar, const unsigned int version)
  { ar & m_i; }

  int
    m_i;

public:

  void* operator new[](std::size_t)
  {
    return NULL;
  }
};

BOOST_CLASS_EXPORT(A)

int _tmain(int argc, _TCHAR* argv[])
{
  A
    *pa;

  std::ifstream ifs("test", std::ios_base::in | std::ios_base::binary);
  {
    boost::archive::binary_iarchive ia(ifs);
    ia >> *pa;
  }
  return 0;
}

Change History (6)

comment:1 by Runar Undheim <r.undheim@…>, 13 years ago

The serialization code use the has_new_operator to decide if it should call T::new or ::new. But what should happen if only the operation new for arrays is overridden? If T::new function only should be called when the operator new(size_t) is overridden then the has_new_operator function may be split into three different functions (ex. has_new_operator, has_new_operator_array and has_new_operator_placement)?

comment:2 by Runar Undheim <r.undheim@…>, 13 years ago

Related to ticket #3401

comment:3 by Robert Ramey, 13 years ago

A very intricate issue. You've spent some time on it already. Would you care to spend a little more and create a patch that we could evaluate?

Robert Ramey

comment:4 by Robert Ramey, 13 years ago

Status: newassigned

comment:5 by Robert Ramey, 13 years ago

Resolution: fixed
Status: assignedclosed

I believe this is fixed by a patch to the trunk in the type_traits library.

Robert Ramey

comment:6 by Gael, 12 years ago

This issue doesn't appear to be fixed. I can reproduce the compilation errors when operator new[] is overloaded. Boost is still trying to call the (T::operator new) version to allocate the object.

Note: See TracTickets for help on using tickets.