soft and program: comp.lang.c++ - 25 new messages in 11 topics

comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en

comp.lang.c++@googlegroups.com

Today's topics:

* Clojure vs Java speed - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/40783f7f814400c9?hl=en
* New release of the Dynace OO extension to C - 13 messages, 6 authors
http://groups.google.com/group/comp.lang.c++/t/ee8689156295093c?hl=en
* Can iterator be checked to be at end of vector? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/04f21bec592f548d?hl=en
* How can I use unqualified names? (Possibly hard or impossible?) - 1 messages,
1 author
http://groups.google.com/group/comp.lang.c++/t/e2f24a95fe72b591?hl=en
* ◎♥◎wholesale Iphone,Nokia,Samsung,Blackberry,etc brand mobile phones, TV
mobiles,Music Mobiles, Touch Mobiles, Dual sim card dual standby Chinese
mobile phones◎♥◎ www.toptradea.com◎♥◎ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/0607e55d23b660fb?hl=en
* Printing the last item of a structure twice - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/9fd75392aae26667?hl=en
* Difference between Windows and Linux GCC compiler - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/f432fafbea7d806a?hl=en
* ♥◎♥Hot sale Iphone 3G 16gb&8gb,Iphone3Gs,M89,M88,T32,G1,G2,TV Brand new,
unlocked,with all accessories Our policy: order 1-3pce brand mobile with a
free polo Tshirt, order more than 5 pcs brand mobiles with a free nike sneaker
(time limited) ♥ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/4ed425c1569ecfd7?hl=en
* 〓〈◆〉〓Air Jordan,Nike,Air Max,Shox,Rift,Max 2009, Jordan 2009 Wholesale
and retail, paypal payment! Welcome to www.toptradea.com - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/b9a2374df0538504?hl=en
* ♂◆♀♥Handbags supplier 田www.toptradea.com田 Lady Handbags Juicy,Gucci,LV,
Prada,D&G,Edhardy,Chanel,Coach, Jimmy-Hoo,Burberry,DB ┈━═☆ - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/34eb1c4b019ed9b6?hl=en
* dealing with lower level programmers - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/f708a2c0cfa8ce2d?hl=en

==============================================================================
TOPIC: Clojure vs Java speed
http://groups.google.com/group/comp.lang.c++/t/40783f7f814400c9?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jul 30 2009 5:48 pm
From: Oxide Scrubber

Jon Harrop wrote:
> fft1976 wrote:
>> On Jul 29, 12:24 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
>>>> This is fanboy fantasy, not reality.
>>> Yes. Clojure has some nice features but its most serious deficiencies are
>>> inherited from the JVM and there is nothing Clojure can do about it, e.g.
>>> value types and TCO.
>> Not as far as speed is concerned, in practice. If you give up 1.5x
>> speed by going from C++ to Java, and 5-10 by going from Java to
>> Clojure [1], than the latter is much more relevant.
>
> Lack of value types can cost you a lot more than 1.5x though. Try writing an
> FFT over boxed complexes and Java and compare with unboxed in C99, for
> example.

