473,320 Members | 2,035 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

This HAS to be UB...

Keep in mind that I am a C programmer; well, anyway here is the C++
program...
__________________________________________________ ____________________
#include <cstdio>
#include <cstdlib>
#include <new>
struct custom_allocator {
static void* allocate(std::size_t size)
throw(std::bad_alloc()) {
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)
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)
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!


thank you all for your time.
Oct 2 '08 #1
12 1257
"Chris M. Thomasson" <no@spam.invalidwrote in message
news:2y*******************@newsfe06.iad...
Keep in mind that I am a C programmer; well, anyway here is the C++
program...
__________________________________________________ ____________________
[...]
template<std::size_t T_size>
class buf {
char mem[T_size];
};

I add virtual dtor to buf1, and no change in output.
>

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;
}
__________________________________________________ ____________________
[...]

Oct 2 '08 #2
Chris M. Thomasson wrote:
Keep in mind that I am a C programmer; well, anyway here is the C++
program...
[..]

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)
MSVC 9 gives the same output, BTW.
Are they both right due to UB? WTF is going on? GCC seems to be accurate
at least... DAMN!
Well, the default implementation of the operator delete[] does *not*
have the "size" argument. In fact there are two allowed declarations of
the operator delete[]:

void operator delete[](void* ptr) throw();

and

void operator delete[](void* ptr, const std::nothrow&) throw();

I'm not sure what else to tell you.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Oct 2 '08 #3
"Victor Bazarov" <v.********@comAcast.netwrote in message
news:gc**********@news.datemas.de...
Chris M. Thomasson wrote:
>Keep in mind that I am a C programmer; well, anyway here is the C++
program...
[..]

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)

MSVC 9 gives the same output, BTW.
>Are they both right due to UB? WTF is going on? GCC seems to be accurate
at least... DAMN!

Well, the default implementation of the operator delete[] does *not* have
the "size" argument. In fact there are two allowed declarations of the
operator delete[]:

void operator delete[](void* ptr) throw();

and

void operator delete[](void* ptr, const std::nothrow&) throw();

I'm not sure what else to tell you.
This has to be GCC extension? This is weird, well, perhaps not so weird
because it simply MUST be 100% UB. Oh well. I initially thought I could take
advantage of it; NOT!!!

;^/

Oct 2 '08 #4
In article <2y*******************@newsfe06.iad>, "Chris M. Thomasson"
<no@spam.invalidwrote:
Keep in mind that I am a C programmer; well, anyway here is the C++
program...
__________________________________________________ ____________________
#include <cstdio>
#include <cstdlib>
#include <new>

