"BGB / cr88192" <cr88192 at (no spam) hotmail.com> wrote in message
news:h4v8sr$p2d$1 at (no spam) news.albasani.net...

"Juha Nieminen" <nospam at (no spam) thanks.invalid> wrote in message
news:abycm.52$sW4.12 at (no spam) read4.inet.fi...
Tech07 wrote:
My
secondary point was that RAII is only one stylistic approach one can
take in
C++ as "one size fits all" is never true.

Well, I have found that RAII fits at least 99% of sizes, and that's
reason enough for me to prefer C++ over C. But that might be just me.


well, unless one can live with alternative memory-management schemes
(AKA: not malloc), which can offer some of the same benefits, but without
necessitating using a C++ (good, for example, when a decent chunk of
ones' project may be JIT compiled with a custom compiler...).

as mentioned elsewhere, "localized heaps" is another strategy, where each
task/subsystem is given its own localized heap...


GC is another strategy, but is not used as much in many cases, in part,
because it is slower (among other issues). as a result, local heaps and
bulk freeing tends to be much better as a higher-performance strategy
(leaving the GC mostly for more "generic" code...).

that or devising a "more effective" garbage collector...

at times, I had considered the possibility of integrating similar sorts
of "bulk free" capabilities into the GC, but have not done so thus far.
it would either require segregating the heap, or tagging objects, the
latter allowing easily moving objects to the global heap (inferring from
the APIs, I think the JVM does something like this...).

however, the "bulk free" could be accomplished with a variation of the
sweep phase, rather than needing to do a full GC pass...

using seperate heaps/allocators is simpler though...


I am quite fond of region allocators. Here is a simple example
implementation I created:


http://pastebin.com/f37a23918


This region allocator does not force all allocations to be aligned up to a
so-called maximum alignment like `malloc' and friends are required to do.
For instance, allocations for a single char will not be forced to waste
the
extra alignment space. This can have benefits in space constrained
environments (e.g., embedded devices). Also, its static in nature and can
be
fed with a buffer residing on the stack. There are no underlying calls to
`malloc'. This can be useful in free standing environments that do not
support heap allocation. One other thing. Its a pure region allocator
which
means you do not need to free individual objects. You can free the entire
region. This is more efficient than calling `malloc()/free()' for each
object. For instance, you can destroy all the nodes in a linked list just
by
freeing the region(s) in which the nodes were allocated from. There is no
need to traverse the list to free its nodes. Its a sort of "manual"
garbage
collection... ;^)

IMVHO, that's kind of cool... ;^)

Nick Keighley wrote:

what coding conventions does C typically use that C++ typically
doesn't? Isn't the use of RAII a massive coding convention?

  No. RAII is certainly not a coding convention. It's a compiler
technique and has little to do with coding conventions. A coding
convention is something the *programmer* does, while RAII is something
the *compiler* does automatically.

  If, for example, I instantiate and manipulate a std::string in a
function, I don't need *any* coding conventions to make sure that the
string gets freed: The compiler is going to free it for me. I don't have
to do anything to achieve that.

  In C, however, if I use a dynamic string in a function, I have to free
it myself, and to avoid leaks in complicated functions I have to use
some coding principles to make sure that the string gets freed no matter
how the function is exited.

  That's precisely what I'm talking about: RAII aids me in avoiding a
useless coding convention which I would have to use in C to make the my
code safer.

well, you've got to write your destructors correctly.

jacob navia wrote:
You just
replace malloc by GC_malloc, and forget about free

Keywords one hears all over the place: "you just...". Well, personally, "I
don't wanna just.. " anything. :P

Trying to sell "you don't have to think about it!" to thinkers (yes, the IQ
on here is way above the average Joe/Jane) on USENET is doomed to failure.. I
suggest you not pursue a marketing career, cuz you really suck at it.

Jerry Coffin wrote:

The basic problem being dealt with is pretty simple. In C, you run
into two problems. First of all, about the only thing C provides for
dealing with dynamic data is malloc/calloc/realloc/free. Second, it
makes it essentially impossible to centralize the use of those tools.


The lcc-win C compiler provides a GC.

This allows for much easier
programming what memory management is concerned.

You just
replace malloc by GC_malloc, and forget about free

"Jerry Coffin" <jerryvcoffin at (no spam) yahoo.com> wrote in message
news:MPG.24dbea4f260cff2198971a at (no spam) news.sunsite.dk...
In article <h4tcbv$apv$1 at (no spam) aioe.org>, jacob at (no spam) nospam.org says...

Jerry Coffin wrote:

The basic problem being dealt with is pretty simple. In C, you run
into two problems. First of all, about the only thing C provides
for dealing with dynamic data is malloc/calloc/realloc/free.
Second, it makes it essentially impossible to centralize the use
of those tools.

The lcc-win C compiler provides a GC. This allows for much easier
programming what memory management is concerned. You just
replace malloc by GC_malloc, and forget about free

In theory, almost any C compiler could include a GC -- but most
don't, and portable code certainly can't count on it. Of course, the
same is true in C++.

More less orthogonally, while GC works quite nicely for memory (at
least in some situations) it does nothing at all for managing other
resources (file handles, handles to GUI stuff, etc.)


often, a GC is written for and used by the app in question.
it being provided by a compiler, then, is a convinience...

"Tech07" <tech07 at (no spam) nospam.hia> writes:
"Phil Carmody" <thefatphil_demunged at (no spam) yahoo.co.uk> wrote in message
news:874ostkewc.fsf at (no spam) kilospaz.fatphil.org...
"Tech07" <tech07 at (no spam) nospam.hia> writes:
While C gives the programmer no help, C++ "provides" only one
stylistic approach: RAII.

Well that's one of the biggest loads of bollocks that's been
cross-posted to comp.lang.c in a long time. (Apart from the regular
idiots who are heppily killfiled.)

C++ provides practically _everything_ provided by C, so if C
provides anything which isn't RAII (which it does), then C++ does
too.

Please evolve a brain before cross-posting again.

You should learn how to read and comprehend before you start
blathering. And if you don't understand, ask.

So you don't have anything to support your absurd assertion then?
Why am I not surprised?

BGB / cr88192 wrote:
"Jerry Coffin" <jerryvcoffin at (no spam) yahoo.com> wrote in message
news:MPG.24dbea4f260cff2198971a at (no spam) news.sunsite.dk...
In article <h4tcbv$apv$1 at (no spam) aioe.org>, jacob at (no spam) nospam.org says...

Jerry Coffin wrote:

The basic problem being dealt with is pretty simple. In C, you run
into two problems. First of all, about the only thing C provides
for dealing with dynamic data is malloc/calloc/realloc/free.
Second, it makes it essentially impossible to centralize the use
of those tools.

The lcc-win C compiler provides a GC. This allows for much easier
programming what memory management is concerned. You just
replace malloc by GC_malloc, and forget about free

In theory, almost any C compiler could include a GC -- but most
don't, and portable code certainly can't count on it. Of course, the
same is true in C++.

More less orthogonally, while GC works quite nicely for memory (at
least in some situations) it does nothing at all for managing other
resources (file handles, handles to GUI stuff, etc.)


often, a GC is written for and used by the app in question.
it being provided by a compiler, then, is a convinience...


Why is it, that when a GC thread emerges, that I feel like spray-painting
on it?

jacob navia wrote:
Jerry Coffin wrote:

The basic problem being dealt with is pretty simple. In C, you run
into two problems. First of all, about the only thing C provides for
dealing with dynamic data is malloc/calloc/realloc/free. Second, it
makes it essentially impossible to centralize the use of those tools.


The lcc-win C compiler provides a GC.

You say that as if it was a lucrative feature. (hint, hint: not to me!).

This allows for much easier
programming what memory management is concerned.

Programming without memory management isn't programming. ;)

You just
replace malloc by GC_malloc, and forget about free

Keywords one hears all over the place: "you just...". Well, personally, "I
don't wanna just.. " anything. :P

Trying to sell "you don't have to think about it!" to thinkers (yes, the
IQ on here is way above the average Joe/Jane) on USENET is doomed to
failure. I suggest you not pursue a marketing career, cuz you really suck
at it.

Nick Keighley wrote:
what coding conventions does C typically use that C++ typically
doesn't?
Isn't the use of RAII a massive coding convention?

No. RAII is certainly not a coding convention. It's a compiler
technique and has little to do with coding conventions. A coding
convention is something the *programmer* does, while RAII is something
the *compiler* does automatically.

If, for example, I instantiate and manipulate a std::string in a
function, I don't need *any* coding conventions to make sure that the
string gets freed: The compiler is going to free it for me. I don't
have to do anything to achieve that.

"Bo Persson" <bop at (no spam) gmb.dk> wrote in message
news:7dgu1rF2cak0cU1 at (no spam) mid.individual.net...
BGB / cr88192 wrote:
"Juha Nieminen" <nospam at (no spam) thanks.invalid> wrote in message
news:NlEcm.129$sW4.42 at (no spam) read4.inet.fi...

snip


as a side note:
WRT strings, this is why I typically very rarely use strdup...
strdup is a memory leak just waiting to happen (likewise for
malloc...).
so, as part of my little "convention", I tend to use functions
which intern all the strings (typically, these are localized to
particular libraries).
char *basm_strdup(char *str);
char *sxil_strdup(char *str);
...

then again, I guess the "strdup" could be a hurdle, since the
resultant string is interned, rather than allocated...

so, my usual approach:
any work on a string is done in a buffer;
the string is interned, and regarded as immutable.

granted, one doesn't want to use this with any large chunk of text,
since typically these interned strings are not going away (making
it "sort of like a memory leak"). some sort of GC-mechanism for
interned strings could be done, but I have typically not done so
(since short strings have a tendency of being very repetitive, and
the total number of them being finite).

it is worth noting, however, that a partial solution to this has
been the use of the "allocate, bulk-free" strategy (or, in Quake
terms, the "Hunk" strategy). basically, where the strings are
interned into a temporary local heap, and upon leaving the general
region, the entire strings-table is destroyed as well.

this is actually the strategy typically used in my compilers (many
of my compiler stages each use their own localized heaps).

the reason for doing this was that compilers tend to produce huge
amounts of "garbage" all at once, and because using the main
heap/GC tended to hurt performance too badly...

if there is one thing the "hunk" strategy is good at, it is being
fast (since an entire heap can be torn down nearly all at once, vs
having to manage and individually free particular items...).


so, alas, maybe this is why "conventions" are disliked...
the idea of each separate major library and subsystem having its
own mini subset of the C runtime...

but, hell, it works for me...

one just has to understand my naming conventions.

simple hint:
if using anything that does not use my "library" notation, and does
not have the same name prefix as the other code around it, take
caution...
SXIL_
BASM_
BGBCC_
...

if in "SXIL" one sees a function call with a "BGBCC" prefix, this
itself is a flag for alarm...

note "sxil" or "basm" is not as bad (since these are typically
simple utility functions), but still cause for concern (for
example, in the case of the string functions, they may intern the
string in the wrong heap, or potentially none at all...).

but, alas, a good portion of my "style" revolves around naming
conventions...

So that's why we C++ guys prefer std::string, which solves all of
this. :-)


yep...

C++ is for those who can safely use it though...

On 31 July, 16:46, Juha Nieminen <nos... at (no spam) thanks.invalid> wrote:
Nick Keighley wrote:

what coding conventions does C typically use that C++ typically
doesn't? Isn't the use of RAII a massive coding convention?

No. RAII is certainly not a coding convention. It's a compiler
technique and has little to do with coding conventions. A coding
convention is something the *programmer* does, while RAII is
something the *compiler* does automatically.

well, you've got to write your destructors correctly.
I'd say using RAII correctly was very much a programmer
thing.

void process_pdu (const byte* pdu, size_t size)
{
Msg* msg = new Msg (pdu, size);
process_msg (msg);
delete msg;
}

If, for example, I instantiate and manipulate a std::string in a
function, I don't need *any* coding conventions to make sure that the
string gets freed: The compiler is going to free it for me. I don't
have to do anything to achieve that.

there are things other than strings

In C, however, if I use a dynamic string in a function, I have to
free it myself, and to avoid leaks in complicated functions I have
to use some coding principles to make sure that the string gets
freed no matter how the function is exited.

That's precisely what I'm talking about: RAII aids me in avoiding a
useless coding convention which I would have to use in C to make the
my code safer.

Oh,I'm not arging *against* RAII I'm simply saying using it
and avoiding other exception unsafty requires some discipline
(aka coding conventions)

Nick Keighley wrote:

well, you've got to write your destructors correctly.

"Juha Nieminen" <nospam at (no spam) thanks.invalid> wrote in message
news:w0Hcm.217$sW4.146 at (no spam) read4.inet.fi...
BGB / cr88192 wrote:
you seem to be opposing "coding conventions".
coding conventions can be more or less equated with code being well
written...

I'm not opposing coding conventions. I use lots of coding
conventions when I develop programs.

What I oppose are coding conventions which exist solely to get
around limitations of the language. These tend to make programs more
complex than they need to be.

Yes, I readily admit that programming in C++ is in no way free of
necessary coding conventions which exist because of the limitations
of C++ (compared to many higher-level languages). My point is,
however, that in well-written C++ *less* coding conventions of this
type are needed compared to C, making development simpler. Also,
many of these coding conventions are more familiar to most
experienced C++ programmers and can be seen much more easily (eg.
because they are used by the C++ standard libraries and such). In C
most of these coding conventions are quite programmer-specific.


actually, I refer to what you call "programmer specific" as "style"...

different programmers use different styles, yes, this much is granted.

however, the point is that one recognize the various common styles,
and use a style as appropriate for the code in question.

I have my own style as well, which is sort of a combination of the
Linux kernel, id, and OpenGL styles, or, another way: the Torvalds,
John Carmack, and SGI styles...


one can adhere to certain styles, such that their code looks nice and
pleasing...

so, beyond specific for particular coding conventions, style also
encompasses matters like variable naming, the use of whitespace and
other formatting issues, ...

it is also a good way to spot "outsiders"...


if (...) {
...

"WTF is this?... go away weirdo..."


why should one worry about more vs less conventions?...

Because more coding conventions makes the program more difficult to
read and understand.


personally, I don't see it this way.
the style and conventions are a good portion of the readability,
IMO...

A coding convention is kind of "metalanguage" in the sense that you
are writing in your own "subset" of the programming language. You
use a kind of "meta-C" on top of the bare C programming language,
for the purpose of avoiding pitfalls and errors (such as memory
leaks, etc).

granted...


The problem is that your "metalanguage" might not be immediately
obvious to someone reading your code and who doesn't know about your
coding conventions.


hence, "outsiders"...

they are, naturally enough, to be viewed with suspicion, as they are
bent on fouling up ones' code with their ways...


When these extra coding conventions are *not needed* (rather than
intentionally avoided), the code tends to be more straightforward and
simpler, without any hidden "metalanguage" being used.

not sure why...


my main reason for not going through all of the usual conventions is
when quickly beating together something under the "make it work"
goal...
but typically, this sort of code tends to be ugly, buggy, and just
generally horrid...

and so, later, I clean it up...



it is like being in a store, and noticing all the terribly ill-behaved
children, and then being reminded of a certain rule: "children should
be seen but not heard"...

impulsive behavior and noise one year, is fornication and moral
depravity the next...

"he who spares the rod hates his son."