Clojure has TCO; you just have to make your use of it explicit (and then
the compiler alerts you if it's not really in tail position).

I'm not sure what you mean by "value types". If you mean immutable types
with value-equality semantics remaining consistent over time, then
Clojure is chock full of them, even its collection types can be used as
value types, so as keys in maps for instance.

If you mean non-pointer types, Clojure has access to the full range of
Java non-pointer types: boolean, byte, short, int, long, float, double,
and char.

It can't currently pass them across function call boundaries without
boxing and unboxing, but you can work around that using definline or a
macro.

> This goes way beyond number crunching though. Lots of applications benefit
> enormously from value types. They are used extensively in the .NET
> framework.

The JVM has several non-pointer types too, and does not have the
Microsoft taint.

==============================================================================
TOPIC: New release of the Dynace OO extension to C
http://groups.google.com/group/comp.lang.c++/t/ee8689156295093c?hl=en
==============================================================================

== 1 of 13 ==
Date: Thurs, Jul 30 2009 5:49 pm
From: "BGB / cr88192"

"Squeamizh" <squeamz@hotmail.com> wrote in message
news:d57ba96b-2aa0-474a-95c4-0970f188a972@f20g2000prn.googlegroups.com...
On Jul 30, 3:40 pm, "BGB / cr88192" <cr88...@hotmail.com> wrote:
> to clarify:
> int foo()
> {
> int i, j, k;
> ...
> for(i=0; i<10; i++)
> ...
>
> }
>
> this is OK, no problems...
>
> now as for:
> int foo()
> {
> ...
> for(int i=0; i<10; i++)
> {
> int j, k;
> ...
> }
> ...
>
> }
>
> only valid for C++ and for C99 and newer, and supported as a language
> extension to many C compilers, but not technically not legal in C89.

<--
The fastest way to get to the bottom of this is to ask you a direct
question. Is your claim that the following code is not permissible in
C89:

int foo(void)
{
int i;
for(i=0; i<10; i++)
{
int j;

j = i;
}
}

...yes or no?

-->

no, AFAIK this is not allowed in C89...

C99 allows it though, as well as does C++...

GCC will accept it, but I have not tried it with MSVC...
ok, seems MSVC accepts it...

so, it is like '//', namely in that it works damn near everywhere, and has
for a very long time, but was not made "official" until fairly recently (or,
at least, 1999, as opposed to 1989/1990...).

then again, I guess using it or not using it anymore is mostly a matter of
style...

(declarations go at top of function, and the variables i, j, and k are
'int', s is 'char *', ...).

or such...

== 2 of 13 ==
Date: Thurs, Jul 30 2009 5:53 pm
From: Keith Thompson

"BGB / cr88192" <cr88192@hotmail.com> writes:
[...]
> to clarify:
> int foo()
> {
> int i, j, k;
> ...
> for(i=0; i<10; i++)
> ...
> }
>
> this is OK, no problems...
>
> now as for:
> int foo()
> {
> ...
> for(int i=0; i<10; i++)
> {
> int j, k;
> ...
> }
> ...
> }
>
> only valid for C++ and for C99 and newer, and supported as a language
> extension to many C compilers, but not technically not legal in C89.
>
> this would seem to be what the prior person was debating...

I doubt it. The ability to have a declaration in the header of
a for loop, the ability to have declarations in a nested block,
and the ability to mix declarations and statement within a block,
are three almost entirely different features. Note that the first
applies only to for loops, not to blocks in general. I don't recall
anyone in this thread specifically mentioning for loops.

> my use of "block" then, meant "internal blocks" or similar, not the function
> as a whole...

Right, and C has *always* supported the ability to have declaratins in
nested blocks. It's the ability to mix declarations and statements
that's new in C99 (and in C++).

For example, the following program

#include <stdio.h>
int main(void)
{
puts("Before block, x doesn't exist yet");
{
int x = 42;
printf("In block, x = %d\n", x);
}
puts("After block, x no longer exists");
return 0;
}

is perfectly valid in both C89 and C99. Change "int main(void)" to
"int main()", and it's valid in (pre-ANSI) K&R C as well. (Similarly
minor tweaks would make it valid C++.)

If you want to argue that it's poor style, I won't share your opinion,
but I won't say you're factually wrong.

> FWIW, not all C compilers conform with C99...

I'm very well aware of that; in fact, only a few do so.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

== 3 of 13 ==
Date: Thurs, Jul 30 2009 6:21 pm
From: "BGB / cr88192"

"Jerry Coffin" <jerryvcoffin@yahoo.com> wrote in message
news:MPG.24dbe07c70205633989717@news.sunsite.dk...
> In article <h4t0kr$iul$1@news.albasani.net>, cr88192@hotmail.com
> says...
>
> [ ... ]
>
>> simple solution:
>> don't design API's this way...
>>
>> each side of the API manages its own memory, and no memory or resource
>> ownership should be passed across this border.
>
> The API in question was one for allocating memory. The rest of your
> comments simply don't apply for such a thing.
>

using 'malloc' in the first place is its own set of issues...

as such, the general rule of thumb:
avoid (directly) using malloc...

it is possible to do so...

> [ ... ]
>
>> the usual alternatives:
>> know what you are doing;
>> don't pass around resource ownership all over the place (there ARE ways
>> to
>> move data from place to place, without directly transporting resource
>> ownership);
>> ...
>>
>> virtualize the resources, and virtualize their access and transport, and
>> many of these management issues either lessen or go away.
>
> That certainly sounds good -- at least in a world where hand-waving
> generalizations cure real problems.
>

virtualizing things is a real, and workable, practice...

granted, garbage collection, and "allocate then bulk free", are typically
more convinient practices.

alloc then bulk free is a simple strategy:
any objects allocated are, firstly, done in a specialized heap;
allocations are kept track of;
when done, destroy any objects within this heap.

ownership does not transfer from this heap.
typically, when exiting the region of code for which this heap was created,
the whole thing is torn down...

Quake is a well known app which used a variation of this strategy (not true
of Doom 1/2 though, which used a different strategy, AKA, a custom allocator
they called Z_Malloc(), which had its role changed in Quake...).

> [ ... ]
>
>> > 1) Decades of experience has shown that while it's
>> > _theoretically_ possible to get it right in C, that in the entire
>> > history of C, there's probably never been even one nontrivial
>> > program that didn't have at least one memory management problem.
>> > For any practical purpose, that qualifies as "impossible".
>> >
>>
>> by extension, this would be the case of C++ as well...
>
> Not true, for the simple reason that the basis isn't true in C++.
> Quite a bit of software developed in C++ doesn't appear to have any
> memory management problems at all.
>

but, as stated, this would contridict the logic in play:
a C++ app necessarily contains dependencies on C code (in the form of
runtime libraries, the OS, ...).

for your claims to be correct, either:
a C++ app would have to contain leaks, due to the C code;
it is possible that C code does not contain leaks.

either way, the argument doesn't hold...

