Re: This HAS to be UB...
On Oct 2, 9:52 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
Keep in mind that I am a C programmer; well, anyway here is
the C++ program...
It looks to me like you're attacking some fairly tricky stuff.
You'd probably be better of starting with something simpler if
you're still learning C++. However...
______________________________________________________________________
#include <cstdio>
#include <cstdlib>
#include <new>
struct custom_allocator {
static void* allocate(std::size_t size)
throw(std::bad_alloc()) {
That should doubtlessly be:
throw( std::bad_alloc )
What you've said is that the only exception type which will
escape from your function is a pointer to a function returning
an std::bad_alloc and taking no arguments. I really don't think
you meant to say that you're going to throw pointers to
functions.
In practice, exception specifications are not really that
useful, except when they're empty. (It's very important in
certain cases to know that a function cannot throw any
exceptions, but it's rarely useful to know that it can't throw
certain types of exceptions.)
void* const mem = ::operator new(size);
std::printf("custom_allocator::allocate(%p, %lu)\n",
(void*)mem, (unsigned long)size);
return mem;
}
static void deallocate(void* const mem, std::size_t size)
throw() {
std::printf("custom_allocator::deallocate(%p, %lu)\n",
(void*)mem, (unsigned long)size);
::operator delete(mem);
}
};
template<typename T>
struct allocator_base {
static void* operator new(std::size_t size)
The static isn't really necessary: allocation and deallocation
member functions (operator new and operator delete) are always
static, whether you declare them so or not. (On the other hand,
it doesn't hurt.)
throw(std::bad_alloc()) {
return custom_allocator::allocate(size);
}
static void* operator new[](std::size_t size)
throw(std::bad_alloc()) {
return custom_allocator::allocate(size);
}
static void operator delete(void* mem)
Just curious: since you require the size in delete[], why don't
you require it here? Derivation can mean that the size isn't a
constant, e.g.:
class Base : public allocator_base< Base >
{
// ...
} ;
class Derived : public Base
{
// ...
} ;
Base* p = new Derived ;
// ...
delete p ;
(This supposes, of course, that Base has a virtual destructor.)
throw() {
if (mem) {
custom_allocator::deallocate(mem, sizeof(T));
}
}
static void operator delete [](void* mem, std::size_t size)
throw() {
if (mem) {
custom_allocator::deallocate(mem, size);
}
}
};
template<std::size_t T_size>
class buf {
char mem[T_size];
};
class buf2 : public buf<1234>, public allocator_base<buf2> {
char mem2[1000];
};
int main() {
buf2* b = new buf2;
delete b;
b = new buf2[5];
delete [] b;
return 0;
}
______________________________________________________________________
On GCC I get the following output:
custom_allocator::allocate(00246C50, 2234)
custom_allocator::deallocate(00246C50, 2234)
custom_allocator::allocate(00247760, 11174)
custom_allocator::deallocate(00247760, 11174)
On MSVC 8 I get:
custom_allocator::allocate(00362850, 2234)
custom_allocator::deallocate(00362850, 2234)
custom_allocator::allocate(00366B68, 11170)
custom_allocator::deallocate(00366B68, 2234)
Are they both right due to UB? WTF is going on? GCC seems to
be accurate at least... DAMN!
Well, there's no undefined behavior. You're program seems
perfectly legal and well defined to me. It looks like a bug in
VC++, see =A712.5/5:
When a delete-expression is executed, the selected
deallocation function shall be called with the address
of the block of storage to be reclaimed as its first
argument and (if the two-parameter style is used) the
size of the block as its second argument.
And I can't think of any way of interpreting "the size of the
block" to mean anything other than the size requested in the
call to operator new.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34