One clear disadvantage with the C++ operator new vs. the malloc schema
used by C is that the possibility to #define extra debugging data to
the memory allocation routines is limited.

In C:
 #define MY_MALLOC(size)  malloc_fl(size, __FILE__, __LINE__)

In C++, you are allowed to overload the operator new in classes, often
used in class libraries inheriting a common class (CObject e.g.).
However, defining the global function:

  void *operator new(size_t nSize, const char *cszFile, int nLine);

with the implied syntax:

  char *pBuffer =3D new(__FILE__, __SIZE__) char[1000];

is not allowed (at least not using Watcom C++, and gcc-2.7.2).

Why has not this emerged into the standard?

To be honest, there are ways to fool the system by using

  void *operator new(size_t nSize, void *pWhere);

like e.g. this example:

//-----------------------------------------------------------------------=
---------------
#include <sys/types.h>
#include <malloc.h>
#include <stdio.h>

struct __memory_position__
{
  const char *pszFileName;
  int nLine;
  __memory_position__(const char *fname, int line)=20
      : pszFileName(fname), nLine(line) {}
  operator void *() { return this; }
};

void *operator new[] (size_t nSize, void *pWhere)
{
  void *p =3D malloc(nSize);
  printf("%s : %d\n", ((__memory_position__ *)pWhere)->pszFileName, ((__m=
emory_position__ *)pWhere)->nLine);
  return p;
}

void *operator new (size_t nSize, void *pWhere)
{
  void *p =3D malloc(nSize);
  printf("%s : %d\n", ((__memory_position__ *)pWhere)->pszFileName, ((__m=
emory_position__ *)pWhere)->nLine);
  return p;
}

// -------------------------------------------------- //
// WARNING : UGLY UGLY UGLY !!!!!                     //
// -------------------------------------------------- //

#define new new (__memory_position__(__FILE__, __LINE__))
//-----------------------------------------------------------------------=
---------------

However, this is far to ugly for my tastes, and also makes the intended u=
se of those
new operators invalid.

PKE.
--=20
----------------------------------------------------------------------
| P=E5l-Kristian Engstad | engstad@funcom.com  | Games programmer, PSX |
| FUNCOM Oslo A/S      | Ph +47 22 42 01 02  | developer & Linux Fan |
----------------------------------------------------------------------
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article 1FAF@funcom.com, Pel-Kristian Engstad <engstad@funcom.no> writes:
>
>In C++, you are allowed to overload the operator new in classes, often
>used in class libraries inheriting a common class (CObject e.g.).
>However, defining the global function:
>
>  void *operator new(size_t nSize, const char *cszFile, int nLine);
>
>with the implied syntax:
>
>  char *pBuffer = new(__FILE__, __SIZE__) char[1000];
>
>is not allowed (at least not using Watcom C++, and gcc-2.7.2).

It is allowed by the ARM and has always been in the draft standard, but
you may be missing one language change.

The draft standard now provides for two kinds of operator new (and
corresponding operator delete): one for single objects "operator new"
and one for arrays of objects "operator new[]". If your compilers support
this new feature, the "operator new" you declared is not the one invoked
by your sample code. Add another function
 void *operator new[](size_t nSize, const char *cszFile, int nLine);
and you should be OK.

---
Steve Clamage, stephen.clamage@eng.sun.com




[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]