>> after all, Java was written in part with the intent to address these
>> sorts
>> of problems, in C++...
>
> Certainly Sun has claimed they designed Java to cure problems in C++.
> A large number of the problems they cited, however, are either
> obviously imaginary, or not cured by Java at all. Somebody with a
> vested interest in one product saying less than complimentary things
> about a (perceived) competitor hardly qualifies as proof of anything.
>

now, you see the irony here?...

>> > 2) The improvement is hardly "incremental" -- in typical cases, it's
>> > a lot _more_ than one order of magnitude improvement.
>> >
>>
>> as you claim...
>> this claim, however, is not substantiated with any more than straw-men...
>
> Rather the contrary -- it's substantiated with a couple of decades of
> writing code myself, and looking at code other people have written.
>

but, yet, you write your code in C++, hmm...

>> just because you can accuse people of using generally horrid coding
>> practices, does not mean they actually do so by definition.
>
> Oh calm down and try to deal with reality!
>
> 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.
>

you don't particularly have to use them in the first place...

it is convinient to use them in some cases, but other options exist:
use a garbage collector, which typically gets memory from mmap or
VirtualAlloc;
write your own MM or GC, and use mmap or VirtualAlloc...

granted, one "can" leak with mmap or VA, but typically it is a very
different sort of leak (assuming the GC works correctly, it takes the form
of not releasing the space when the process exits, which is typically
handled by the OS).

once an app gets beyond a trivial scale, it is typical to largely forsake
malloc.
now, this does leave "other" resources, but luckily these tend to be much
easier to localize and isolate.

>> "well, you use C++, that means by default you like making hugely
>> tangled class heirarchies and #includ'ing your entire source tree
>> into a single file...", "don't deny it, we KNOW this is how people
>> write C++...", "that and with all the operator overloading on damn
>> near every class, and use of recursive templates...", ...
>>
>> see the point?...
>
> If "the point" is that you realize you've lost the argument based on
> facts, and prefer to spout nonsense rather than admit you're wrong,
> then yes. If there was supposed to be another point, you've failed to
> make it.
>

who is pointing fingers here?...

firstly, what am I claiming?...
I am not claiming C is as convinient to use as C++, or that it provides all
the same niceties.
I am saying here, a person can use it, AND know what they are doing...

>> > 3) The number of scenarios where it provides a nontrivial improvement
>> > is extremely large -- I'd say well over 90% of all typical code can
>> > use RAII to manage the lifetime of most objects.
>> >
>>
>> but, is this actually necessary?...
>> or is it, rather, the case that one CAN get by without using it?...
>
> In theory, you can also get by on simply being the world's greatest
> genius, and always doing things perfectly with no help from the
> language at all.
>
> In reality, experience has shown that that approach just doesn't
> work.
>

so says you...

one does not have to be a "genius", rather, there is a very different
strategy:
anality...

if one has rules which, if followed, will eliminate a problem, and they
follow them without fail, then the problem largely goes away...

it is much like how people can avoid the problems associated with
promiscuous behavior through a simple and effective stategy: abstinence...

abstinence works, for those who care to use it...

> [ ... ]
>
>> partial reason:
>> because, at its core, C++ is based on C, and, essentially, manages the
>> resources in the same basic ways, and with the same basic issues.
>
> I've already pointed out that this is just plain wrong. Repeating
> your falsehood is NOT going to make it true.
>
> [ ... ]
>
>> a task which can be done in one can, thus, be done in the other,
>> typically with only a modest difference in overall code size.
>
> Oh what a load of horse hockey! Let's look at a truly trivial
> example:
>
> #include <string>
> #include <set>
> #include <algorithm>
> #include <iterator>
> #include <iostream>
>
> int main() {
> std::string line;
> std::set<std::string> lines;
>
> while (std::getline(std::cin, line))
> lines.insert(line);
> std::copy(lines.begin(), lines.end(),
> std::ostream_iterator<std::string>(std::cout, "\n"));
> return 0;
> }
>
> The problem statement is pretty simple: you need to read lines from
> standard input, and then write the unique lines in sorted order to
> standard output. The maximum line length and maximum number of lines
> should be limited only by available memory.
>
> Now, as shown above in C++, even if we include blank lines,
> #include's, and so on, it's trivial to do that in less than 20 lines.
>
> C just doesn't provide the tools to make this trivial at all. For
> example, here's code just to read in a string of arbitrary size:
>
> char *getstring(void) {
> int ch;
> size_t i;
> static size_t bufsize = 0;
> static char *buffer = NULL;
>
> for (i = 0;((ch=getchar())!= EOF) && (ch!='\n')&&(ch!='\r'); ++i)
> {
> if (i + 1 > bufsize)
> {
> /* If buffer is full, resize it. */
> char *temp = realloc(buffer, bufsize+BLOCKSIZ);
> if (NULL==temp) {
> puts("\agetstrng() - Insufficient memory");
> /* Add terminator to partial string */
> buffer[i] = '\0';
> return buffer;
> }
> buffer = temp;
> bufsize += BLOCKSIZ;
> }
> buffer[i] = (char)ch;
> }
> buffer[i] = '\0'; /* Tack on a null-terminator. */
> return buffer;
> }
>
> All by itself, this is larger and more complex than the complete
> program in C++. Then we need to write another very similar routine to
> manage a dynamic array to hold the lines we read. Alternatively, we
> could do like the C++ code does, and use a balanced tree of some sort
> (R-B tree, AVL tree, etc.), but that's going to expand the code a LOT
> more -- plan on around 100 lines of fairly tricky code just to do an
> insertion in a balanced tree. As yet another alternative, you could
> use a tree that doesn't attempt to keep itself balanced -- this will
> keep the code a lot simpler at the expense of worst case performance
> being roughly O(n*n) instead of O(n*log(n)).
>

