maxtal@physics.su.OZ.AU (John Max Skaller) writes:

>[I think Greg Colvin has a paper on this improving on my original
>idea that operator new call "allocate()". A user operator
>new can then call the _same_ function "allocate()" supplied
>by the vendor. If we dont do this the only alternative
>is to call malloc: there is no other standard way to allocate
>memory]

So what's wrong with calling malloc()?
What would allocate() buy us?

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article 0p90@hwg.muc.de, heinz@hwg.muc.de (Heinz Wrobel   ) writes:
>Steve Clamage (clamage@Eng.Sun.COM) wrote:
>: The Standard reserves the external identifiers in the
>: library, and makes no provision for user replacement of any standard library
>: function.
>
>Rephrasing my question: Assuming that the standard library needs to _use_
>malloc/new, i.e. the general memory allocation mechanism provided for the
>user of the library itself internally by its definition, shouldn't one
>provide for a defined level of encapsulation around the calls to this?

We sort of lost the point that we were talking about the C library and malloc
originally. The Standard makes no provision for replacing standard C library
functions. If an implementation chooses to provide the extension, that is
by definition an implemenation question. Considering malloc, it has
defined semantics. If a user wants to replace it, the replacement better
have compatible semantics, or who know what will break. If the semantics
are compatible, everthing should still work.

If the implementation internally makes assumptions about malloc apart from
what the Standard says, then malloc is not going to be replaceable unless
those assumptions are documented too. Remember, we are completely outside
the Standard at at this point. Systems vary widely in what constitutes
a "library" and how it might be replaced, or if it can be replaced at all.
Remember, Unix-like systems are not the whole world of computing.

Summarizing some of your other points, what if the user wants the library
internally to continue to do what it always did, but user code needs a
different allocation mechanism? You can already do this in C and C++.
Don't replace malloc, but provide alternative allocation/deallocation
functions that do whatever you want.

What about "operator new()"? C++ already provides for its replacement. The
implementation must allow for users to replace the global 'new' with
another having the semantics defined in the standard.

If you want special allocation pools, that is also already in C++. Use
class-specific 'new', another 'new' just for arrays (global or class-
specific), or placement-new if you need still more flexibility. By the
latter, I mean provide your own allocator, get raw memory from it, then
use placement-new to construct at object at that address, bypassing operator
new entirely.

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

Steve Clamage (clamage@Eng.Sun.COM) wrote:
: It isn't debatable. The Standard reserves the external identifiers in the
: library, and makes no provision for user replacement of any standard library
: function.

I realize my question might be more on implementation issues but I am not
sure where one must draw the line.

Rephrasing my question: Assuming that the standard library needs to _use_
malloc/new, i.e. the general memory allocation mechanism provided for the
user of the library itself internally by its definition, shouldn't one
provide for a defined level of encapsulation around the calls to this? The
problem (which might not affect most people but could be a potential
stopper to some) I see is this:

    - the standard library contains the general memory allocation
      mechanism malloc/new.

    - the standard library implementation needs to use this, too. Example:
      allocation and freeing of internal file handling structures.

    - the user writes an application and finds that he wants to do
      wholesale replacement of the general memory allocator to achieve some
      desirable effect.

    - this replacement will automatically affect the internal works of the
      library now which might not be at all desirable. The concept of the
      library as "black box" is broken because replacement work intended
      for user code affects the library.

    - If the library used "special" names for internal allocation
      procedures where malloc/new would be in turn defined in terms of
      these names, the user could replace one without hurting the other.

: Any implementation is free to provide an extension whereby standard library
: functions may be replaced, and in fact on some systems you can do that.

If an implementation is free to provide for function replacement, shouldn't
the standard at least give hints what should happen if a function is
replaced that is used by other library functions? What about the
interdependency problem? The standard defines that functions "a" and "b"
need to exist in the library and do certain things. Should it define how
"a" should behave if it depends on "b" and "b" is changed/replaced in some
way? Shouldn't the change in "b" by whatever means be theoretically
independent of "a"? Is this beyond the standard and just "an implementation
detail"?


: If you mean the Standard should provide for a replacement mechanism, that is

Defining a certain replacement mechanism is probably not a good idea. But
saying something about effects of any replacement mechanism might be one.

: of course debatable. You could prepare such a proposal for the next round
: of C standardization and see what happens. I predict a debate :-)

Hmm. How would one go about that? I am a very uninformed part time reader
of this group.

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


--
Heinz Wrobel        Edotronik GmbH: heinz@edohwg.adsp.sub.org
                    Private Mail:   heinz@hwg.muc.de
My private FAX: +49 89 850 51 25, I prefer email

In article <3508fr$dtm@engnews2.Eng.Sun.COM> clamage@Eng.Sun.COM writes:
>
>What about "operator new()"? C++ already provides for its replacement. The
>implementation must allow for users to replace the global 'new' with
>another having the semantics defined in the standard.

 But its rather badly designed. There is no way to
"wrap" the vendor supplied "operator new" and there should be.

[I think Greg Colvin has a paper on this improving on my original
idea that operator new call "allocate()". A user operator
new can then call the _same_ function "allocate()" supplied
by the vendor. If we dont do this the only alternative
is to call malloc: there is no other standard way to allocate
memory]

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article 0p4g@hwg.muc.de, heinz@hwg.muc.de (Heinz Wrobel   ) writes:
>
>[Uninformed?] question: If the use of malloc in the library is ... uhm ...
>debatable, why wouldn't one simply say ... [suggestion for replacing functions]

It isn't debatable. The Standard reserves the external identifiers in the
library, and makes no provision for user replacement of any standard library
function.

Any implementation is free to provide an extension whereby standard library
functions may be replaced, and in fact on some systems you can do that.

If you mean the Standard should provide for a replacement mechanism, that is
of course debatable. You could prepare such a proposal for the next round
of C standardization and see what happens. I predict a debate :-)
---
Steve Clamage, stephen.clamage@eng.sun.com

In article <34nr8i$okk@engnews2.Eng.Sun.COM> clamage@Eng.Sun.COM
(Steve Clamage) writes:

|> In article 0p4g@hwg.muc.de, heinz@hwg.muc.de (Heinz Wrobel   ) writes:

|> >[Uninformed?] question: If the use of malloc in the library is ... uhm ...
|> >debatable, why wouldn't one simply say ... [suggestion for replacing functions]

|> It isn't debatable. The Standard reserves the external identifiers in the
|> library, and makes no provision for user replacement of any standard library
|> function.

|> Any implementation is free to provide an extension whereby standard library
|> functions may be replaced, and in fact on some systems you can do that.

|> If you mean the Standard should provide for a replacement mechanism, that is
|> of course debatable. You could prepare such a proposal for the next round
|> of C standardization and see what happens. I predict a debate :-)

And of course, in C++ (this is in comp.lang.c++), the language does
define a replacement mechnanism for ::operator new.
--
James Kanze                                  email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung