Re: Using malloc in C++?
On Jun 11, 12:38 pm, Owen Jacobson <angrybald...@gmail.com> wrote:
On Jun 11, 2:25 am, James Kanze <james.ka...@gmail.com> wrote:
On Jun 8, 5:59 am, Owen Jacobson <angrybald...@gmail.com> wrote:
On Jun 7, 8:09 pm, Gianni Mariani <gi3nos...@mariani.ws> wrote:
That's what "implementation defined" means, yes. The entire behaviour
of malloc is, somewhat obliquely, implementation-defined. The only
properties malloc must have in a conforming implementation is always
producing any of a fixed set of outputs for any given input, and that
subsequent operations on those values also have predictable results.
I wouldn't even say that a fixed set of outputs is required.
All that it required is that IF it returns a non-null pointer,
the user must be able to read and write the n bytes starting at
that address. The same as with operator new(). The
requirements are exactly the same.
Well, since there are a finite number of potentially-valid values for
any given pointer type, I think that (much more comfortable)
definition is equivalent. :)
I wonder if it's worth noting that some widespread
implementations don't always meet these requirements, be it
malloc or operator new.
Probably. MS Visual C++ 6, as I recall, returns NULL from failed
'new' expressions rather than throwing. Then again, it was released
before the C++ standard.
Yes. Still, I remember the one time I tested it (some eight or
nine years ago, under Windows NT), it just suspended the
process; it was impossible to get either a null pointer or an
exception. That could have depended on the configuration of our
system, however; in the end, malloc/operator new must sometimes
get memory from the system, and if the system lies to them (e.g.
the default configuration of Linux) or suspends the process for
an indeterminate time, there's not much the library code can do
about it.
And others meet them in rather strange
ways: I've encountered cases where malloc/operator new() simply
suspended the process until more memory was available---fully
conforming, since the standard doesn't say how long
malloc/operator new might take:-).
Come to think of it, does the C++ standard constrain execution time
anywhere?
No. Usability and quality of implementation do, of course, but
not in any absolute terms.
I can imagine an implementation of int operator+ (int m,
int n) with O(nm*nm) complexity with large constant factors; would it
be conforming?
Of course. I've actually used machines where this was the case
for multiplication and divide.
What about the behaviour of the C++ standard library?
The only guarantees you get are complexity, expressed in the
number of certain primitive operations. Nothing about actual
time, nor the operations not being considered. (Thus, insert
into an std::list is "constant", measured in terms of calls to
the constructor. But it's perfectly conform to use an allocator
which is O(N^2), where N is the number of allocated blocks,
which would, of course, make the actual insertion times O(N^2).)
OT: Is google groups getting signatures wrong, or are you, James? The
sig separator should be "-- \n"; if that's what you're sending, then
google groups is no longer stripping signatures from replies.
I wish I knew. I've modified my environment so that I should be
sending the correct delimiter. At least, that's what, barring
false manipulation, ends up in the text buffer I'm editing (in
vim). Regretfully, a lot happens after that, and I'm having
problems finding out exactly what, much less doing anything
about it. Add to the fact that I post from several different
machines, with slightly different environments, and I don't
always know from which machine the posting which caused problems
comes from.
I've modified my signature on the machine here to indicate the
source; I'll do the same the next time I post from another
machine. If anyone sees a posting that is not conform, please
let me know, by email (no point in flooding the group), with all
of the headers of the posting in question, and I'll try and
trace it down. With no guarantee, however; I have no control
over what Google does. (On the other hand, I have sent error
messages to them before, and they've been acknowledged. I think
they do want to be conform, at least to some degree.)
I'm leaving my editor now. I've just confirmed that the
separator is "-- \n", with the space... And now I'm in the
post buffer of Firefox, and the space is still there.
--
James Kanze (GABI Software, from CAI) 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