if you don't know how to use C in the first place, it will bite you...

the bite goes away IF someone knows what they are doing...

once again, it comes down to a matter of badly written and badly designed
code.

>> the actual differences then, are not significant, rather, they are
>> modest...
>
> See the example above -- the difference qualifies as at least
> significant, and probably closer to "dramatic". Looked at from
> another perspective, it's simply average -- about what we can expect
> to see in a typical case.
>

straw men don't make your "facts" real either...

<snip>

not going to bother with the rest...

== 4 of 13 ==
Date: Thurs, Jul 30 2009 6:28 pm
From: "BGB / cr88192"

"Jerry Coffin" <jerryvcoffin@yahoo.com> wrote in message
news:MPG.24dbea4f260cff2198971a@news.sunsite.dk...
> In article <h4tcbv$apv$1@aioe.org>, jacob@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...

but, as noted, the usual strategy for file handles and GUI stuff is to
isolate it...

this means typically a setup/teardown process is used (for example, for the
main GUI, ...).
files are usually isolated, such that file handles are not kept open for
extended lengths of time, or if they need to be, a similar setup/teardown
approach is used...

> --
> Later,
> Jerry.

== 5 of 13 ==
Date: Thurs, Jul 30 2009 6:31 pm
From: Jerry Coffin

In article <h4tgv6$b59$1@news.albasani.net>, cr88192@hotmail.com
says...

[ ... ]

> a C++ app necessarily contains dependencies on C code (in the form
> of runtime libraries, the OS, ...).

So you're claiming that all C++ code uses parts of the standard
library that use dynamic memory written in C? You're also claiming
that ever OS is written in C?

If you honestly believe either, further discussion is clearly
pointless, since your idea of "reality" differs too radically from
mine to give sufficient common ground for meaningful communication.

--
Later,
Jerry.

== 6 of 13 ==
Date: Thurs, Jul 30 2009 6:54 pm
From: Keith Thompson

"BGB / cr88192" <cr88192@hotmail.com> writes:
> "Squeamizh" <squeamz@hotmail.com> wrote in message
> news:d57ba96b-2aa0-474a-95c4-0970f188a972@f20g2000prn.googlegroups.com...
[...]
> <--
> The fastest way to get to the bottom of this is to ask you a direct
> question. Is your claim that the following code is not permissible in
> C89:
>
> int foo(void)
> {
> int i;
> for(i=0; i<10; i++)
> {
> int j;
>
> j = i;
> }
> }
>
> ...yes or no?
>
> -->
>
> no, AFAIK this is not allowed in C89...
>
> C99 allows it though, as well as does C++...
>
> GCC will accept it, but I have not tried it with MSVC...
> ok, seems MSVC accepts it...

Once again, I'm afraid you are simply wrong.

The above code is valid in both C89 and C90.

Quoting from the ISO C90 standard:

6.6 Statements:

statement:
labeled-statement
compound-statement
expression-statement
selection-statement
iteration-statement
jump-statement

6.6.2 Compound statement, or block:

compound-statement:
{ declaration-list(opt) statement-list(opt) }

declaration-list:
declaration
declaration-list declaration

statement-list:
statement
statement-list statement

Semantics

A compound statement (also called a block) allows a set of
statements to be grouped into one syntactic unit, which may have
its own set of declarations and initializations (as discussed in
6.1.2.4).

The C Reference manual in K&R1 (1978), section 9.2, has a very similar
description; I'm not going to take the time to type it in.

Both K&R1 and K&R2 have this example:

if (n > 0) {
int i; /* declare a new i */
for (i = 0; i < n; i ++)
...
}

> so, it is like '//', namely in that it works damn near everywhere, and has
> for a very long time, but was not made "official" until fairly recently (or,
> at least, 1999, as opposed to 1989/1990...).

One more time, the ability to have declarations within blocks goes
back to K&R1 and earlier. The ability to *mix* declarations and
statements within blocks does not exist in C90; it's new in C99 and
C++.

[snip]

== 7 of 13 ==
Date: Thurs, Jul 30 2009 7:00 pm
From: "BGB / cr88192"

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnd47hwrap.fsf@nuthaus.mib.org...
> "BGB / cr88192" <cr88192@hotmail.com> writes:
>> "Squeamizh" <squeamz@hotmail.com> wrote in message
>> news:d57ba96b-2aa0-474a-95c4-0970f188a972@f20g2000prn.googlegroups.com...
> [...]

<snip>

