create warning message when using new and delete

[jd]

Hello everyone,

I have just a question you surely noticed it by the subject.

I would like application clients not to use new and delete operators, and
use other means we developped. To do so, I would like to arise some
compile-time warnings when new and delete operators are used.
I have searched on Internet but failed to find something, so I make this
request here.

Do you know if it is possible to do so ? If yes, do you have any ideas on
how to do this ?

Thanks a lot.

 

[Donkey Hottie]

19.7.2011 14:46, jd kirjoitti:

Hello everyone,

I have just a question you surely noticed it by the subject.

I would like application clients not to use new and delete operators, and
use other means we developped. To do so, I would like to arise some
compile-time warnings when new and delete operators are used.
I have searched on Internet but failed to find something, so I make this
request here.

Do you know if it is possible to do so ? If yes, do you have any ideas on
how to do this ?

Thanks a lot.

This will be interesting, following

 

[Victor Bazarov]

I have just a question you surely noticed it by the subject.

I would like application clients not to use new and delete operators, and
use other means we developped. To do so, I would like to arise some
compile-time warnings when new and delete operators are used.
I have searched on Internet but failed to find something, so I make this
request here.

Do you know if it is possible to do so ? If yes, do you have any ideas on
how to do this ?

I don't think it's such a great idea. What you seem to suggest is to
fence the "application clients" into some castrated version of the
language. Why not disable the use of references, then? Or pointers
(they are evil, don't you know)?

If you want your library implementation to never use 'new' and 'delete'
for *your own classes*, declare operator new and operator delete in your
classes as *private*. That way the code that tries to allocate those
classes using 'new' will simply hit the "not accessible" wall. If you
are implementing some kind of memory management library, take a look at
how those things have been done before you. I remember one product that
we used at the dawn of our development - SmartHeap. It used macros to
trick the compiler into replacing any 'malloc', 'new' with some special
functionality, which is not necessarily completely legit from the
Standard C++ POV ("Thou shalt not replace keywords"). But it worked
with a couple of compilers we were using. I.e. it was heavily
compiler-specific.

There are some solutions you can hope to implement, not sure if a truly
portable one exists. Perhaps all you need is to cover the most common
compilers your clients are going to be using...

V

 

[Goran]

Hello everyone,

I have just a question you surely noticed it by the subject.

I would like application clients not to use new and delete operators, and
use other means we developped. To do so, I would like to arise some
compile-time warnings when new and delete operators are used.
I have searched on Internet but failed to find something, so I make this
request here.

Do you know if it is possible to do so ? If yes, do you have any ideas on
how to do this ?

Is your application a library that exposes some types? If so, did you
consider making operator new of these types private? That will stop
clients dead. But note this: your clients can easily use containment
to effectively allocate your types on the heap. E.g.

class your_type;

class my_type
{
public: your_type your_var;
}

void f()
{
my_type p = new my_type(params); p->your_var now effectively on
heap.
}

But I wouldn't do any of this, not unless I could come up with a
really compelling reason why I need it. In C++, ultimate restriction
of such things is virtually impossible. If your goal is to stop people
from making errors, you will easily fail. The best way to avoid making
errors is for you users to know what they're doing better.
Restrictions tend to attract people to doing wrong things in more
elaborate ways.

Goran.

 

[James Kanze]

I have just a question you surely noticed it by the subject.

I would like application clients not to use new and delete
operators, and use other means we developped. To do so, I
would like to arise some compile-time warnings when new and
delete operators are used. I have searched on Internet but
failed to find something, so I make this request here.

Do you know if it is possible to do so ? If yes, do you have
any ideas on how to do this ?

For your own classes, it's fairly easy. Just declare a private
member operator new. Globally... There's not much you can do,
given that a lot of things in the standard library are going to
want to use new and delete as well.

 

[TJorgenson]

For your own classes, it's fairly easy.  Just declare a private
member operator new.  Globally... There's not much you can do,
given that a lot of things in the standard library are going to
want to use new and delete as well.

I am curious if you think this might be a useful technique (i.e.
declaring a private member operator new) for RAII classes to prevent
accidental heap allocation? I have considered this on occasion, but I
have not seen this technique used by others. I suppose you could say
that the chances of someone accidentally using a “new’ed” RAII class
is unlikely and does not need to be protected against. What do you
think?

Tony

 

[James Kanze]

I am curious if you think this might be a useful technique (i.e.
declaring a private member operator new) for RAII classes to prevent
accidental heap allocation? I have considered this on occasion, but I
have not seen this technique used by others. I suppose you could say
that the chances of someone accidentally using a “new’ed” RAII class
is unlikely and does not need to be protected against. What do you
think?

I don't see any real advantage in it. There's no point in
allocating an instance of an RAII class directly with new, but
there's no real harm either; it doesn't actively violate any
invariants. If you want to go this route, you should forbid
dynamic allocation of all value types. (FWIW: in over 20 years
experience in C++, I've not encountered a case where it made
sense to forbid dynamic allocation.)

 

[TJorgenson]

I am curious if you think this might be a useful technique (i.e.

I don't see any real advantage in it.  There's no point in
allocating an instance of an RAII class directly with new, but
there's no real harm either; it doesn't actively violate any
invariants.  If you want to go this route, you should forbid
dynamic allocation of all value types.  (FWIW: in over 20 years
experience in C++, I've not encountered a case where it made
sense to forbid dynamic allocation.)

I guess I have to agree. I have never actually implemented an RAII
class this way and in my 20+ years I can't remember any instance where
someone actually dynamically allocated an RAII object that should have
been declared auto either.

Tony

 

[Joshua Maurice]

I guess I have to agree. I have never actually implemented an RAII
class this way and in my 20+ years I can't remember any instance where
someone actually dynamically allocated an RAII object that should have
been declared auto either.

To add some breadth to this, sadly I have. I once saw some code of a
std::auto_ptr being allocated with new and delete, in a single scope,
and the object did not escape the scope. Probably one of the Java
programmers not thinking.