Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
C and C++
414 views
Skip to first unread message
Bill Cunningham
Oct 31, 2013, 8:09:13 PM10/31/13
to
Ok what is it that's so much easier in C++ than C? It's been so long
since I've looked at C++ I can't remember much about it. Instead of free()
you can use delete if I remember right. You need a whole extra header
fstream in order to save to files. Is it worth the overhead in the binaries?
iostream is a big library.
Bill
since I've looked at C++ I can't remember much about it. Instead of free()
you can use delete if I remember right. You need a whole extra header
fstream in order to save to files. Is it worth the overhead in the binaries?
iostream is a big library.
Bill
Victor Bazarov
Oct 31, 2013, 7:59:36 PM10/31/13
to
V
--
I do not respond to top-posted replies, please don't ask
Barry Schwarz
Oct 31, 2013, 11:59:19 PM10/31/13
to
On Thu, 31 Oct 2013 19:09:13 -0500, "Bill Cunningham"
<nos...@nspam.invalid> wrote:
> Ok what is it that's so much easier in C++ than C? It's been so long
Given the problems you have demonstrated with C, it is unlikely that
<nos...@nspam.invalid> wrote:
> Ok what is it that's so much easier in C++ than C? It's been so long
C++ holds any advantage for you.
>since I've looked at C++ I can't remember much about it. Instead of free()
>you can use delete if I remember right. You need a whole extra header
>fstream in order to save to files. Is it worth the overhead in the binaries?
is including one more a big deal?
>iostream is a big library.
only the functions required for your program
--
Remove del for email
Alf P. Steinbach
Nov 1, 2013, 12:03:42 AM11/1/13
to
On 01.11.2013 01:09, Bill Cunningham wrote:
> Ok what is it that's so much easier in C++ than C? It's been so long
> since I've looked at C++ I can't remember much about it.
Recall that C++ was originally "C with classes".
> Ok what is it that's so much easier in C++ than C? It's been so long
> since I've looked at C++ I can't remember much about it.
So that's the basic thing that originally was added to C to create C++.
Essentially it's about having /language support/, with strict type
checking, of what you have to do manually in C. For example:
* C++ supports derived classes. In C you have to cast to/from a
conceptual "base class member" placed first in the struct.
* C++ supports the o.m() notation for member functions. In C you have to
write m( &o ), and (modulo some "generics" support introduced in C11)
you have to invent different names for m overloads.
* C++ supports virtual member functions in a type safe way. Doing this
manually in C is a nightmare, even with supporting macros, and involves
a lot of very unsafe casting. Essentially, C++ has a /type safe implicit
downcast/, but you don't see it until you try to do the same in C, at
which point most programmers choose to trade away some efficiency in
order to simplify the programming, which IMHO trades away the whole
point of using C in the first place.
I suspect the third point was why Bjarne found it worthwhile to create a
language extension, which turned into a whole new language with support
for far more than that. Including, as you did recall, more easily
customizable allocation machinery. Which is in support of the strong
typing, namely an all-or-nothing guarantee for allocation +
initialization, sort of like a database transaction but transparently.
However, the all-or-nothing guarantee for allocation + initialization
requires exceptions and so it wasn't added until around 1990 somewhere
(1989? I can't recall).
In short, at the start it was virtual member functions, with that
ordinarily-not-very-apparent implicit type safe downcasting.
> Instead of free() you can use delete if I remember right.
And this machinery ties in with the all-or-nothing guarantee for
allocation + initialization.
And that guarantee ties in with and requires exceptions.
Exceptions are another thing that that you really don't want to do
manually in C. But then the difficulty of doing it in C means that most
"pure C" programmers are unfamiliar with it and therefore utterly fail
to see the utility. Like, why on Earth would we want that complication?
Well, they /simplify/ things directly, when you have language support,
and they make possible the allocation + initialization all-or-nothing
guarantee, which is of immense practical value. They do have a steep
cost, though, namely that the supporting internal machinery must be
dynamically initialized, which can be difficult to arrange in e.g.
driver software. Also, difficult for embedded programming.
As I recall Bjarne postponed adding exceptions until Andrew Koenig and
he arrived at some satisfactory ideas about it. At that time exception
handling had been added in a number of languages (notably Ada, but
academics will no doubt prefer to mention e.g. Common Lisp), so it did
not require genius to see its utility, merely familiarity with the
programming world outside the C sphere. E.g. I remember writing an
enthusiastic article about Ada exception handling in the middle 80s. But
I think it did require folks like Bjarne and Andrew in order to see how
to integrate that concept with C, and how it could offer new and very
useful guarantees, thereby greatly simplifying the programming.
> You need a whole extra header
> fstream in order to save to files. Is it worth the overhead in the binaries?
> iostream is a big library.
For small toy programs, yes, why not.
One notch up in size you (or I) start considering alternatives.
Even more up in size, hey, that added size overhead is now insignificant.
But the main reason that I'd like to avoid iostreams as much as possible
is that they generally cause needlessly verbose, complex and brittle
client code, with usually pretty inefficient i/o, all in order to get a
little type safety that by no means is very complete. It sort of reminds
me of Benjamin Franklin. Readers can probably guess why.
Cheers & hth.,
- Alf
Alf P. Steinbach
Nov 1, 2013, 1:10:42 AM11/1/13
to
On 01.11.2013 04:59, Barry Schwarz wrote:
> On Thu, 31 Oct 2013 19:09:13 -0500, "Bill Cunningham"
> <nos...@nspam.invalid> wrote:
>
>> Ok what is it that's so much easier in C++ than C? It's been so long
>
> Given the problems you have demonstrated with C, it is unlikely that
> C++ holds any advantage for you.
Regardless of the merit or lack thereof of the above evaluation of the
> On Thu, 31 Oct 2013 19:09:13 -0500, "Bill Cunningham"
> <nos...@nspam.invalid> wrote:
>
>> Ok what is it that's so much easier in C++ than C? It's been so long
>
> Given the problems you have demonstrated with C, it is unlikely that
> C++ holds any advantage for you.
OP, very few clc++ readers will benefit from that statement.
The statement is also quite offensive.
I know, we're not yet at the point again where out-of-the-blue
needlessly offensive statements are not ordinary in clc++, and perhaps
we'll never get there again, but it's a good ideal to aim for.
>> since I've looked at C++ I can't remember much about it. Instead of free()
>> you can use delete if I remember right. You need a whole extra header
>
> You remember wrong.
free() with delete and don't correspondingly replace malloc with new) as
adversarial. I would say that Bill does remember correctly -- then
choosing a more natural interpretation where the statement makes sense.
>> fstream in order to save to files. Is it worth the overhead in the binaries?
>
> Wrong again.
> Besides, headers don't result in any object code
It also misrepresents the OP, who has not claimed anything in that
direction.
> so why is including one more a big deal?
>> iostream is a big library.
>
> It doesn't matter how big the library is.
effort needed to learn how to use it, and the effort needed to test and
correct client code. In other words, there's a fairly direct connection
between library size and financial cost (in man-hours) of using it.
> The linker will bring in
> only the functions required for your program
iostreams, which the OP is discussing, is well known for adding a fair
amount of baggage.
- Alf
Ian Collins
Nov 1, 2013, 3:24:05 AM11/1/13
to
Alf P. Steinbach wrote:
> On 01.11.2013 04:59, Barry Schwarz wrote:
>> On Thu, 31 Oct 2013 19:09:13 -0500, "Bill Cunningham"
>> <nos...@nspam.invalid> wrote:
>>
>>> Ok what is it that's so much easier in C++ than C? It's been so long
>>
>> Given the problems you have demonstrated with C, it is unlikely that
>> C++ holds any advantage for you.
>
> Regardless of the merit or lack thereof of the above evaluation of the
> OP, very few clc++ readers will benefit from that statement.
>
> The statement is also quite offensive.
"Bill" is well known on c.l.c, renowned for asking almost the same
> On 01.11.2013 04:59, Barry Schwarz wrote:
>> On Thu, 31 Oct 2013 19:09:13 -0500, "Bill Cunningham"
>> <nos...@nspam.invalid> wrote:
>>
>>> Ok what is it that's so much easier in C++ than C? It's been so long
>>
>> Given the problems you have demonstrated with C, it is unlikely that
>> C++ holds any advantage for you.
>
> Regardless of the merit or lack thereof of the above evaluation of the
> OP, very few clc++ readers will benefit from that statement.
>
> The statement is also quite offensive.
question many times over many years. Anyone familiar with that group
would agree with Barry.
--
Ian Collins
Stuart
Nov 1, 2013, 8:48:41 AM11/1/13
to
On 01.11.2013 04:59, Barry Schwarz wrote:
[snip]
>> Given the problems you have demonstrated with C, it is unlikely that
>> C++ holds any advantage for you.
>> C++ holds any advantage for you.
On 13/11/01, Alf P. Steinbach wrote:
> Regardless of the merit or lack thereof of the above evaluation of the
> OP, very few clc++ readers will benefit from that statement.
Probably true. If Barry had written "The problems you have shown to us
> Regardless of the merit or lack thereof of the above evaluation of the
> OP, very few clc++ readers will benefit from that statement.
in previous posts indicate that C++ is in fact not better suited for
your specific problem space than C.", it would have been much more
clearer to the "average" clc++ reader.
> The statement is also quite offensive.
offensive. My formulation would have been "I think that your statement
is offensive".
> I know, we're not yet at the point again where out-of-the-blue
> needlessly offensive statements are not ordinary in clc++, and
> perhaps we'll never get there again, but it's a good ideal to aim
> for.
Regards,
Stuart
Juha Nieminen
Nov 1, 2013, 9:41:14 AM11/1/13
to
Bill Cunningham <nos...@nspam.invalid> wrote:
> Ok what is it that's so much easier in C++ than C?
http://warp.povusers.org/programming/cplusplus_superior_to_c.html
> Ok what is it that's so much easier in C++ than C?
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Paul ( The Troll )
Nov 1, 2013, 11:51:25 AM11/1/13
to
On Thursday, 31 October 2013 23:09:13 UTC, Bill Cunningham wrote:
> Ok what is it that's so much easier in C++ than C?
C++ References are very good.
> Ok what is it that's so much easier in C++ than C?
>It's been so long
>
> since I've looked at C++ I can't remember much about it. Instead of free()
>
> you can use delete if I remember right. You need a whole extra header
>
> fstream in order to save to files. Is it worth the overhead in the binaries?
>
> iostream is a big library.
>
>
>
woodb...@gmail.com
Nov 1, 2013, 12:09:56 PM11/1/13
to
their own source/implementation files in order to minimize the
size of executables. I sometimes split a function off into a
separate file like that.
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
Leigh Johnston
Nov 1, 2013, 3:24:30 PM11/1/13
to
/Leigh
David Harmon
Nov 1, 2013, 3:42:26 PM11/1/13
to
On Thu, 31 Oct 2013 19:09:13 -0500 in comp.lang.c++, "Bill
Cunningham" <nos...@nspam.invalid> wrote,
easier in C++ to organize your code so that parts that should have
nothing to do with each other don't, in fact, depend on each other.
Cunningham" <nos...@nspam.invalid> wrote,
> Ok what is it that's so much easier in C++ than C? It's been so long
There are may possible answers to that, but I'll pick just one. It's
easier in C++ to organize your code so that parts that should have
nothing to do with each other don't, in fact, depend on each other.
osmium
Nov 1, 2013, 5:34:57 PM11/1/13
to
Paul ( The Troll )
Nov 1, 2013, 10:46:20 PM11/1/13
to
David Harmon
Nov 2, 2013, 3:14:19 PM11/2/13
to
On Fri, 1 Nov 2013 15:34:57 -0600 in comp.lang.c++, "osmium"
<r124c...@comcast.net> wrote,
You are wooshed? For a explanation at longer length, see Alf's post
in this thread. Suffice it to say that if you try to start out by
debating free vs. delete or printf vs. iostreams, as did the OP, the
real point will inevitably whoosh by you. To get the full benefit
of c++ you need to think in terms of program design first.
>
<r124c...@comcast.net> wrote,
in this thread. Suffice it to say that if you try to start out by
debating free vs. delete or printf vs. iostreams, as did the OP, the
real point will inevitably whoosh by you. To get the full benefit
of c++ you need to think in terms of program design first.
>
osmium
Nov 2, 2013, 6:38:12 PM11/2/13
to
down from what you said to some real substance..
I think Bill could do much better by typing "what are the advantages of
object oriented programming languages" into google. Without the quotes.
Someone said the thing that would benefit Bill most was references, I agree
with that reading of the situation, I came up with that same notion,
independently but did not post it. I also agree with whoever said Bill's
post was very troll like. .
David Harmon
Nov 2, 2013, 10:33:59 PM11/2/13
to
On Sat, 2 Nov 2013 16:38:12 -0600 in comp.lang.c++, "osmium"
<r124c...@comcast.net> wrote,
with good old c pointers. When you combine the simplified syntax of
references with c++ overloaded functions and templates then they
start to get powerful. Most c++ "features" are like that: they work
together.
<r124c...@comcast.net> wrote,
>Someone said the thing that would benefit Bill most was references,
But references, by themselves, buy you very little more than you get
with good old c pointers. When you combine the simplified syntax of
references with c++ overloaded functions and templates then they
start to get powerful. Most c++ "features" are like that: they work
together.
Jorgen Grahn
Nov 3, 2013, 3:41:15 AM11/3/13
to
On Fri, 2013-11-01, Juha Nieminen wrote:
> Bill Cunningham <nos...@nspam.invalid> wrote:
>> Ok what is it that's so much easier in C++ than C?
>
> http://warp.povusers.org/programming/cplusplus_superior_to_c.html
I promised myself not to contribute to this thread, but ...
> Bill Cunningham <nos...@nspam.invalid> wrote:
>> Ok what is it that's so much easier in C++ than C?
>
> http://warp.povusers.org/programming/cplusplus_superior_to_c.html
I agree with more or less all of that. Read it first, and then
I'm willing to discuss any remaining unclear points.
/Jorgen
PS. The text would be more powerful if the author's name (Mr Nieminen,
I suppose) was there.
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
woodb...@gmail.com
Nov 3, 2013, 7:12:03 AM11/3/13
to
On Sunday, November 3, 2013 2:41:15 AM UTC-6, Jorgen Grahn wrote:
> On Fri, 2013-11-01, Juha Nieminen wrote:
> > Bill Cunningham <nos...@nspam.invalid> wrote:
>
> >> Ok what is it that's so much easier in C++ than C?
>
> > http://warp.povusers.org/programming/cplusplus_superior_to_c.html
>
> I promised myself not to contribute to this thread, but ...
> I agree with more or less all of that. Read it first, and then
> I'm willing to discuss any remaining unclear points.
>
>
You say it would be more powerful if the author's name were
> On Fri, 2013-11-01, Juha Nieminen wrote:
> > Bill Cunningham <nos...@nspam.invalid> wrote:
>
> >> Ok what is it that's so much easier in C++ than C?
>
> > http://warp.povusers.org/programming/cplusplus_superior_to_c.html
>
> I promised myself not to contribute to this thread, but ...
> I agree with more or less all of that. Read it first, and then
> I'm willing to discuss any remaining unclear points.
>
>
there. I think it would be better with fewer adjectives and
adverbs.
"You can completely safely have such a struct"
I'd write it as
You can safely have such a struct
There's an "exels" in the conclusion that looks misspelled.
osmium
Nov 3, 2013, 11:00:47 AM11/3/13
to
c.l.c for eight years or so and has been making little progress. He claims
to be on medication for a problem of some sort which impacts his mind.
There is even the possibility that he is a *very good* troll.
Bill would be even more whooshed by your initial post than I was, references
would have been a nice addition to C, going beyond that gets complicated..
Bill Cunningham
Nov 4, 2013, 3:28:13 AM11/4/13
to
classes ? What would make C++ a good add on to C?
Bill
Bill Cunningham
Nov 4, 2013, 3:30:09 AM11/4/13
to
Juha Nieminen wrote:
> Bill Cunningham <nos...@nspam.invalid> wrote:
>> Ok what is it that's so much easier in C++ than C?
>
> http://warp.povusers.org/programming/cplusplus_superior_to_c.html
Thanks for the link.
> Bill Cunningham <nos...@nspam.invalid> wrote:
>> Ok what is it that's so much easier in C++ than C?
>
> http://warp.povusers.org/programming/cplusplus_superior_to_c.html
Bill
Bill Cunningham
Nov 4, 2013, 3:33:00 AM11/4/13
to
*any* usenet post is a troll. *All* questions can be asked of google and
*any* response answers all possible questions.
I'm going to butt out now.
Barry Schwarz
Nov 4, 2013, 1:38:06 AM11/4/13
to
On Fri, 01 Nov 2013 06:10:42 +0100, "Alf P. Steinbach"
<alf.p.stein...@gmail.com> wrote:
>On 01.11.2013 04:59, Barry Schwarz wrote:
>> On Thu, 31 Oct 2013 19:09:13 -0500, "Bill Cunningham"
>> <nos...@nspam.invalid> wrote:
>>
>>> Ok what is it that's so much easier in C++ than C? It's been so long
>>
>> Given the problems you have demonstrated with C, it is unlikely that
>> C++ holds any advantage for you.
>
>Regardless of the merit or lack thereof of the above evaluation of the
>OP, very few clc++ readers will benefit from that statement.
Since the OP was asking advice for himself, any benefit to other
<alf.p.stein...@gmail.com> wrote:
>On 01.11.2013 04:59, Barry Schwarz wrote:
>> On Thu, 31 Oct 2013 19:09:13 -0500, "Bill Cunningham"
>> <nos...@nspam.invalid> wrote:
>>
>>> Ok what is it that's so much easier in C++ than C? It's been so long
>>
>> Given the problems you have demonstrated with C, it is unlikely that
>> C++ holds any advantage for you.
>
>Regardless of the merit or lack thereof of the above evaluation of the
>OP, very few clc++ readers will benefit from that statement.
readers is secondary.
>The statement is also quite offensive.
Was it the statement of fact that Bill has a long history of
posts documenting his difficulty in mastering basic C concepts? Since
he has explicitly addressed this problem numerous times in his own
posts, this is neither a surprise nor an insult.
Perhaps it was the assertion that moving on to a more
advanced/complex language without understanding the basics will not
prove fruitful? You can take offense at that if you want but learning
to walk before attempting to run is still sound advice. There is a
reason algebra is a prerequisite for trigonometry and calculus.
>I know, we're not yet at the point again where out-of-the-blue
>needlessly offensive statements are not ordinary in clc++, and perhaps
>we'll never get there again, but it's a good ideal to aim for.
yet ready to move up is just an honest evaluation. In my opinion,
misleading him to think otherwise would be even more offensive.
>>> since I've looked at C++ I can't remember much about it. Instead of free()
>>> you can use delete if I remember right. You need a whole extra header
>>
>> You remember wrong.
>
>That depends on the interpretation. I see your interpretation (replace
>free() with delete and don't correspondingly replace malloc with new) as
>adversarial. I would say that Bill does remember correctly -- then
>choosing a more natural interpretation where the statement makes sense.
you. But many of us have seen him get fixated on a quote out of
context with no appreciation of the nuances or ramifications. This is
not adversarial; it is simply an attempt to prevent a mistaken idea
from gathering too much steam.
>>> fstream in order to save to files. Is it worth the overhead in the binaries?
>>
>> Wrong again.
>
>I'm sorry, but that statement does not make sense to me.
>> Besides, headers don't result in any object code
>
>Sorry, that's incorrect.
generated?
>It also misrepresents the OP, who has not claimed anything in that
>direction.
it does, I'd like to learn how.
>> so why is including one more a big deal?
>Including headers add to build time.
>
>
>>> iostream is a big library.
>>
>> It doesn't matter how big the library is.
>
>Oh, it does. In particular for its complexity, which affects both the
>effort needed to learn how to use it, and the effort needed to test and
>correct client code. In other words, there's a fairly direct connection
>between library size and financial cost (in man-hours) of using it.
>
>
>> The linker will bring in
>> only the functions required for your program
>
>If one is lucky.
>
>iostreams, which the OP is discussing, is well known for adding a fair
>amount of baggage.
Alf P. Steinbach
Nov 4, 2013, 3:03:29 AM11/4/13
to
On 04.11.2013 07:38, Barry Schwarz wrote:
> On Fri, 01 Nov 2013 06:10:42 +0100, "Alf P. Steinbach"
> On Fri, 01 Nov 2013 06:10:42 +0100, "Alf P. Steinbach"
>> On 01.11.2013 04:59, Barry Schwarz wrote:
>
>>> Besides, headers don't result in any object code
>>
>> Sorry, that's incorrect.
>
> Enlighten me please. Which standard headers result in code being
> generated?
First though, readers may note that Barry's first statement above is a
>
>>> Besides, headers don't result in any object code
>>
>> Sorry, that's incorrect.
>
> Enlighten me please. Which standard headers result in code being
> generated?
misrepresentation of the OP, in order to attack him, and that the second
statement is a slight misrepresentation of my response.
Now, technically even a C header can contain definitions. But in C++
this is supported by the language, and therefore generally in C++ it
causes no problem except header size bloat and some machine code bloat.
Depending on the compiler the machine code bloat can be optimized away.
Indeed, the bloat caused by templated code is largely a thing of the
past, with nobody teaching the workarounds anymore. But, for example,
the language guarantees that the iostream objects are initialized at or
prior to inclusion of <iostream>, which brings in the whole machinery,
and a compiler has to be pretty darn smart to optimize that away.
[code]
#include <stdio.h>
#ifdef IOSTREAM
# include <iostream>
#endif
#ifdef FSTREAM
# include <fstream>
#endif
auto main() -> int
{ printf( "Blah blah\n" ); }
[/code]
[example]
[D:\dev\test]
> rem create a batch file to report file size cleanly
[D:\dev\test]
> type con >size.bat
@for %%f in (%*) do @echo %%~zf bytes
^Z
[D:\dev\test]
> rem test with MinGW g++ compiler.
[D:\dev\test]
> g++ foo.cpp -O2 && size a.exe
54539 bytes
[D:\dev\test]
> g++ foo.cpp -O2 -D IOSTREAM && size a.exe
55768 bytes
[D:\dev\test]
> rem test with visual c++ compiler
[D:\dev\test]
> cl foo.cpp -O2 /Feb && size b.exe
foo.cpp
57344 bytes
[D:\dev\test]
> cl foo.cpp -O2 /Feb -D IOSTREAM && size b.exe
foo.cpp
77312 bytes
[D:\dev\test]
> _
[/example]
Leigh Johnston
Nov 4, 2013, 12:14:43 PM11/4/13
to
anally retentive and fucktarded that words almost escape me.
/Leigh
Öö Tiib
Nov 4, 2013, 1:35:25 PM11/4/13
to
participate" in plain English?
I just see 8 characters added with purpose to make clear that it is C++
not C code.
Leigh Johnston
Nov 4, 2013, 1:45:17 PM11/4/13
to
as yourself.
/Leigh
James Kanze
Nov 5, 2013, 12:05:48 PM11/5/13
to
On Friday, 1 November 2013 16:09:56 UTC, woodb...@gmail.com wrote:
> On Friday, November 1, 2013 12:10:42 AM UTC-5, Alf P. Steinbach wrote:
> > On 01.11.2013 04:59, Barry Schwarz wrote:
> > > The linker will bring in
> > > only the functions required for your program
> > If one is lucky.
> I think Mr. Kanze and others have talked about giving functions
> their own source/implementation files in order to minimize the
> size of executables. I sometimes split a function off into a
> separate file like that.
The case for fstream is different, because it is a template.
> On Friday, November 1, 2013 12:10:42 AM UTC-5, Alf P. Steinbach wrote:
> > On 01.11.2013 04:59, Barry Schwarz wrote:
> > > The linker will bring in
> > > only the functions required for your program
> > If one is lucky.
> I think Mr. Kanze and others have talked about giving functions
> their own source/implementation files in order to minimize the
> size of executables. I sometimes split a function off into a
> separate file like that.
Basically, there are three cases to consider:
-- Non-template non-virtual functions: There is no difference
between C and C++ here. The granularity of the linker (at
least most linkers) is the object file. If you put each of
your functions in a separate source file, then the linker
will pull in exactly what is needed, no more, no less. If
you put all of your functions in one big source file, the
linker will plu in all of your functions. Both in C and in
C+++.
-- Virtual functions: A virtual function is "used" any time the
class is instantiated (since its address will appear in the
vtable). If you instantiate a class of type C, then all of
the virtual functions of class C will be pulled in,
regardless of how you organize your source files.
-- Function templates (and member functions of class
templates): The linker generally has nothing to do with
this. The templates will be instantiated if they are used,
and not otherwise. (And here, again, virtual member
functions are "used" anytime the class itself is
instantiated.)
std::fstream is a class template, so the last point applies. It
does have virtual functions, but one, the destructor, will be
used, forceably, and the only other one, rdbuf, is more or less
trivial.
In fact, in this case, unless the implementation uses fprintf or
sprintf in its implementation, the C++ model should result in
far less code being pulled in. If you use printf, for example,
you will pull in all of the code for floating point formatting,
even if your program doesn't have a single floating point value
in it. (Older readers may remember that early implementations
of C generally had two implementations of the library, one with
floating point support, and one without. Because the floating
point support did take up a lot of space, and without virtual
memory and with only 64KB of memory, that space was important.)
--
James
James Kanze
Nov 5, 2013, 12:28:03 PM11/5/13
to
On Monday, 4 November 2013 06:38:06 UTC, Barry Schwarz wrote:
> On Fri, 01 Nov 2013 06:10:42 +0100, "Alf P. Steinbach"
> <alf.p.stein...@gmail.com> wrote:
>
> >On 01.11.2013 04:59, Barry Schwarz wrote:
> >> On Thu, 31 Oct 2013 19:09:13 -0500, "Bill Cunningham"
[...]
> On Fri, 01 Nov 2013 06:10:42 +0100, "Alf P. Steinbach"
> <alf.p.stein...@gmail.com> wrote:
>
> >On 01.11.2013 04:59, Barry Schwarz wrote:
> >> On Thu, 31 Oct 2013 19:09:13 -0500, "Bill Cunningham"
> Perhaps it was the assertion that moving on to a more
> advanced/complex language without understanding the basics will not
> prove fruitful?
From the users point of view, C++ is a simpler, less complex
> advanced/complex language without understanding the basics will not
> prove fruitful?
language than C, because it automatically takes care of some of
the more complex issues (like string handling and arrays that
actually work) for you. There *are* a number of unnecessary
complications, but most of the ones which actually cause
practical problems when programming (like double silently
converting to an int) are inherited from C.
[...]
> >> Besides, headers don't result in any object code
> >Sorry, that's incorrect.
> Enlighten me please. Which standard headers result in code being
> generated?
<iostream>. "The results of including <iostream> in
> >Sorry, that's incorrect.
> Enlighten me please. Which standard headers result in code being
> generated?
a translation unit shall be as if <iostream> defined an instance
of ios_base::Init with static storage duration." ios_base::Init
has a trivial constructor and destructor, and the compiler must
generate code to ensure that they are called.
Of course, there will usually be only one or two sources which
incluce <iostream>, so the total impact on code size will be
minimal.
> >It also misrepresents the OP, who has not claimed anything in that
> >direction.
> He said including the header fstream adds overhead to a program. If
> it does, I'd like to learn how.
It's rare that code size due to IO is a problem, but compared to
C, C++ should require less library code (supposing the library
is written intelligently), but there will be more code at the
client side: "fprintf( f, "%d\n", i )" pulls in all of the
output formatting code, including that for floating point, but
at the call site, it is a single function with three arguments;
"f << i << std::endl" only pulls in the code for formatting
integers, but will result in two function calls at the call
site, each one with two arguments.
Of course, if someone later changes i to type long, the
C version suddenly ends up with undefined behavior, where as the
C++ version just goes one working correctly. But since no one
ever has to maintain a program, who cares.
--
James
James Kanze
Nov 5, 2013, 12:32:37 PM11/5/13
to
On Monday, 4 November 2013 17:14:43 UTC, Leigh Johnston wrote:
> > auto main() -> int
> Writing "auto main() -> int" instead of the canonical "int main()" is so
> anally retentive and fucktarded that words almost escape me.
Now, now. Some people like obfuscation, or change just for
> > auto main() -> int
> Writing "auto main() -> int" instead of the canonical "int main()" is so
> anally retentive and fucktarded that words almost escape me.
changes sake. Or maybe he's paid by the character: the above
replaces a very clear 10 character sequence with an
18 character sequence which isn't quite as clear, at least for
current C++ programmers.
--
James
James Kanze
Nov 5, 2013, 12:42:31 PM11/5/13
to
On Friday, 1 November 2013 13:41:14 UTC, Juha Nieminen wrote:
> Bill Cunningham <nos...@nspam.invalid> wrote:
> > Ok what is it that's so much easier in C++ than C?
> http://warp.povusers.org/programming/cplusplus_superior_to_c.html
That's a good article, but it misses the most important point:
> Bill Cunningham <nos...@nspam.invalid> wrote:
> > Ok what is it that's so much easier in C++ than C?
> http://warp.povusers.org/programming/cplusplus_superior_to_c.html
in C, you define a struct and a number of functions to
manipulate it, and you cross your fingers that no one accesses
any of the members except through your functions (or you only
provide a forward declaration of the struct, and add a factory
function, and require all instances to be dynamically
allocated); in C++, you make the data private, the functions
members, and if the struct itself needs dynamic memory (or any
other resources), you add a constructor and a destructor. In
fact, you probably add a constructor regardless, to ensure that
no one accidentally uses the date before it it is initialized.
This simple difference means that any time more than one
programmer is working on the code, or the code must be
maintained for more that six months, C++ is a better choice.
Even if you don't need polymorphism or templates or operator
overloading or function overloading.
This simple difference also means that from a practical point of
view, using C++ will result in shorter time to market, and less
total cost over the program lifetime. (Of course, the
additional features can in many cases reduce time to market and
total costs even more.)
--
James
James Kanze
Nov 5, 2013, 12:47:26 PM11/5/13
to
On Friday, 1 November 2013 19:24:30 UTC, Leigh Johnston wrote:
> On 01/11/2013 15:51, Paul ( The Troll ) wrote:
> One shouldn't use printf in a C++ program. printf is not type safe.
And it's not extensible. And you can't add output for user defined
> One shouldn't use printf in a C++ program. printf is not type safe.
types. And you can't add new targets (and you need a differently
named function just to get a string). And you can't add new
formatting options for your own types.
The printf family is hardly usable.
--
James
Alf P. Steinbach
Nov 5, 2013, 12:57:51 PM11/5/13
to
There is of course a good rationale. I do not do things willy-nilly.
Leigh Johnston
Nov 5, 2013, 1:03:26 PM11/5/13
to
/Leigh
Cholo Lennon
Nov 5, 2013, 2:59:54 PM11/5/13
to
best case to use the trailing return syntax. C'mon, it's the well known
function main, why change its shape?
Best regards
--
Cholo Lennon
Bs.As.
ARG
woodb...@gmail.com
Nov 5, 2013, 4:30:45 PM11/5/13
to
On Tuesday, November 5, 2013 12:03:26 PM UTC-6, Leigh Johnston wrote:
Please don't swear here.
Please don't swear here.
Leigh Johnston
Nov 5, 2013, 5:15:20 PM11/5/13
to
On 05/11/2013 21:30, woodb...@gmail.com wrote:
> On Tuesday, November 5, 2013 12:03:26 PM UTC-6, Leigh Johnston wrote:
>
> Please don't swear here.
Fuck off.
> On Tuesday, November 5, 2013 12:03:26 PM UTC-6, Leigh Johnston wrote:
>
> Please don't swear here.
Juha Nieminen
Nov 7, 2013, 6:30:09 AM11/7/13
to
In C there's a kludge around that problem, and it's to use, basically,
the Pimpl idiom using an opaque pointer. The two biggest problems with
this are, of course, that the program becomes automatically more
error-prone (because it becomes easier to make mistakes and have leaks,
double frees, or accessing freed memory), and the program becomes less
efficient because every instance of that struct needs to be allocated
dynamically (which, as we know, is a really heavy operation.)
Quite ironically, this makes the C implementation a lot less efficient
than the proper C++ implementation. (It's ironic because many C advocates
argue that C is faster and more efficient than C++.)
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
the Pimpl idiom using an opaque pointer. The two biggest problems with
this are, of course, that the program becomes automatically more
error-prone (because it becomes easier to make mistakes and have leaks,
double frees, or accessing freed memory), and the program becomes less
efficient because every instance of that struct needs to be allocated
dynamically (which, as we know, is a really heavy operation.)
Quite ironically, this makes the C implementation a lot less efficient
than the proper C++ implementation. (It's ironic because many C advocates
argue that C is faster and more efficient than C++.)
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Scott Lurndal
Nov 7, 2013, 9:58:47 AM11/7/13
to
Juha Nieminen <nos...@thanks.invalid> writes:
It certainly doesn't need to be, and there are many ways to do dynamic
allocation O(1). Even the default malloc is quite efficient. Using mmap
(on unix-like systems) or even using pooled allocators are also quite
efficient and commonly used.
scott
>James Kanze <james...@gmail.com> wrote:
> and the program becomes less
>efficient because every instance of that struct needs to be allocated
>dynamically (which, as we know, is a really heavy operation.)
Why do you believe that dynamic allocation is "a real heavy operation".
> and the program becomes less
>efficient because every instance of that struct needs to be allocated
>dynamically (which, as we know, is a really heavy operation.)
It certainly doesn't need to be, and there are many ways to do dynamic
allocation O(1). Even the default malloc is quite efficient. Using mmap
(on unix-like systems) or even using pooled allocators are also quite
efficient and commonly used.
scott
Juha Nieminen
Nov 7, 2013, 10:20:55 AM11/7/13
to
Scott Lurndal <sc...@slp53.sl.home> wrote:
> Why do you believe that dynamic allocation is "a real heavy operation".
Because of lots of actual experience. You can measure this yourself.
> Why do you believe that dynamic allocation is "a real heavy operation".
Allocating memory with malloc/new is at least an order of magnitude
slower than allocating a local object on the stack. Also, allocating
many objects individually is also a lot slower than allocating an array
of objects (the larger the amount of objects being instantiated, the
slower it becomes to allocate them individually.)
This can also get worse as the program progresses because of memory
fragmentation and ensuing cache misses (something that stack allocation
is essentially free of, and array allocation almost free of.)
There's a reason why something like std::vector<MyClass> is more efficient
than, for example, std::vector<std::unique_ptr<MyClass>> (where each object
is individually allocated with 'new') and a lot more efficient than
std::vector<std::shared_ptr<MyClass>> (because shared_ptr does its own
allocation in addition to your "new MyClass".)
A more minor inefficiency also comes from the fact that allocating
individual objects consumes more memory because of all the extra
bookkeeping (increased memory consumption means increased chances of
cache misses.)
> It certainly doesn't need to be, and there are many ways to do dynamic
> allocation O(1).
magnitude slower than stack/static/array allocation even if it's O(1).
The asymptotic complexity of the allocation does not say how much slower
it is.
Scott Lurndal
Nov 7, 2013, 12:05:57 PM11/7/13
to
I did point out, where you snipped, that other allocators (pool allocators
for instance) are quite fast, particularly if the allocator function is
inline).
In over 30 years of C and C++ programming, both bare-metal and large application,
I've not found the speed of allocation, when properly designed and utilized,
to be a significant issue.
I've certainly seen programmers abuse dynamic allocation, but that doesn't
mean that dynamic allocation is intrinsically bad, just that bad programmers
exist.
Paavo Helde
Nov 7, 2013, 12:50:06 PM11/7/13
to
sc...@slp53.sl.home (Scott Lurndal) wrote in news:HUNeu.189665$Am5.165093
@fx24.iad:
> Juha Nieminen <nos...@thanks.invalid> writes:
>>James Kanze <james...@gmail.com> wrote:
>
>
>> and the program becomes less
>>efficient because every instance of that struct needs to be allocated
>>dynamically (which, as we know, is a really heavy operation.)
>
> Why do you believe that dynamic allocation is "a real heavy operation".
Because it is.
> It certainly doesn't need to be, and there are many ways to do dynamic
> allocation O(1). Even the default malloc is quite efficient. Using
mmap
> (on unix-like systems) or even using pooled allocators are also quite
> efficient and commonly used.
Obtaining memory pages from OS is typically not a bottleneck, it is done
in large chunks and the memory gets reused inside the process.
In multi-threaded programs, the major bottleneck seems to be
synchronizing the global allocator data structures across the cores,
especially if there are multiple processors/sockets. There are some
allocators like Intel's TBB which scale better here, and Linux glibc
allocator has also become quite good, but any dynamic allocation is still
a relatively heavy-weight operation.
Cheers
Paavo
@fx24.iad:
> Juha Nieminen <nos...@thanks.invalid> writes:
>>James Kanze <james...@gmail.com> wrote:
>
>
>> and the program becomes less
>>efficient because every instance of that struct needs to be allocated
>>dynamically (which, as we know, is a really heavy operation.)
>
> Why do you believe that dynamic allocation is "a real heavy operation".
> It certainly doesn't need to be, and there are many ways to do dynamic
> allocation O(1). Even the default malloc is quite efficient. Using
mmap
> (on unix-like systems) or even using pooled allocators are also quite
> efficient and commonly used.
in large chunks and the memory gets reused inside the process.
In multi-threaded programs, the major bottleneck seems to be
synchronizing the global allocator data structures across the cores,
especially if there are multiple processors/sockets. There are some
allocators like Intel's TBB which scale better here, and Linux glibc
allocator has also become quite good, but any dynamic allocation is still
a relatively heavy-weight operation.
Cheers
Paavo
Seungbeom Kim
Nov 7, 2013, 3:40:55 PM11/7/13
to
On 2013-11-05 09:42, James Kanze wrote:
> On Friday, 1 November 2013 13:41:14 UTC, Juha Nieminen wrote:
>> http://warp.povusers.org/programming/cplusplus_superior_to_c.html
>
> That's a good article, but it misses the most important point:
> [..] in C++, you make the data private
> On Friday, 1 November 2013 13:41:14 UTC, Juha Nieminen wrote:
>> http://warp.povusers.org/programming/cplusplus_superior_to_c.html
>
> That's a good article, but it misses the most important point:
Information hiding is certainly a good thing, but I'm not sure if it's
the most important advantage of C++ over C, though opinions may vary,
of course. Especially when many other languages, including C and other
scripting languages, rely on conventions (e.g. "A name that begins with
an underscore is private.") and it doesn't seem like a major source of
problems. Of course you can break it if you really intend to, but more
or less the same thing can be said of C++ as well. And violations are
easy to spot. On the other hand, things like RAII, exceptions, or
generics are much harder to get right by hand.
--
Seungbeom Kim
Drew Lawson
Nov 7, 2013, 4:16:35 PM11/7/13
to
In article <l5gtss$fi1$1...@usenet.stanford.edu>
discussed a lot. To say that opinions vary is a world class
understatement.
Pick a feature, almost any feature, of C++, and there are knowledgeable
posters who will claim that it is essential to the language and
other knowledgeable posters who will claim that it is an unimportant
curiosity.
RAII is an "I have seen the light" religion for some and a really
cool convenience for others. Templates are either not very important,
or they are the only essential language contribution. Exceptions
should be thrown all the time or very rarely (though most seem to
agree that stack unwinding is undeniably a Good Thing).
As an exercise in observing sociology, it is actually pretty
interesting.
I use a thin slice of C++ (dictated by project policies, compiler
support and habit). Perhaps obviously, I view the other features
as non-essential.
--
Drew Lawson | Pass the tea and sympathy
| for he good old days are dead
| Let's raise a toast to those
| who best survived the life they led
Seungbeom Kim <musi...@bawi.org> writes:
>On 2013-11-05 09:42, James Kanze wrote:
>> On Friday, 1 November 2013 13:41:14 UTC, Juha Nieminen wrote:
>>> http://warp.povusers.org/programming/cplusplus_superior_to_c.html
>>
>> That's a good article, but it misses the most important point:
>> [..] in C++, you make the data private
>
>Information hiding is certainly a good thing, but I'm not sure if it's
>the most important advantage of C++ over C, though opinions may vary,
>of course.
I don't know how long you have been reading here, but this has been
>On 2013-11-05 09:42, James Kanze wrote:
>> On Friday, 1 November 2013 13:41:14 UTC, Juha Nieminen wrote:
>>> http://warp.povusers.org/programming/cplusplus_superior_to_c.html
>>
>> That's a good article, but it misses the most important point:
>> [..] in C++, you make the data private
>
>Information hiding is certainly a good thing, but I'm not sure if it's
>the most important advantage of C++ over C, though opinions may vary,
>of course.
discussed a lot. To say that opinions vary is a world class
understatement.
Pick a feature, almost any feature, of C++, and there are knowledgeable
posters who will claim that it is essential to the language and
other knowledgeable posters who will claim that it is an unimportant
curiosity.
RAII is an "I have seen the light" religion for some and a really
cool convenience for others. Templates are either not very important,
or they are the only essential language contribution. Exceptions
should be thrown all the time or very rarely (though most seem to
agree that stack unwinding is undeniably a Good Thing).
As an exercise in observing sociology, it is actually pretty
interesting.
I use a thin slice of C++ (dictated by project policies, compiler
support and habit). Perhaps obviously, I view the other features
as non-essential.
--
Drew Lawson | Pass the tea and sympathy
| for he good old days are dead
| Let's raise a toast to those
| who best survived the life they led
woodb...@gmail.com
Nov 7, 2013, 5:04:30 PM11/7/13
to
On Thursday, November 7, 2013 2:40:55 PM UTC-6, Seungbeom Kim wrote:
>
> Information hiding is certainly a good thing, but I'm not sure if it's
> the most important advantage of C++ over C, though opinions may vary,
> of course. Especially when many other languages, including C and other
> scripting languages, rely on conventions (e.g. "A name that begins with
> an underscore is private.") and it doesn't seem like a major source of
> problems. Of course you can break it if you really intend to, but more
> or less the same thing can be said of C++ as well. And violations are
> easy to spot. On the other hand, things like RAII, exceptions, or
> generics are much harder to get right by hand.
>
I'm sympathetic to this view.
>
> Information hiding is certainly a good thing, but I'm not sure if it's
> the most important advantage of C++ over C, though opinions may vary,
> of course. Especially when many other languages, including C and other
> scripting languages, rely on conventions (e.g. "A name that begins with
> an underscore is private.") and it doesn't seem like a major source of
> problems. Of course you can break it if you really intend to, but more
> or less the same thing can be said of C++ as well. And violations are
> easy to spot. On the other hand, things like RAII, exceptions, or
> generics are much harder to get right by hand.
>
Paavo Helde
Nov 8, 2013, 3:35:07 AM11/8/13
to
dr...@furrfu.invalid (Drew Lawson) wrote in news:l5gvvj$11g7$1
@raid.furrfu.com:
together, making the "embrace barrier" higher. For example, exceptions
without RAII would not work well, and RAII without exceptions would not
be so important. Templates would not work well without operator
overloading, and operator overloading would not work well without
references.
The private/public data protection is a somewhat different feature in
that it is mostly orthogonal to other features and does not depend on
them. Basically it is an automatic tool for detecting errors in
encapsulation/modularisation logic and turning them into compile-time
errors. It is useful exactly in those cases where the said logic would
otherwise be hard to comply with (e.g. large and/or evolving programs).
What we are currently missing is a way to detect multithreading errors
like data races and deadlocks and turn them into compile-time errors.
Deadlocks could be for example avoided by enforcing a total consistent
ordering of mutexes and encoding the level of locked mutexes somehow in
the function interfaces. This would be extremely useful in some sort of
programs, even more so than private/public as it is harder to get that
right by hand.
Cheers
Paavo
@raid.furrfu.com:
>
> Pick a feature, almost any feature, of C++, and there are knowledgeable
> posters who will claim that it is essential to the language and
> other knowledgeable posters who will claim that it is an unimportant
> curiosity.
>
> RAII is an "I have seen the light" religion for some and a really
> cool convenience for others. Templates are either not very important,
> or they are the only essential language contribution. Exceptions
> should be thrown all the time or very rarely (though most seem to
> agree that stack unwinding is undeniably a Good Thing).
One factor here might be that some C++ features only work well if used
> Pick a feature, almost any feature, of C++, and there are knowledgeable
> posters who will claim that it is essential to the language and
> other knowledgeable posters who will claim that it is an unimportant
> curiosity.
>
> RAII is an "I have seen the light" religion for some and a really
> cool convenience for others. Templates are either not very important,
> or they are the only essential language contribution. Exceptions
> should be thrown all the time or very rarely (though most seem to
> agree that stack unwinding is undeniably a Good Thing).
together, making the "embrace barrier" higher. For example, exceptions
without RAII would not work well, and RAII without exceptions would not
be so important. Templates would not work well without operator
overloading, and operator overloading would not work well without
references.
The private/public data protection is a somewhat different feature in
that it is mostly orthogonal to other features and does not depend on
them. Basically it is an automatic tool for detecting errors in
encapsulation/modularisation logic and turning them into compile-time
errors. It is useful exactly in those cases where the said logic would
otherwise be hard to comply with (e.g. large and/or evolving programs).
What we are currently missing is a way to detect multithreading errors
like data races and deadlocks and turn them into compile-time errors.
Deadlocks could be for example avoided by enforcing a total consistent
ordering of mutexes and encoding the level of locked mutexes somehow in
the function interfaces. This would be extremely useful in some sort of
programs, even more so than private/public as it is harder to get that
right by hand.
Cheers
Paavo
Ian Collins
Nov 8, 2013, 3:41:00 AM11/8/13
to
Drew Lawson wrote:
>
> Pick a feature, almost any feature, of C++, and there are knowledgeable
> posters who will claim that it is essential to the language and
> other knowledgeable posters who will claim that it is an unimportant
> curiosity.
>
> RAII is an "I have seen the light" religion for some and a really
> cool convenience for others.
It is also the only C++ feature that can't be replicated in C. So you
>
> Pick a feature, almost any feature, of C++, and there are knowledgeable
> posters who will claim that it is essential to the language and
> other knowledgeable posters who will claim that it is an unimportant
> curiosity.
>
> RAII is an "I have seen the light" religion for some and a really
> cool convenience for others.
could argue that RAII alone is enough of a reason to use C++ in place of C.
--
Ian Collins
nick.keig...@gmail.com
Nov 8, 2013, 3:44:52 AM11/8/13
to
On Thursday, 7 November 2013 20:40:55 UTC, Seungbeom Kim wrote:
> On 2013-11-05 09:42, James Kanze wrote:
> > On Friday, 1 November 2013 13:41:14 UTC, Juha Nieminen wrote:
> >> http://warp.povusers.org/programming/cplusplus_superior_to_c.html
>
> > That's a good article, but it misses the most important point:
> > [..] in C++, you make the data private
>
> Information hiding is certainly a good thing, but I'm not sure if it's
> the most important advantage of C++ over C, though opinions may vary,
> of course. Especially when many other languages, including C and other
> scripting languages, rely on conventions (e.g. "A name that begins with
> an underscore is private.")
that would be a bad convention in C as it encroaches on the reserved namespace.
> On 2013-11-05 09:42, James Kanze wrote:
> > On Friday, 1 November 2013 13:41:14 UTC, Juha Nieminen wrote:
> >> http://warp.povusers.org/programming/cplusplus_superior_to_c.html
>
> > That's a good article, but it misses the most important point:
> > [..] in C++, you make the data private
>
> Information hiding is certainly a good thing, but I'm not sure if it's
> the most important advantage of C++ over C, though opinions may vary,
> of course. Especially when many other languages, including C and other
> scripting languages, rely on conventions (e.g. "A name that begins with
> an underscore is private.")
> and it doesn't seem like a major source of
> problems.
> Of course you can break it if you really intend to, but more
> or less the same thing can be said of C++ as well. And violations are
> easy to spot. On the other hand, things like RAII, exceptions, or
> generics are much harder to get right by hand.
Öö Tiib
Nov 8, 2013, 7:12:36 AM11/8/13
to
compilers have extensions that let one to RAII (like gcc).
Painful is it however in languages that massively use exceptions but do
not have RAII (like C# or Java).
James Kanze
Nov 8, 2013, 7:22:38 AM11/8/13
to
On Thursday, 7 November 2013 11:30:09 UTC, Juha Nieminen wrote:
> James Kanze <james...@gmail.com> wrote:
> > in C++, you make the data private, the functions members
> In C there's a kludge around that problem, and it's to use, basically,
> the Pimpl idiom using an opaque pointer.
I mentionned that later (in a parentheses).
> James Kanze <james...@gmail.com> wrote:
> > in C++, you make the data private, the functions members
> In C there's a kludge around that problem, and it's to use, basically,
> the Pimpl idiom using an opaque pointer.
> The two biggest problems with
> this are, of course, that the program becomes automatically more
> error-prone (because it becomes easier to make mistakes and have leaks,
> double frees, or accessing freed memory), and the program becomes less
> efficient because every instance of that struct needs to be allocated
> dynamically (which, as we know, is a really heavy operation.)
by using memory pools. The real issue is the programming one:
we all know how error prone manual memory management can be.
> Quite ironically, this makes the C implementation a lot less efficient
> than the proper C++ implementation. (It's ironic because many C advocates
> argue that C is faster and more efficient than C++.)
--
Scott Lurndal
Nov 8, 2013, 9:32:48 AM11/8/13
to
Paavo Helde <myfir...@osa.pri.ee> writes:
>dr...@furrfu.invalid (Drew Lawson) wrote in news:l5gvvj$11g7$1
>@raid.furrfu.com:
>dr...@furrfu.invalid (Drew Lawson) wrote in news:l5gvvj$11g7$1
>@raid.furrfu.com:
>What we are currently missing is a way to detect multithreading errors
>like data races and deadlocks and turn them into compile-time errors.
>Deadlocks could be for example avoided by enforcing a total consistent
>ordering of mutexes and encoding the level of locked mutexes somehow in
>the function interfaces. This would be extremely useful in some sort of
>programs, even more so than private/public as it is harder to get that
>right by hand.
Interesting idea. Here's how we did exactly that in the late 70's/early 80's
>like data races and deadlocks and turn them into compile-time errors.
>Deadlocks could be for example avoided by enforcing a total consistent
>ordering of mutexes and encoding the level of locked mutexes somehow in
>the function interfaces. This would be extremely useful in some sort of
>programs, even more so than private/public as it is harder to get that
>right by hand.
on one of Burroughs SMP mainframes (built right into the instruction set):
http://vseries.lurndal.org/doku.php?id=instructions:lok
Note particularly the "lock number" field in the 20-digit (10-byte)
lock structure.
The lock instructions provided a standard mutex. The event instructions
provided a standard condition variable.
Öö Tiib
Nov 8, 2013, 1:04:02 PM11/8/13
to
difficult is how to achieve such total order in dynamic world of modern software. Will there be several different mutexes of same level?
Scott Lurndal
Nov 8, 2013, 1:50:21 PM11/8/13
to
fix all the deadlock issues that were prevented by the processor throwing an
illegal instruction error (which would red-light (panic)) the MCP (Operating System).
However, once developed, we _never_ saw a deadlock report from the field regardless
of the processor count (the largest field systems could have four loosely-coupled
(shared peripherals (disk, magtape, card reader/punch, datacomm processor(s))) systems
each with four tightly-coupled (i.e. SMP) central processors (shared memory)). A
maxed-out system sold for several million dollars and required a large room (a
string of 16 300MB removable disk packs (memorex 677) required something like
14+ linear meters of floorspace including the controllers (one per host interface,
up to eight allowed) and exchanges (to multiplex the drives & controllers allowing
all controllers access to all 16 drives from up to four distinct hosts).
We did have simulators in the lab that supported up to 16 SMP processors that we
used to test scaling issues. These ran on a large B7900.
Yes, there can be several mutexes with the same level. The ordering was enforced
when the LOK instruction was executed and was enforced relative to an prior acquired
locks. Note that the "canonical lock number" was a four-digit BCD field, which allowed
9,999 distinct lock levels (the value zero marked a condition variable).
While we had intended to extend the hardware lock instruction into user-mode, that
feature in the processor had been defered to later releases since there was no ability
(i.e. operating system support) to create multithreaded COBOL applications in 1980. The
line of systems was discontinued in 1991 a few years after the merger with Sperry
Univac, but development of new features ended circa 1989 except for maintenance and
some new peripheral support.
Dombo
Nov 10, 2013, 9:23:47 AM11/10/13
to
Op 08-Nov-13 13:12, 嘱 Tiib schreef:
My experience is that the lack of RAII is not all that painful in these
languages. I don't think it makes sense to consider language features in
isolation. I've been programming C++ for 20 years now, and consider RAII
to be an essential part of the C++ language. Recently I've done a couple
of C# projects and I have a little experience with Java too. Java and C#
have language features, such as garbage collection and the finally
clause, that make the lack of support for RAII less painful and
occasionally these language features are actually more convenient than
RAII. In case of C# you have also the using/IDisposable construct, which
isn't as nice as RAII, but in many cases it is close enough.
Often I see people when confronted with a new programming language
insisting on using the idioms of the programming language they know/like
best. My experience is that that is a recipe for a lot of frustration
and eventually disaster. If you want to program like in Java then use
Java, if you want to program like in C++ then use C++. If you are
picking up a new programming language be sure you pick up also the
idioms that go with that language. If you are not willing to adapt your
programming style then stick to the language for which that style is
appropriate.
languages. I don't think it makes sense to consider language features in
isolation. I've been programming C++ for 20 years now, and consider RAII
to be an essential part of the C++ language. Recently I've done a couple
of C# projects and I have a little experience with Java too. Java and C#
have language features, such as garbage collection and the finally
clause, that make the lack of support for RAII less painful and
occasionally these language features are actually more convenient than
RAII. In case of C# you have also the using/IDisposable construct, which
isn't as nice as RAII, but in many cases it is close enough.
Often I see people when confronted with a new programming language
insisting on using the idioms of the programming language they know/like
best. My experience is that that is a recipe for a lot of frustration
and eventually disaster. If you want to program like in Java then use
Java, if you want to program like in C++ then use C++. If you are
picking up a new programming language be sure you pick up also the
idioms that go with that language. If you are not willing to adapt your
programming style then stick to the language for which that style is
appropriate.
Öö Tiib
Nov 10, 2013, 12:29:02 PM11/10/13
to
On Sunday, 10 November 2013 16:23:47 UTC+2, Dombo wrote:
> Op 08-Nov-13 13:12, Öö Tiib schreef:
more convenient to others.
> In case of C# you have also the using/IDisposable construct, which
> isn't as nice as RAII, but in many cases it is close enough.
Yes that was exactly what I said. The idioms that replace RAII (chains of catches everywhere, finalizers and disposers) are painful to use for
managing precious resources. The information that some object "manages"
precious resources leaks outside and so the object has to be "managed"
differently by using code. No true encapsulation possible. How to
OOP then?
> Op 08-Nov-13 13:12, Öö Tiib schreef:
> > On Friday, 8 November 2013 10:41:00 UTC+2, Ian Collins wrote:
> >> Drew Lawson wrote:
> >>> Pick a feature, almost any feature, of C++, and there are knowledgeable
> >>> posters who will claim that it is essential to the language and
> >>> other knowledgeable posters who will claim that it is an unimportant
> >>> curiosity.
> >>>
> >>> RAII is an "I have seen the light" religion for some and a really
> >>> cool convenience for others.
> >>
> >> It is also the only C++ feature that can't be replicated in C. So you
> >> could argue that RAII alone is enough of a reason to use C++ in place of C.
> >
> > C does not have exceptions so it is slightly less important. Also some C
> > compilers have extensions that let one to RAII (like gcc).
> >
> > Painful is it however in languages that massively use exceptions but do
> > not have RAII (like C# or Java).
>
> My experience is that the lack of RAII is not all that painful in these
> languages. I don't think it makes sense to consider language features in
> isolation. I've been programming C++ for 20 years now, and consider RAII
> to be an essential part of the C++ language. Recently I've done a couple
> of C# projects and I have a little experience with Java too. Java and C#
> have language features, such as garbage collection and the finally
> clause, that make the lack of support for RAII less painful and
> occasionally these language features are actually more convenient than
> RAII.
May be. More verbose code is inconvenient for me but it may be is somehow
> >> Drew Lawson wrote:
> >>> Pick a feature, almost any feature, of C++, and there are knowledgeable
> >>> posters who will claim that it is essential to the language and
> >>> other knowledgeable posters who will claim that it is an unimportant
> >>> curiosity.
> >>>
> >>> RAII is an "I have seen the light" religion for some and a really
> >>> cool convenience for others.
> >>
> >> It is also the only C++ feature that can't be replicated in C. So you
> >> could argue that RAII alone is enough of a reason to use C++ in place of C.
> >
> > C does not have exceptions so it is slightly less important. Also some C
> > compilers have extensions that let one to RAII (like gcc).
> >
> > Painful is it however in languages that massively use exceptions but do
> > not have RAII (like C# or Java).
>
> My experience is that the lack of RAII is not all that painful in these
> languages. I don't think it makes sense to consider language features in
> isolation. I've been programming C++ for 20 years now, and consider RAII
> to be an essential part of the C++ language. Recently I've done a couple
> of C# projects and I have a little experience with Java too. Java and C#
> have language features, such as garbage collection and the finally
> clause, that make the lack of support for RAII less painful and
> occasionally these language features are actually more convenient than
> RAII.
more convenient to others.
> In case of C# you have also the using/IDisposable construct, which
> isn't as nice as RAII, but in many cases it is close enough.
managing precious resources. The information that some object "manages"
precious resources leaks outside and so the object has to be "managed"
differently by using code. No true encapsulation possible. How to
OOP then?
Richard Damon
Nov 10, 2013, 2:09:26 PM11/10/13
to
without the ability to tell the compiler to automatically call an
objects destructor, I wouldn't call listing a requirement that the
object needs its "close" function called before the object goes away an
encapsulation "leakage", it is just part of the objects interface. It
does say that when designing said interface, the designer needs to think
if there is now, or in some point in the future a possible need for such
an routine, and if so provide it and "require" its call. If anything, it
is the objects that do NOT require a "close" call that have leaked
implementation details, as if the future that changes, you need to
review all usage of that class.
Yes, the automatic calling of the "close" function simplify a lot of
code, but some of the critics of C++ also point out that this
automatisity is also a big problem as it can hide significant amounts of
operations.
Paavo Helde
Nov 10, 2013, 2:34:59 PM11/10/13
to
嘱 Tiib <oot...@hot.ee> wrote in
news:d5b5499b-4702-4928...@googlegroups.com:
I have implemented a similar system in our (largish) C++ software,
working only in Debug or test mode (for performance reasons, but also
because there is a large chance it would detect false positives in the
field and we are not sure what to do with them).
Yes, there are lots of mutexes on the same level. Whenever the program
attempts to lock a mutex on a less or equal level, this is a potential
deadlock scenario which has to get fixed. Setting up such a system is a
lot of work and the yield is seems pretty low, about 90% of times when
the alert triggers, it appears this is a false positive (meaning the lock
levels were assigned incorrectly and need readjusting). Maybe next time
it would work better, with more experience.
The drawback of this system is that this is a runtime system and can only
detect deadlock scenarios which are actually run through in tests. What I
imagined in my previous post was to achieve the same at the compile time.
Cheers
Paavo
news:d5b5499b-4702-4928...@googlegroups.com:
working only in Debug or test mode (for performance reasons, but also
because there is a large chance it would detect false positives in the
field and we are not sure what to do with them).
Yes, there are lots of mutexes on the same level. Whenever the program
attempts to lock a mutex on a less or equal level, this is a potential
deadlock scenario which has to get fixed. Setting up such a system is a
lot of work and the yield is seems pretty low, about 90% of times when
the alert triggers, it appears this is a false positive (meaning the lock
levels were assigned incorrectly and need readjusting). Maybe next time
it would work better, with more experience.
The drawback of this system is that this is a runtime system and can only
detect deadlock scenarios which are actually run through in tests. What I
imagined in my previous post was to achieve the same at the compile time.
Cheers
Paavo
Öö Tiib
Nov 10, 2013, 5:51:50 PM11/10/13
to
On Sunday, 10 November 2013 21:09:26 UTC+2, Richard Damon wrote:
close" kind.
> It
> does say that when designing said interface, the designer needs to think
> if there is now, or in some point in the future a possible need for such
> an routine, and if so provide it and "require" its call.
Yes. May be we need to manage a member that manages a member that may be
has a file open or network connection or something like that? Everything
"may happen" (perhaps besides bare bone strings and numbers) and so
everything may need manual life-time management. Dealt with it once and
the RAII of C++ feels suddenly so sweet a feature. ;)
> If anything, it
> is the objects that do NOT require a "close" call that have leaked
> implementation details, as if the future that changes, you need to
> review all usage of that class.
Ok but with mandatory manual life time management of most things
... what is the major benefit above idiomatic OOP of C?:
#include <Thing.h>
int main()
{
Thing* thing = Thing_open(42);
if (thing == NULL)
perror("Error opening Thing");
else
{
Thing_trick1(thing);
Thing_trick2(thing);
Thing_close(thing);
}
return 0;
establish some borderline. If a class does travel to Moon and back to
fulfill some responsibility of it despite it does not have to then it
is crappy implementation. If it is clear that it has to travel to Moon
and back however then more verbose interface does not aid us any.
We need that done and so someone has to visit Moon.
> On 11/10/13, 12:29 PM, Öö Tiib wrote:
> > On Sunday, 10 November 2013 16:23:47 UTC+2, Dombo wrote:
> >
> >> In case of C# you have also the using/IDisposable construct, which
> >> isn't as nice as RAII, but in many cases it is close enough.
> >
> > Yes that was exactly what I said. The idioms that replace RAII (chains
> > of catches everywhere, finalizers and disposers) are painful to use for
> > managing precious resources. The information that some object "manages"
> > precious resources leaks outside and so the object has to be "managed"
> > differently by using code. No true encapsulation possible. How to
> > OOP then?
> >
>
> I an nor so sure I would call that an information "leak", in a language
> without the ability to tell the compiler to automatically call an
> objects destructor, I wouldn't call listing a requirement that the
> object needs its "close" function called before the object goes away an
> encapsulation "leakage", it is just part of the objects interface.
I was more about leaking that "interfacial property" up the whole cascade. Usage of such class as member turns usually the composite also into "must
> > On Sunday, 10 November 2013 16:23:47 UTC+2, Dombo wrote:
> >
> >> In case of C# you have also the using/IDisposable construct, which
> >> isn't as nice as RAII, but in many cases it is close enough.
> >
> > Yes that was exactly what I said. The idioms that replace RAII (chains
> > of catches everywhere, finalizers and disposers) are painful to use for
> > managing precious resources. The information that some object "manages"
> > precious resources leaks outside and so the object has to be "managed"
> > differently by using code. No true encapsulation possible. How to
> > OOP then?
> >
>
> I an nor so sure I would call that an information "leak", in a language
> without the ability to tell the compiler to automatically call an
> objects destructor, I wouldn't call listing a requirement that the
> object needs its "close" function called before the object goes away an
> encapsulation "leakage", it is just part of the objects interface.
close" kind.
> It
> does say that when designing said interface, the designer needs to think
> if there is now, or in some point in the future a possible need for such
> an routine, and if so provide it and "require" its call.
has a file open or network connection or something like that? Everything
"may happen" (perhaps besides bare bone strings and numbers) and so
everything may need manual life-time management. Dealt with it once and
the RAII of C++ feels suddenly so sweet a feature. ;)
> If anything, it
> is the objects that do NOT require a "close" call that have leaked
> implementation details, as if the future that changes, you need to
> review all usage of that class.
... what is the major benefit above idiomatic OOP of C?:
#include <Thing.h>
int main()
{
Thing* thing = Thing_open(42);
if (thing == NULL)
perror("Error opening Thing");
else
{
Thing_trick1(thing);
Thing_trick2(thing);
Thing_close(thing);
}
return 0;
}
> Yes, the automatic calling of the "close" function simplify a lot of
> code, but some of the critics of C++ also point out that this
> automatisity is also a big problem as it can hide significant amounts
> of operations.
I just do not buy that argument. The idea of encapsulation is to
> Yes, the automatic calling of the "close" function simplify a lot of
> code, but some of the critics of C++ also point out that this
> automatisity is also a big problem as it can hide significant amounts
> of operations.
establish some borderline. If a class does travel to Moon and back to
fulfill some responsibility of it despite it does not have to then it
is crappy implementation. If it is clear that it has to travel to Moon
and back however then more verbose interface does not aid us any.
We need that done and so someone has to visit Moon.
Ian Collins
Nov 10, 2013, 6:00:54 PM11/10/13
to
Richard Damon wrote:
> On 11/10/13, 12:29 PM, 嘱 Tiib wrote:
>> On Sunday, 10 November 2013 16:23:47 UTC+2, Dombo wrote:
>>
>>> In case of C# you have also the using/IDisposable construct, which
>>> isn't as nice as RAII, but in many cases it is close enough.
>>
>> Yes that was exactly what I said. The idioms that replace RAII (chains of catches everywhere, finalizers and disposers) are painful to use for
>> managing precious resources. The information that some object "manages"
>> precious resources leaks outside and so the object has to be "managed"
>> differently by using code. No true encapsulation possible. How to
>> OOP then?
>>
>
> I an nor so sure I would call that an information "leak", in a language
> without the ability to tell the compiler to automatically call an
> objects destructor, I wouldn't call listing a requirement that the
> object needs its "close" function called before the object goes away an
> encapsulation "leakage", it is just part of the objects interface. It
> does say that when designing said interface, the designer needs to think
> if there is now, or in some point in the future a possible need for such
> an routine, and if so provide it and "require" its call.
So the design of the interface forces the responsibility for cleaning up
> On 11/10/13, 12:29 PM, 嘱 Tiib wrote:
>> On Sunday, 10 November 2013 16:23:47 UTC+2, Dombo wrote:
>>
>>> In case of C# you have also the using/IDisposable construct, which
>>> isn't as nice as RAII, but in many cases it is close enough.
>>
>> Yes that was exactly what I said. The idioms that replace RAII (chains of catches everywhere, finalizers and disposers) are painful to use for
>> managing precious resources. The information that some object "manages"
>> precious resources leaks outside and so the object has to be "managed"
>> differently by using code. No true encapsulation possible. How to
>> OOP then?
>>
>
> I an nor so sure I would call that an information "leak", in a language
> without the ability to tell the compiler to automatically call an
> objects destructor, I wouldn't call listing a requirement that the
> object needs its "close" function called before the object goes away an
> encapsulation "leakage", it is just part of the objects interface. It
> does say that when designing said interface, the designer needs to think
> if there is now, or in some point in the future a possible need for such
> an routine, and if so provide it and "require" its call.
the object onto the consumer. This is no different from C or using raw
resources.
> If anything, it
> is the objects that do NOT require a "close" call that have leaked
> implementation details, as if the future that changes, you need to
> review all usage of that class.
using RAII, only the owning object has to be updated.
> Yes, the automatic calling of the "close" function simplify a lot of
> code, but some of the critics of C++ also point out that this
> automatisity is also a big problem as it can hide significant amounts of
> operations.
--
Ian Collins
Jorgen Grahn
Nov 10, 2013, 6:15:28 PM11/10/13
to
believe they have total control over the generated machine code (and
that C++ wants to rob them of it), but here we're comparing C++ with
languages like Java and Python, not C.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Öö Tiib
Nov 10, 2013, 6:48:36 PM11/10/13
to
On Sunday, 10 November 2013 21:34:59 UTC+2, Paavo Helde wrote:
> Öö Tiib <oot...@hot.ee> wrote in
OK. That was what I suspected. There will be lot of (likely false)
alarms initially. False alarms are silenced by adjusting mutex levels.
When someone maintains something then that may cause again alarms (mostly
false positives) again some work, etc. At end it will work brilliantly
however. Deadlock never happens, add as lot of threads, peripherals
and what you need.
> Yes, there are lots of mutexes on the same level. Whenever the program
> attempts to lock a mutex on a less or equal level, this is a potential
> deadlock scenario which has to get fixed. Setting up such a system is a
> lot of work and the yield is seems pretty low, about 90% of times when
> the alert triggers, it appears this is a false positive (meaning the lock
> levels were assigned incorrectly and need readjusting). Maybe next time
> it would work better, with more experience.
Yes, it is worth trying I trust. Some clever pattern (how to set it all
up with less work) may enter the world in that process and turn the
multi-threading into simple and clear. :)
> The drawback of this system is that this is a runtime system and can only
> detect deadlock scenarios which are actually run through in tests. What I
> imagined in my previous post was to achieve the same at the compile time.
That involves some magic algorithm of automatic discovering of the "levels"
of mutexes that feels to be missing at the moment.
> Öö Tiib <oot...@hot.ee> wrote in
alarms initially. False alarms are silenced by adjusting mutex levels.
When someone maintains something then that may cause again alarms (mostly
false positives) again some work, etc. At end it will work brilliantly
however. Deadlock never happens, add as lot of threads, peripherals
and what you need.
> Yes, there are lots of mutexes on the same level. Whenever the program
> attempts to lock a mutex on a less or equal level, this is a potential
> deadlock scenario which has to get fixed. Setting up such a system is a
> lot of work and the yield is seems pretty low, about 90% of times when
> the alert triggers, it appears this is a false positive (meaning the lock
> levels were assigned incorrectly and need readjusting). Maybe next time
> it would work better, with more experience.
up with less work) may enter the world in that process and turn the
multi-threading into simple and clear. :)
> The drawback of this system is that this is a runtime system and can only
> detect deadlock scenarios which are actually run through in tests. What I
> imagined in my previous post was to achieve the same at the compile time.
of mutexes that feels to be missing at the moment.
Paavo Helde
Nov 11, 2013, 2:45:04 AM11/11/13
to
嘱 Tiib <oot...@hot.ee> wrote in
news:6094e90d-45bd-4304...@googlegroups.com:
> OK. That was what I suspected. There will be lot of (likely false)
> alarms initially. False alarms are silenced by adjusting mutex levels.
> When someone maintains something then that may cause again alarms
> (mostly false positives) again some work, etc. At end it will work
> brilliantly however. Deadlock never happens, add as lot of threads,
> peripherals and what you need.
worst kind of bug what one might have.
Intel threading diagnostic tools do something similar, they attempt to
detect what are the mutexes and locks in the binary code, then remember
the relative order of locking of each mutex, so they can alert about a
potential deadlock if the same two mutexes are locked in the reverse
order later during the program run. Their tool also detects data races.
However, this is again pure run-time testing, and one has to make sure
the tool actually recognizes the mutexes and locks your program is
utilizing (at one point, their tool did not support boost::mutex).
>
>> imagined in my previous post was to achieve the same at the compile
>> time.
>
> That involves some magic algorithm of automatic discovering of the
> "levels" of mutexes that feels to be missing at the moment.
private/public/friend keywords. However, any compile-time schema I can
think of is too rigid and would require fully static level assignments,
whereas in real programs different objects of the same class might have
different levels, depending on their place in some hierarchical data
structure.
Cheers
Paavo
Juha Nieminen
Nov 11, 2013, 8:39:22 AM11/11/13
to
Scott Lurndal <sc...@slp53.sl.home> wrote:
> In over 30 years of C and C++ programming, both bare-metal and large application,
> I've not found the speed of allocation, when properly designed and utilized,
> to be a significant issue.
In the vast majority of cases it doesn't matter if you allocate objects
> In over 30 years of C and C++ programming, both bare-metal and large application,
> I've not found the speed of allocation, when properly designed and utilized,
> to be a significant issue.
dynamically. Thinks like std::set are useful in most situations regardless
of the slowness of dynamic memory allocation (because in the vast majority
of cases searching is done a lot more than adding elements.)
However, as an experienced C++ programmer one should be aware of how
inefficient dynamic allocation is, and avoid it in situations where it
may cause a problem, especially if there's an easy alternative. For
example, allocating an object dynamically in a tight inner loop of an
algorithm that needs to be as fast as possible (and which may get run
millions of times) is madness, especially if there's really no need to
allocate it dynamically. The difference in speed will probably be one
or two orders of magnitude.
Also, if you can use an array or vector to handle objects by value,
that's always preferable to allocating individual objects separately,
unless there's a good reason to do the latter. (As an extreme example,
if you were handling eg. image data, and you have a class that represents
one pixel, it would be madness to allocate each pixel object individually
instead of using a vector of them.)
Juha Nieminen
Nov 11, 2013, 8:45:13 AM11/11/13
to
Drew Lawson <dr...@furrfu.invalid> wrote:
> RAII is an "I have seen the light" religion for some and a really
> cool convenience for others.
Note that this thread is mainly comparing C to C++. C does not offer
> RAII is an "I have seen the light" religion for some and a really
> cool convenience for others.
any alternative to RAII (like many other programming languages do.)
An argument could be made whether RAII-style or eg. Java-style GC is
better, but I don't think that's the issue being discussed.
> Templates are either not very important,
> or they are the only essential language contribution.
In my experience templates are much more useful and important than eg.
dynamic binding. (Not that the language wouldn't get a lot worse if
dynamic binding were removed, but if I were to compare the two, then
templates are in practice much more useful.)
Juha Nieminen
Nov 11, 2013, 8:46:44 AM11/11/13
to
I have to strongly disagree with that.
Juha Nieminen
Nov 11, 2013, 8:52:35 AM11/11/13
to
Dombo <do...@disposable.invalid> wrote:
> My experience is that the lack of RAII is not all that painful in these
> languages.
It might not be painful per se, but the lack can certainly be felt in
> My experience is that the lack of RAII is not all that painful in these
> languages.
some cases. It's the very reason for the existence of 'using' blocks
in C#, for instance (which is basically a limited form of RAII.)
0 new messages