>
> Semantics
>
> A compound statement (also called a block) allows a set of
> statements to be grouped into one syntactic unit, which may have
> its own set of declarations and initializations (as discussed in
> 6.1.2.4).
>
> The C Reference manual in K&R1 (1978), section 9.2, has a very similar
> description; I'm not going to take the time to type it in.
>
> Both K&R1 and K&R2 have this example:
>
> if (n > 0) {
> int i; /* declare a new i */
> for (i = 0; i < n; i ++)
> ...
> }
>
>> so, it is like '//', namely in that it works damn near everywhere, and
>> has
>> for a very long time, but was not made "official" until fairly recently
>> (or,
>> at least, 1999, as opposed to 1989/1990...).
>
> One more time, the ability to have declarations within blocks goes
> back to K&R1 and earlier. The ability to *mix* declarations and
> statements within blocks does not exist in C90; it's new in C99 and
> C++.
>

oh, ok...

well, it is worth noting that I don't remember if I could ever find the C89
spec to look at (I might have, I don't remember). so, I hadn't realized this
was allowed.

ok then...

> [snip]
>
> --
> Keith Thompson (The_Other_Keith) kst-u@mib.org
> <http://www.ghoti.net/~kst>
> Nokia
> "We must do something. This is something. Therefore, we must do this."
> -- Antony Jay and Jonathan Lynn, "Yes Minister"

== 8 of 13 ==
Date: Thurs, Jul 30 2009 7:28 pm
From: "BGB / cr88192"

"Jerry Coffin" <jerryvcoffin@yahoo.com> wrote in message
news:MPG.24dbf743b702ff7198971c@news.sunsite.dk...
> In article <h4tgv6$b59$1@news.albasani.net>, cr88192@hotmail.com
> says...
>
> [ ... ]
>
>> a C++ app necessarily contains dependencies on C code (in the form
>> of runtime libraries, the OS, ...).
>
> So you're claiming that all C++ code uses parts of the standard
> library that use dynamic memory written in C? You're also claiming
> that ever OS is written in C?
>
> If you honestly believe either, further discussion is clearly
> pointless, since your idea of "reality" differs too radically from
> mine to give sufficient common ground for meaningful communication.
>

yep on the former, or at least, any non-trivial app will end up using (if
indirectly) components written in C.

for example:
in Linux, the kernel is C;
the X server is C;
GTK is C (and also one of the core components of GNome);
...

Windows is similar...

C code is essentially inescapable, much like ASM is inescapable...

to escape C, one would essentially either have to run their code on raw
hardware, or use an OS with the kernel and all core system functionality
written in C++...

either way, the point is moot, C does not inherently have leaks, it only
often does (and, more often, these leaks are cleaned up by idirect action,
thus making them typically not matter...).

leaks are common, and can happen easily if one is not careful, but they are
not unavoidable either...
in the common case, there are all sorts of (generally effective) strategies
to avoid them.

C having leaks is much like ASM being buggy...

it is difficult to avoid bugs in ASM, but it can be done, and often is
done...

fix the bugs, or seal the leaks, either one can be done...

> --
> Later,
> Jerry.

== 9 of 13 ==
Date: Thurs, Jul 30 2009 8:28 pm
From: Phil Carmody

"Tech07" <tech07@nospam.hia> writes:
> "Phil Carmody" <thefatphil_demunged@yahoo.co.uk> wrote in message
> news:874ostkewc.fsf@kilospaz.fatphil.org...
>> "Tech07" <tech07@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?

Phil
--
If GML was an infant, SGML is the bright youngster far exceeds
expectations and made its parents too proud, but XML is the
drug-addicted gang member who had committed his first murder
before he had sex, which was rape. -- Erik Naggum (1965-2009)

== 10 of 13 ==
Date: Thurs, Jul 30 2009 8:34 pm
From: Phil Carmody

"BGB / cr88192" <cr88192@hotmail.com> writes:
> "BGB / cr88192" <cr88192@hotmail.com> wrote in message
> news:h4t6p7$rm0$1@news.albasani.net...
>>
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:lnvdl9ygr6.fsf@nuthaus.mib.org...
>>> "BGB / cr88192" <cr88192@hotmail.com> writes:
>>>> "Squeamizh" <squeamz@hotmail.com> wrote in message
>>>> news:c0927f54-f774-4c28-ad22-69ae3ee4e2b6@l5g2000pra.googlegroups.com...
>>>> On Jul 30, 12:34 pm, "BGB / cr88192" <cr88...@hotmail.com> wrote:
>>> [...]
>>>>> nesting and using "local objects" in this way, is bad practice, FWIW...
>>>>> granted, some newer compilers allow it (such as GCC), and it is part of
>>>>> C99, but this does not make it a good style.
>>>>>
>>>>> either all declarations are done at the top of the function, or the
>>>>> function should be split.
>>>>
>>>> <--
>>>> First, you're wrong; declaring variables local to a block is legal in
>>>> c89. Secondly, you labeling something as "bad practice" is
>>>> meaningless without being accompanied by some sort of explanation.
>>>> WHY is it bad practice?
>>>> -->
>>>>
>>>> AFAIK, it is not legal in C89 (after all, if it had been legal since
>>>> C89, no one would need mention it becomming legal in C99...).
>>>>
>>>> (note: by this, I meant internal blocks, such as with a for loop or if
>>>> block...).
>>>>
>>>> it was only "made" legal in C99, and was informally legal in many
>>>> compilers
>>>> (much like the "//" comment syntax, which has worked damn near as long
>>>> as I have been using C, but was also not legal until C99...).
>>>
>>> You are mistaken.
>>>
>>> Mixing declarations and statements within a block is illegal in C90,
>>> legal in C99 and C++.
>>>
>>> Declarations within blocks have been legal at least since K&R1; even
>>> BCPL permitted them.
>>
>> this is what I had meant...
>>
>> you misunderstood what I had written...
>
> to clarify:
> int foo()
> {
> int i, j, k;
> ...
> for(i=0; i<10; i++)
> ...
> }
>
> this is OK, no problems...
>
> now as for:
> int foo()
> {
> ...
> for(int i=0; i<10; i++)
> {
> int j, k;
> ...
> }
> ...
> }
>
> only valid for C++ and for C99 and newer, and supported as a language
> extension to many C compilers, but not technically not legal in C89.

Only because of the 'for(int i' part. Which, by no stretch of the
imagination is most simply described as a "declaration within a block".

The "{ int j,k;" part is perfectly legal in every version of C Keith
said it was legal in. Why did you completely ignore what he had to say?

> this would seem to be what the prior person was debating...
>
> my use of "block" then, meant "internal blocks" or similar, not the function
> as a whole...

Your use of "block" shows you don't know what you're talking about.

== 11 of 13 ==
Date: Thurs, Jul 30 2009 9:09 pm
From: Richard Heathfield

Jerry Coffin said:

> 1) Decades of experience has shown that while it's _theoretically_
> possible to get it right in C, that in the entire history of C,
> there's probably never been even one nontrivial program that didn't
> have at least one memory management problem.