struct custom_allocator {
static void* allocate(std::size_t size)
throw(std::bad_alloc()) {
***^^***
void* const mem = ::operator new(size);
std::printf("custom_allocator::allocate(%p, %lu)\n",
(void*)mem, (unsigned long)size);
return mem;
}
[...]

How did this even compile?
Oct 2 '08 #5
"blargg" <bl********@gishpuppy.comwrote in message
news:bl*************************@192.168.1.4...
In article <2y*******************@newsfe06.iad>, "Chris M. Thomasson"
<no@spam.invalidwrote:
>Keep in mind that I am a C programmer; well, anyway here is the C++
program...
_________________________________________________ _____________________
#include <cstdio>
#include <cstdlib>
#include <new>

struct custom_allocator {
static void* allocate(std::size_t size)
throw(std::bad_alloc()) {
***^^***
> void* const mem = ::operator new(size);
std::printf("custom_allocator::allocate(%p, %lu)\n",
(void*)mem, (unsigned long)size);
return mem;
}
[...]

How did this even compile?
I don't know! It did! Well, blame MSVC 8+ and GCC! ARGH... Well, if it
didn;t compile I would have NOT asked the contrived question indeed!

:^|

Oct 3 '08 #6
On Oct 2, 9:52 pm, "Chris M. Thomasson" <n...@spam.invalidwrote:
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 §12.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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Oct 3 '08 #7
>
"James Kanze" <ja*********@gmail.comwrote in message
news:78**********************************@z66g2000 hsc.googlegroups.com...
On Oct 2, 9:52 pm, "Chris M. Thomasson" <n...@spam.invalidwrote:
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...
I was exploring the feature in C++ delete operator in which the size of the
allocation is returned along with the pointer to allocated memory. One could
create heavily optimized custom memory allocator using that important piece
of information.

__________________________________________________ ____________________
#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.
That was definitely a typo/error on my part.

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.)
I thought it would be prudent to give the overloaded operator new an
exception specification of `std::bad_alloc'. Also, I wanted to give an empty
specification to the overload of operator delete. As to how useful it is...
Well, I don't quite know.

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.)
Its a habit of mine. Also, using printf in C++ is another habit.

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.)

[...]
__________________________________________________ ____________________
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 §12.5/5:
It definitely looks like a bug is MSVC++. I get erroneous behavior on
versions 6 through 9.

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.
I thought that MSVC was crapping out because `allocator_base' was a
template. So I created another little test which hopefully has all the bugs
fixed:
__________________________________________________ ________________________
#include <cstdio>
#include <cstdlib>
#include <new>
struct custom_allocator {
static void* allocate(std::size_t size)
throw(std::bad_alloc) {
void* const mem = std::malloc(size);
if (! mem) {
throw std::bad_alloc();
}
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() {
if (mem) {
std::printf("custom_allocator::deallocate(%p, %lu)\n",
(void*)mem, (unsigned long)size);
std::free(mem);
}
}
};
struct allocator_base {
void* operator new(std::size_t size)
throw(std::bad_alloc) {
return custom_allocator::allocate(size);
}

void* operator new [](std::size_t size)
throw(std::bad_alloc) {
return custom_allocator::allocate(size);
}

void operator delete(void* mem, std::size_t size)
throw() {
custom_allocator::deallocate(mem, size);
}

void operator delete [](void* mem, std::size_t size)
throw() {
custom_allocator::deallocate(mem, size);
}
};


template<std::size_t T_size>
class buf : public allocator_base {
char mem[T_size];
public:
virtual ~buf() throw() {}
};
class buf2 : public buf<1234{
char mem2[1000];
};
int main() {
buf<1024>* b1 = new buf<1024>;
delete b1;

buf2* b2 = new buf2;
delete b2;

b2 = new buf2[5];
delete [] b2;

return 0;
}

__________________________________________________ ________________________


On every version of GCC I have, I get the following output on a 32-bit
machine:

custom_allocator::allocate(00246C50, 1028)
custom_allocator::deallocate(00246C50, 1028)
custom_allocator::allocate(002472A8, 2240)
custom_allocator::deallocate(002472A8, 2240)
custom_allocator::allocate(002472A8, 11204)
custom_allocator::deallocate(002472A8, 11204)


On every version of MSVC, I get:

custom_allocator::allocate(00365B28, 1028)
custom_allocator::deallocate(00365B28, 1028)
custom_allocator::allocate(00362850, 2240)
custom_allocator::deallocate(00362850, 2240)
custom_allocator::allocate(00366FA8, 11204)
custom_allocator::deallocate(00366FA8, 2240)

Well, MSVC has a fairly nasty bug indeed. Anyway, what do you think James?

Oct 4 '08 #8

"Victor Bazarov" <v.********@comAcast.netwrote in message
news:gc**********@news.datemas.de...
Chris M. Thomasson wrote:
>Keep in mind that I am a C programmer; well, anyway here is the C++
program...
[...]
>
Well, the default implementation of the operator delete[] does *not* have
the "size" argument. In fact there are two allowed declarations of the
operator delete[]:

void operator delete[](void* ptr) throw();

and

void operator delete[](void* ptr, const std::nothrow&) throw();

I'm not sure what else to tell you.
I think that

void operator delete [](void*, std::size_t) throw();

is a valid declaration. I mean, even Comeau compiles the following program
without any warnings:
__________________________________________________ __________________
#include <cstdio>
#include <cstdlib>
#include <new>
struct custom_allocator {
static void* allocate(std::size_t size)
throw(std::bad_alloc) {
void* const mem = std::malloc(size);
if (! mem) {
throw std::bad_alloc();
}
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() {
if (mem) {
std::printf("custom_allocator::deallocate(%p, %lu)\n",
(void*)mem, (unsigned long)size);
std::free(mem);
}
}
};
struct allocator_base {
void* operator new(std::size_t size)
throw(std::bad_alloc) {
return custom_allocator::allocate(size);
}

void* operator new [](std::size_t size)
throw(std::bad_alloc) {
return custom_allocator::allocate(size);
}

void operator delete(void* mem, std::size_t size)
throw() {
custom_allocator::deallocate(mem, size);
}

void operator delete [](void* mem, std::size_t size)
throw() {
custom_allocator::deallocate(mem, size);
}
};


template<std::size_t T_size>
class buf : public allocator_base {
char mem[T_size];
public:
virtual ~buf() throw() {}
};
class buf2 : public buf<1234{
char mem2[1000];
};
int main() {
buf<1024>* b1 = new buf<1024>;
delete b1;

buf2* b2 = new buf2;
delete b2;

b2 = new buf2[5];
delete [] b2;

return 0;
}
__________________________________________________ __________________

Humm... Is Comeau screwing up and compiling non-compliant code without so
much as a warning?

Oct 4 '08 #9
Victor Bazarov wrote:
>[...]

Well, the default implementation of the operator delete[] does *not*
have the "size" argument. In fact there are two allowed declarations of
the operator delete[]:

void operator delete[](void* ptr) throw();

and

void operator delete[](void* ptr, const std::nothrow&) throw();
While that's true for global 'operator delete', my reading of
3.7.3.2/2 seems to indicate that class-specific versions can
indeed have a second argument of type 'std::size_t'. ICBWT.
I'm not sure what else to tell you.

V
Schobi

Oct 4 '08 #10
Chris M. Thomasson wrote:
[...]
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)
That code can be simplified further. Using VC9, this

#include <cstdio>
#include <cstdlib>
#include <new>

void* allocate(std::size_t size) throw(std::bad_alloc) {
void* const mem = ::operator new(size);
std::printf("allocate(%p, %lu)\n", (void*)mem, (unsigned long)size);
return mem;
}

void deallocate(void* const mem, std::size_t size) throw() {
std::printf("deallocate(%p, %lu)\n", (void*)mem, (unsigned long)size);
if (mem) ::operator delete(mem);
}

struct buf2 {
char mem[1024];
void* operator new(std::size_t size) throw(std::bad_alloc) {
return allocate(size);
}

void* operator new[](std::size_t size) throw(std::bad_alloc) {
return allocate(size);
}

void operator delete(void* mem, std::size_t size) throw() {
deallocate(mem, size);
}

void operator delete [](void* mem, std::size_t size) throw() {
deallocate(mem, size);
}
};

int main() {
buf2* b = new buf2;
delete b;

b = new buf2[5];
delete [] b;

return 0;
}

shows the same behavior for me.

Debugging shows that VC9 doesn't call 'operator new[]' for 'new buf2[5]'
(it calls 'operator new' instead), but calls 'operator delete[]' for
'delete[] b'.
Either I'm missing something really obvious, or that's a plain bug.
[...]
Schobi

Oct 4 '08 #11
On Oct 4, 1:46 am, Hendrik Schober <spamt...@gmx.dewrote:
Victor Bazarov wrote:
[...]
Well, the default implementation of the operator delete[]
does *not* have the "size" argument. In fact there are two
allowed declarations of the operator delete[]:
void operator delete[](void* ptr) throw();
and
void operator delete[](void* ptr, const std::nothrow&) throw();
While that's true for global 'operator delete', my reading of
3.7.3.2/2 seems to indicate that class-specific versions can
indeed have a second argument of type 'std::size_t'. ICBWT.
Actually, the only requirement for defining an operator delete
function is that the first argument have type void*. You can
declare and define delete functions with any other arguments you
want. What is relevant here is the fact that *IF* there is no
operator delete[]( void* ) in the class, but there is a operator
delete[]( void*, std::size_t ), the latter will be used as the
"usual" deallocator, and not only for placement delete.

And at global scope, the standard defines three operator
delete[]: (void*), (void*, std::nothrow const&) and (void*,
void*).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Oct 6 '08 #12
On Oct 4, 7:13 am, "Chris M. Thomasson" <n...@spam.invalidwrote:
"James Kanze" <james.ka...@gmail.comwrote in message
news:78**********************************@z66g2000 hsc.googlegroups.com...
On Oct 2, 9:52 pm, "Chris M. Thomasson" <n...@spam.invalidwrote:
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...
I was exploring the feature in C++ delete operator in which
the size of the allocation is returned along with the pointer
to allocated memory. One could create heavily optimized custom
memory allocator using that important piece of information.
Certainly. It could be, in certain cases. But you're using a
fairly advanced feature of C++, one that many experienced C++
programmers aren't too familiar with. *IF* you're basically a C
programmer, and not too familiar with C++, you should probably
gain that familiarity first.

[...]
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.)
I thought it would be prudent to give the overloaded operator
new an exception specification of `std::bad_alloc'. Also, I
wanted to give an empty specification to the overload of
operator delete. As to how useful it is... Well, I don't
quite know.
Given that the standard does use that exception specifier for
the global operator new, it's probably a good idea to follow
suite. But I don't think that it's really that useful, and in
general, I wouldn't bother unless the specifier were empty.
(Note that the contract of the operator new function is slightly
different if it has an empty exception specifier. Unless it has
an empty specifier, operator new() and operator new[] may not
return a null pointer; if the version chosen has an empty
specifier, they can.)
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.)
Its a habit of mine. Also, using printf in C++ is another habit.
The static doesn't hurt. Using printf is a very bad habit,
however.
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.)
[...]
__________________________________________________ ____________________
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 §12.5/5:
It definitely looks like a bug is MSVC++. I get erroneous
behavior on versions 6 through 9.
It's quite possible. This is such a rarely used feature, I
doubt that it gets much testing. (In practice, I don't think
I've ever used new[]/delete[] in over 15 years of C++.)
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.
I thought that MSVC was crapping out because `allocator_base'
was a template. So I created another little test which
hopefully has all the bugs fixed:
__________________________________________________ ________________________
[...[
__________________________________________________ ________________________

On every version of GCC I have, I get the following output on
a 32-bit machine:
custom_allocator::allocate(00246C50, 1028)
custom_allocator::deallocate(00246C50, 1028)
custom_allocator::allocate(002472A8, 2240)
custom_allocator::deallocate(002472A8, 2240)
custom_allocator::allocate(002472A8, 11204)
custom_allocator::deallocate(002472A8, 11204)
On every version of MSVC, I get:
custom_allocator::allocate(00365B28, 1028)
custom_allocator::deallocate(00365B28, 1028)
custom_allocator::allocate(00362850, 2240)
custom_allocator::deallocate(00362850, 2240)
custom_allocator::allocate(00366FA8, 11204)
custom_allocator::deallocate(00366FA8, 2240)
Well, MSVC has a fairly nasty bug indeed. Anyway, what do you
think James?
It looks like an error in the compiler, but it's certainly a
minor one, since it concerns a feature that has no real use in
practice.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Oct 6 '08 #13

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: James | last post by:
I have a from with 2 fields: Company & Name Depening which is completed, one of the following queries will be run: if($Company){ $query = "Select C* From tblsample Where ID = $Company...
5
by: Scott D | last post by:
I am trying to check and see if a field is posted or not, if not posted then assign $location which is a session variable to $location_other. If it is posted then just assign it to...
2
by: Nick | last post by:
Can someone please tell me how to access elements from a multiple selection list? From what ive read on other posts, this is correct. I keep getting an "Undefined variable" error though... Form...
2
by: Alexander Ross | last post by:
I have a variable ($x) that can have 50 different (string) values. I want to check for 7 of those values and do something based on it ... as I see it I have 2 options: 1) if (($x=="one") ||...
0
by: Dan Foley | last post by:
This script runs fine, but I'd like to know why it's so slow.. Thanks for any help out there on how i can make it faster (it might take up to 5 min to write these 3 export files whith 15 records...
5
by: Lee Redeem | last post by:
Hi there I've created abd uploaded this basic PHP script: <html> <head> <title>PHP Test</title> </head> <body> <H1 align="center">
5
by: christopher vogt | last post by:
Hi, i'm wondering if there is something like $this-> to call a method inside another method of the same class without using the classname in front. I actually use class TEST { function...
6
by: Phil Powell | last post by:
Ok guys, here we go again! SELECT s.nnet_produkt_storrelse_navn FROM nnet_produkt_storrelse s, nnet_produkt_varegruppe v, nnet_storrelse_varegruppe_assoc sv, nnet_produkt p WHERE...
1
by: Michel | last post by:
a site like this http://www.dvdzone2.com/dvd Can you make it in PHP and MySQL within 6 weeks? If so, send me your price 2 a r a (at) p a n d o r a . b e
11
by: Maciej Nadolski | last post by:
Hi! I can`t understand what php wants from me:( So: Cannot send session cache limiter - headers already sent (output started at /home/krecik/public_html/silnik.php:208) in...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.