Is C++ used in life-critical systems?

[James Kanze]

On 01/11/11 03:01 AM, James Kanze wrote:

Most, yes. But dynamic allocation isn't imposed.

Not using malloc, no. But some sort of dynamic allocation is
more or less imposed for FILE.

Early versions of the C standard library used a statically
allocated pool of FILE, and "allocated" out of that. But it's
still a form of dynamic allocation (which can fail if there
aren't enough entries in the pool). Similarly, Microsoft's
HANDLE almost certainly points to something dynamically
allocated within the kernel. (Perhaps addressed through
a map---I don't know whether HANDLE is actually a void* or an
int. Which is as it should be.)

 

[Ian Collins]

Not using malloc, no. But some sort of dynamic allocation is
more or less imposed for FILE.

Early versions of the C standard library used a statically
allocated pool of FILE, and "allocated" out of that. But it's
still a form of dynamic allocation (which can fail if there
aren't enough entries in the pool).

That's an interesting redefinition of dynamic allocation!

So given

typedef struct libXX_handle libXX_handle_t;

extern libXX_handle_t* libXX_init(void);

and libXX_init returns the address of a static libXX_handle, is that
dynamic allocation?

 

[Alf P. Steinbach /Usenet]

* Ian Collins, on 11.01.2011 20:50:

That's an interesting redefinition of dynamic allocation!

So given

typedef struct libXX_handle libXX_handle_t;

extern libXX_handle_t* libXX_init(void);

and libXX_init returns the address of a static libXX_handle, is that dynamic
allocation?

No. But it is dynamic allocation if you allocate out of a pool at run-time. Even
a free-list qualifies as dynamic allocation.


Cheers,

- Alf

 

[Ian Collins]

* Ian Collins, on 11.01.2011 20:50:

No. But it is dynamic allocation if you allocate out of a pool at
run-time. Even a free-list qualifies as dynamic allocation.

Um, maybe. I've always used the term to refer to heap memory allocated
by malloc or new. I've worked on C projects on small systems where we
did not use a heap, but we did have fixed sized pools (2 serial port
handles for example). None of us considered these to be dynamic memory.
The applications memory footprint was fixed, static not dynamic.

Either way, my original point still stands: use an opaque type does not
impose dynamic allocation.

 

[Adam Skutt]

Most of which are allocated dynamically.

In just about any major C API you can find at least one opaque
structure that isn't intended to be allocated dynamically or need not
be allocated dynamically.

 (FILE in any case; you
can only use FILE*, not FILE.  

You're free to create a FILE, the fact it's not entirely useful isn't
especially relevant to my point. Regardless, consider jmp_buf or
va_list.

And HANDLE is just Microsoft's
name for a pointer to a dynamically allocated block.)

And like most opaque pointers, it need not be a mere pointer, which
was part of the design of handles, nor do handles ipso facto point to
dynamically allocated blocks (though such usage is rare).

Adam

 

[Adam Skutt]

That's an interesting redefinition of dynamic allocation!

So given

typedef struct libXX_handle libXX_handle_t;

extern libXX_handle_t* libXX_init(void);

and libXX_init returns the address of a static libXX_handle, is that
dynamic allocation?

Dynamic allocation means "getting temporary access to a finite
resource", so that qualifies. That being said, it's somewhat
disingenuous compared to how it was used previously in the discussion,
where it was being used to lament "one more thing I have to handle"
which isn't the case with the API here.

Adam

 

[James Kanze]

That's an interesting redefinition of dynamic allocation!

It's the only definition I know. Either you know the address
(perhaps relative to something like the stack pointer) at
compile time, or it's dynamic.

So given

typedef struct libXX_handle libXX_handle_t;

extern libXX_handle_t* libXX_init(void);

and libXX_init returns the address of a static libXX_handle, is that
dynamic allocation?

Not if it always returns the same one. If it has a pool, and
returns one that is free, then there is dynamic management of
the memory, even if malloc and free are not involved. More
generally, if there is a "free" (explicit or implicit), and
freed objects get returned by a future "new" (explicit or
implicit), then I'd say that there is dynamic allocation. This
is certainly the case for fopen/fclose, and I'm pretty sure that
it's also the case for the various Microsoft HANDLE. Whereas
it's not really the case for the Posix thread types. (Although
they all require some sort of "initialization", which can ensure
the "allocation"---with lazy allocation being used in the case
of static allocation. But the distinction maybe isn't strictly
binary.)

 

[James Kanze]

On Jan 10, 9:01 am, James Kanze <[email protected]>
wrote:> Most of which are allocated dynamically.

In just about any major C API you can find at least one opaque
structure that isn't intended to be allocated dynamically or
need not be allocated dynamically.

You're free to create a FILE,

Are you? I don't have my copy of the C standard available to
check, but I was pretty sure that just a "struct FILE;" in
stdio.h was all that was required. (Most implementations do
provide a more complete specification, in order to implement
some of the smaller functions as macros, but this is not
required by the standard.)

 

[Richard Kettlewell]

Are you? I don't have my copy of the C standard available to
check, but I was pretty sure that just a "struct FILE;" in
stdio.h was all that was required. (Most implementations do
provide a more complete specification, in order to implement
some of the smaller functions as macros, but this is not
required by the standard.)

7.19.1 requires that FILE 'is an object type'. Object types are
disjoint from incomplete types (6.2.5).

So I think you're free to write 'FILE x;' if you really want...

 

[Michael Doubez]

7.19.1 requires that FILE 'is an object type'.  Object types are
disjoint from incomplete types (6.2.5).

So I think you're free to write 'FILE x;' if you really want...

So it seems although you are not guaranteed to have the real
underlying structure (and probably you don't).

In the Standard,
27.8.1(Note 305): In C FILE must be a typedef. In C++ it may be a
typedef or other type name.

In this regard, C++ seems to allow incomplete types for FILE.

 

[Richard Kettlewell]

So it seems although you are not guaranteed to have the real
underlying structure (and probably you don't).

No, other way round. It cannot be an incomplete type.

In the Standard,
27.8.1(Note 305): In C FILE must be a typedef. In C++ it may be a
typedef or other type name.

I don't see how that removes the requirement that it be an object type.

 

[Michael Doubez]

No, other way round.  It cannot be an incomplete type.

I can use polymorphism and have FILE as a complete type:

In header:

struct _Base_FILE
{
// Nothing
};
typedef _Base_FILE FILE;


And in implementation:

struct _File_FILE
{
struct _Base_FILE _base;
// other stuff related to file handling
};

struct _Stdio_FILE
{
struct _Base_FILE _base;
// other stuff related to standard I/O handling
};

And then, allocation function will provide either
* a file stream

FILE* fopen(...)
{
_File_FILE* f = (_File_FILE*) malloc(...);

return &f->_base;
};

* a stdio stream
_Stdio_FILE _stdout;
FILE* stdout = &_stdout._base;

In practice, I expect the base will contain function pointers to hande
the real underlying type and f*() function will delegate it to those
members..

I don't see how that removes the requirement that it be an object type.

If it can be any type name, it can be an incomplete type. AKAIS, in C+
+, it could be a void which is not an object type.