This is trivially true, provided we define "nontrivial C program" as
"C program containing at least one memory management problem".

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
This line unintentionally left unblank

== 12 of 13 ==
Date: Thurs, Jul 30 2009 9:30 pm
From: cri@tiac.net (Richard Harter)

On Fri, 31 Jul 2009 04:09:03 +0000, Richard Heathfield
<rjh@see.sig.invalid> wrote:

>Jerry Coffin said:
>
>> 1) Decades of experience has shown that while it's _theoretically_
>> possible to get it right in C, that in the entire history of C,
>> there's probably never been even one nontrivial program that didn't
>> have at least one memory management problem.
>
>This is trivially true, provided we define "nontrivial C program" as
>"C program containing at least one memory management problem".

That works. :-)

I suspect that Mr. Coffin's expertise lies in being well informed about the
opinions of Mr. Coffin.

Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
No one asks if a tree falls in the forest
if there is no one there to see it fall.

== 13 of 13 ==
Date: Thurs, Jul 30 2009 10:13 pm
From: "BGB / cr88192"

"Richard Heathfield" <rjh@see.sig.invalid> wrote in message
news:IIOdnQIz0edX8e_XnZ2dnUVZ8nhi4p2d@bt.com...
> Jerry Coffin said:
>
>> 1) Decades of experience has shown that while it's _theoretically_
>> possible to get it right in C, that in the entire history of C,
>> there's probably never been even one nontrivial program that didn't
>> have at least one memory management problem.
>
> This is trivially true, provided we define "nontrivial C program" as
> "C program containing at least one memory management problem".
>

yep...

then again, I guess another question is:
what of the case where the app could run indefinitely long, as on the large
scale, it runs in constant space, but still fails to free all of its
memory?... (instead, relying on the process exiting, eventually, to destroy
the heap...).

so, we can then split memory leaks into 2 major camps:
continuous leaks, where during its operation the app allocates memory, and
then leaks it;
teardown leaks, where the app is lazy and does not entirely perform
teardown, since the OS will clean up the mess anyways.

an example of the former is non-careful use of malloc and strdup and
similar...

an example of the latter, is using a garbage collector, but failing to do a
teardown when the app exits (AKA: telling the GC to go free the heap and any
internal structures).

granted, some of my code is subject to this latter condition, as often I
have not bothered with a comprehensive teardown (actually, sadly... about
the only code I really have which bothers with proper teardown, is those
parts of my projects originally derived from Quake and similar...).

in a way it is kind of funny...

when I was young, I had largely learned programming through the use of id
software's source code... (well, that, and to a lesser extent, the Linux
kernel...).

decided on leaving out a bunch of me being emo...

it is sadly lame... nearly my whole life thus far has amounted to little
more than me cloning damn near everything I have seen, but never really
matching or surpassing any of it...

if there is anything I am good at, it is seeing things and then beating
together something that does about the same, but a critical wall exists: it
seems this is my limit... all just a variant or a poor immitation...

or such...

==============================================================================
TOPIC: Can iterator be checked to be at end of vector?
http://groups.google.com/group/comp.lang.c++/t/04f21bec592f548d?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jul 30 2009 6:02 pm
From: Jerry Coffin

