Very interesting GC discussion

[jacob navia]

There is a very interesting thread in comp.lang.c++
about garbage collection.

It is very instructive to compare the level of the discussion
there with the discussion we just had here in comp.lang.c

The discussion is called
"An accurate, pauseless & deterministic GC for C++"

The message id of the starting message is:
<[email protected]>

 

[santosh]

There is a very interesting thread in comp.lang.c++
about garbage collection.

It is very instructive to compare the level of the discussion
there with the discussion we just had here in comp.lang.c

Most of that thread seems to an argument over the applicability of the
said GC for patenting. Only a few posts actually discuss the technical
aspects.

<snip>

 

[CBFalconer]

There is a very interesting thread in comp.lang.c++
about garbage collection.

It is very instructive to compare the level of the discussion
there with the discussion we just had here in comp.lang.c

The discussion is called
"An accurate, pauseless & deterministic GC for C++"

However, while I don't really know about C++, I do know that there
is no garbage collecting malloc package for _standard_ C. This is
off topic. Possible topical newsgroups include comp.lang.c++ and
comp.compilers.lcc.

 

[santosh]

However, while I don't really know about C++, I do know that there
is no garbage collecting malloc package for _standard_ C. This is
off topic. Possible topical newsgroups include comp.lang.c++ and
comp.compilers.lcc.

Not comp.lang.c++.

It would be topical on comp.std.c if it is to be a proposed modification
to the Standard.

 

[jacob navia]

However, while I don't really know about C++, I do know that there
is no garbage collecting malloc package for _standard_ C. This is
off topic. Possible topical newsgroups include comp.lang.c++ and
comp.compilers.lcc.

This is a typical answer that shows the level of discussion in this
newsgroup.

 

[Mark McIntyre]

This is a typical answer that shows the level of discussion in this
newsgroup.

It was actually a typical answer that showed the attention to topicality
that most posters here prefer.

Your original post on the other hand was a troll. The second sentence
was a deliberate bait to rouse the anger of CLC posters. Each day, you
become more and more troll-like, and your usefulness as a contributor in
CLC diminishes. I really wish you'd apply your considerable intellect to
the topic.

 

[CBFalconer]

It was actually a typical answer that showed the attention to
topicality that most posters here prefer.

No, it was a typical post suggesting areas where the subject would
be topical, and no longer arouse the ire of c.l.c participants.
Jacobs response seems to have no purpose other than to arouse
resentment and show disdain for the newsgroup.

Jacob might note that, as a rule, adhering to topicality does not
arouse chastising messages.

 

[Keith Thompson]

It seems to be quite common in libraries (e.g. GMP) to have typedefs
like

typedef struct {
/* stuff */
} __type_struct;
typedef __type_struct type_t[1];

I guess the advantage of this is that it allows type_t variables to be
passed by reference without an extra level of indirection.

Is this considered good C style? Are there any problems or pitfalls to
be wary of with this approach?

I'm sure it's considered good C style by some people. Personally, I
think it provides some added convenience at the cost of obfuscating
the code. It lets you write code *as if* C directly supported
pass-by-reference. The problem is, it doesn't. It optimizes for
programmers who don't know C very well.

 

[Marco Manfredini]

It seems to be quite common in libraries (e.g. GMP) to have typedefs
like

typedef struct {
/* stuff */
} __type_struct;
typedef __type_struct type_t[1];

I guess the advantage of this is that it allows type_t variables to be
passed by reference without an extra level of indirection.

Is this considered good C style? Are there any problems or pitfalls to
be wary of with this approach?

I'm sure it's considered good C style by some people. Personally, I
think it provides some added convenience at the cost of obfuscating
the code. It lets you write code *as if* C directly supported
pass-by-reference. The problem is, it doesn't. It optimizes for
programmers who don't know C very well.

I think this is to a lesser extent about the convenience to pass by
reference, but an attempt to make implicit value copies impossible. The
GMP objects hold pointers to heap objects, so an implicit copy slipping
through might lead to hard to track bugs.

 

[Ben Pfaff]

It seems to be quite common in libraries (e.g. GMP) to have typedefs
like

typedef struct {
/* stuff */
} __type_struct;
typedef __type_struct type_t[1];

I guess the advantage of this is that it allows type_t variables to be
passed by reference without an extra level of indirection.

Is this considered good C style? Are there any problems or pitfalls to
be wary of with this approach?

I'm sure it's considered good C style by some people. [...]

....including at least some members of the standards committee, I
guess, since that's jmp_buf is required to be declared:

7.13 Nonlocal jumps <setjmp.h>

1 The header <setjmp.h> defines the macro setjmp, and declares
one function and one type, for bypassing the normal function
call and return discipline.207)

2 The type declared is
jmp_buf
which is an array type suitable for holding the information
needed to restore a calling environment.

The Rationale adds:

7.13 Nonlocal jumps <setjmp.h>

jmp_buf must be an array type for compatibility with
existing practice: programs typically omit the address
operator before a jmp_buf argument, even though a pointer
10 to the argument is desired, not the value of the
argument itself. Thus, a scalar or structure type is
unsuitable. Note that a one- element array of the
appropriate type is a valid definition.

 

[CBFalconer]

It seems to be quite common in libraries (e.g. GMP) to have
typedefs like

typedef struct {
/* stuff */
} __type_struct;
typedef __type_struct type_t[1];

I guess the advantage of this is that it allows type_t variables
to be passed by reference without an extra level of indirection.

Is this considered good C style? Are there any problems or
pitfalls to be wary of with this approach?

I'm sure it's considered good C style by some people. Personally,
I think it provides some added convenience at the cost of
obfuscating the code. It lets you write code *as if* C directly
supported pass-by-reference. The problem is, it doesn't. It
optimizes for programmers who don't know C very well.

It also directly invades the implementations reserved namespace.
NEVER use names headed by two '_'. In practice, never use names
headed by even one '_'. Or expect funny weird non-understandable
bugs, varying with compiler/system.