In article <4f782394-117b-4e04-8af9-
0516a1b2166a@h11g2000yqb.googlegroups.com>,
kees.van.der.bent@gmail.com says...

[ ... ]

> Is there a meaningful (not technical) reason why an iterator does
> not have this information? You write my "its" between ""; is there
> perhaps any clue in why you do this, in how you conceptually see an
> iterator and "its" container?

I'm not sure what "not technical" is supposed to mean here, but the
key reason (IMO, at least) is that an iterator doesn't necessarily
have to be associated with a container at all.

Just for example, consider a random number iterator that you
dereference to generate random (or pseudorandom, as the case may be)
numbers. To get truly random numbers, it might read data from a
thermal diode or a radioactive source. A pseudorandom generator would
invoke its underlying generator for each new number.

OTOH, you could simply treat cases like this as exceptions that would
just have trivial implementations that always said that yes, the
iterator was still "valid".

--
Later,
Jerry.

==============================================================================
TOPIC: How can I use unqualified names? (Possibly hard or impossible?)
http://groups.google.com/group/comp.lang.c++/t/e2f24a95fe72b591?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jul 30 2009 6:17 pm
From: Gerhard Fiedler

James Kanze wrote:

> I've looked a little bit more at it. I don't see a shell. Using
> Unix-like tools means linking them together---the shell is the glue.
> And the default Windows command interpreter (what executes .bat
> files) is pretty weak. What do Windows users use for this?

Typically cmd.exe; as Jerry says, it's not that weak, it's just that
most people don't know how to use it :)

(On a side note: If you want to surprise a typical Windows "power" user,
bring up a listing of the .exe files in the Windows system32 directory.
Most are command line tools, and many don't know a tenth of it.)

Besides what Jerry wrote, there are native builds of many Unix shells.
If you already know how to use them, this may be the way for you.

There's also 4NT from jpsoft.com, which is sort of a more powerful
cmd.exe, backwards compatible. But their extensions are custom and not
commonly known or used.

Also note that many Windows command line tools use or accept the dash as
option separator and the forward slash as path separator. (AFAIK all of
the Win32 API accepts the forward slash as path separator.)

Gerhard

==============================================================================
TOPIC: ◎♥◎wholesale Iphone,Nokia,Samsung,Blackberry,etc brand mobile phones,
TV mobiles,Music Mobiles, Touch Mobiles, Dual sim card dual standby Chinese
mobile phones◎♥◎ www.toptradea.com◎♥◎
http://groups.google.com/group/comp.lang.c++/t/0607e55d23b660fb?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jul 30 2009 7:58 pm
From: "www.toptradea.com Toptradea"

◎♥◎wholesale Iphone http://www.toptradea.com/category.php?id=435
Nokia http://www.toptradea.com/category.php?id=436
Blackberry http://www.toptradea.com/category.php?id=437
HTC http://www.toptradea.com/category.php?id=438
Samsung http://www.toptradea.com/category.php?id=440
Motorola http://www.toptradea.com/category.php?id=439,etc brand mobile
phones, TV mobiles,Music Mobiles, Touch Mobiles, Dual sim card dual
standby Chinese mobile phones◎♥◎ www.toptradea.com◎♥◎

Iphone http://www.toptradea.com/category.php?id=435
Nokia http://www.toptradea.com/category.php?id=436
Blackberry http://www.toptradea.com/category.php?id=437
HTC http://www.toptradea.com/category.php?id=438
Samsung http://www.toptradea.com/category.php?id=440
Motorola http://www.toptradea.com/category.php?id=439

==============================================================================
TOPIC: Printing the last item of a structure twice
http://groups.google.com/group/comp.lang.c++/t/9fd75392aae26667?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jul 30 2009 8:29 pm
From: red floyd

Jerry Coffin wrote:
> In article <6ff1c26e-5bf9-4092-86aa-d021f3e310e3
> @h30g2000vbr.googlegroups.com>, rafael.anschau@gmail.com says...
>
> [ ... ]
>
>> while(!feof(fp)) {
>
> Your problem is right here. The problem is that eof on a stream isn't
> detected until AFTER you attempt a read and you're at the end of the
> end of the file, and the attempted read fails. When the read fails at
> the end of the file, what was previously read will still be there,
> but you won't have detected the end of the file yet, so you'll
> process it again. Then the code above will detect that the previous
> read failed and quit trying to read any more.
>

What Jerry said. See FAQ 15.5

http://parashift.com/c++-faq-lite/input-output.html#faq-15.5

==============================================================================
TOPIC: Difference between Windows and Linux GCC compiler
http://groups.google.com/group/comp.lang.c++/t/f432fafbea7d806a?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Jul 30 2009 9:21 pm
From: Rayne

Hi all,

I'm interested to know what is the difference in programming using MS
Visual C++ on Windows and using the GCC compiler on Linux, i.e. what
are some of the things I can do on Visual C++ that won't compile/run
on Linux, and vice versa.

For example, I know that Windows uses the LLP64 model, while Linux
uses the LP64 model, so I can't use the long long data type when
programming on Linux. Also, the windows.h file is only available in
Windows, and can't be used on Linux. I've also read that there is also
some differences in network programming, since winsock, and especially
the underlying ip headers are much different in Windows than Unix/
Linux gcc. Is this true?

Thank you.

== 2 of 2 ==
Date: Thurs, Jul 30 2009 10:50 pm
From: Ian Collins

Rayne wrote:
> Hi all,
>
> I'm interested to know what is the difference in programming using MS
> Visual C++ on Windows and using the GCC compiler on Linux, i.e. what
> are some of the things I can do on Visual C++ that won't compile/run
> on Linux, and vice versa.
>
> For example, I know that Windows uses the LLP64 model, while Linux
> uses the LP64 model, so I can't use the long long data type when
> programming on Linux.

Where did you get that idea from?

All the models do is specify the size longs and pointers. long long is
part of the C standard.

> Also, the windows.h file is only available in
> Windows, and can't be used on Linux.

What use would it be on anything other than windows?

> I've also read that there is also
> some differences in network programming, since winsock, and especially
> the underlying ip headers are much different in Windows than Unix/
> Linux gcc. Is this true?

Not really. Once you get past initialisation, there's not a lot of
difference and socket level code is pretty portable between platforms.

This isn't really the place to ask, you have more luck asking windows
questions on a windows group and Unix ones on comp.unix.programmer.

--
Ian Collins

==============================================================================
TOPIC: ♥◎♥Hot sale Iphone 3G 16gb&8gb,Iphone3Gs,M89,M88,T32,G1,G2,TV Brand new,
unlocked,with all accessories Our policy: order 1-3pce brand mobile with a
free polo Tshirt, order more than 5 pcs brand mobiles with a free nike sneaker
(time limited) ♥
http://groups.google.com/group/comp.lang.c++/t/4ed425c1569ecfd7?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jul 30 2009 10:02 pm
From: "www.toptradea.com Toptradea"

♥◎♥Hot sale Iphone 3G 16gb&8gb http://www.toptradea.com/category.php?id=435
,Iphone3Gs http://www.toptradea.com/category.php?id=435 ,M89
http://www.toptradea.com/category.php?id=435 ,M88
http://www.toptradea.com/category.php?id=435 ,T32
http://www.toptradea.com/category.php?id=435 ,G1 http://www.toptradea.com/category.php?id=435
,G2 http://www.toptradea.com/category.php?id=435 ,TV Brand
new,unlocked,with all accessories Our policy: order 1-3pce brand
mobile with a free polo Tshirt, order more than 5 pcs brand mobiles
with a free nike sneaker (time limited) ♥

==============================================================================
TOPIC: 〓〈◆〉〓Air Jordan,Nike,Air Max,Shox,Rift,Max 2009, Jordan 2009
Wholesale and retail, paypal payment! Welcome to www.toptradea.com
http://groups.google.com/group/comp.lang.c++/t/b9a2374df0538504?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jul 30 2009 10:05 pm
From: "www.toptradea.com Toptradea"

==============================================================================
TOPIC: ♂◆♀♥Handbags supplier 田www.toptradea.com田 Lady Handbags Juicy,Gucci,
LV,Prada,D&G,Edhardy,Chanel,Coach, Jimmy-Hoo,Burberry,DB ┈━═☆
http://groups.google.com/group/comp.lang.c++/t/34eb1c4b019ed9b6?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jul 30 2009 10:09 pm
From: "www.toptradea.com Toptradea"

==============================================================================
TOPIC: dealing with lower level programmers
http://groups.google.com/group/comp.lang.c++/t/f708a2c0cfa8ce2d?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Jul 30 2009 10:25 pm
From: Ian Collins

James Kanze wrote:
>
> Without some sort of process, you don't know whether your
> software is doing what it is supposed to do, or how good you
> really are. Noah was very right about one thing: you have to
> measure.

Ah, but measure what?

I've always judged my my code by either customer satisfaction and (lack
of!) support revenue with a single customer or field defects for
applications with many, unknown, customers.

--
Ian Collins

== 2 of 2 ==
Date: Thurs, Jul 30 2009 10:32 pm
From: fft1976

On Jul 29, 2:10 am, James Kanze <james.ka...@gmail.com> wrote:
> On Jul 28, 10:08 pm, fft1976 <fft1...@gmail.com> wrote:
>
> > On Jul 26, 12:44 am, James Kanze <james.ka...@gmail.com> wrote:
> > > I don't think a professional programmer can succeed without
> > > good management, regardless of how good he is.
> > This confirms my suspicion that you've never worked with
> > anyone good. (Being good is somewhat different than being a
> > language lawyer, by the way)
>
> So show an exception. Empirical evidence supports my
> statement---where management is bad, projects fail, regardless
> of how good the programmers on them are. To date, no one has
> been able to present an exception, and an awfully large data set
> has been examined.

That's not what you said, actually. "Without management" and "with bad
management" are different things.

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en

To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

soft and program

Thursday, July 30, 2009

comp.lang.c++ - 25 new messages in 11 topics - digest

No comments:

Blog Archive

About Me