soft and program: comp.lang.c++ - 26 new messages in 13 topics

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

comp.lang.c++@googlegroups.com

Today's topics:

* ￠¤￠Wholesale Tshirt and Jeans BBC,Evis,POLO,Lacoste,Affliction ,Gucci,
Edhardy,Armani,LV,Christina Audigier ￠¤￠www.toptradea.com￠¤￠ - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/07dfce3de48798b9?hl=en
* ◎●◎Sneaker of Nike,Jordan,Gucci,Adidas,Puma,EdhardyShox,Max,Free,Rift◎Polo,
Lacoste,BBC,Gucci,Armani,LV,Christina Audigier Tshirt and Jeans www.toptradea.
com◎●◎ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/c7a0c768bbfa8c83?hl=en
* ♥◆⊙→Fashion Handbags supplier ♂www.toptradea.com♀ Lady Handbags Juicy,Gucci,
LV,Prada,D&G,Edhardy,Chanel,Coach, Jimmy-Hoo,Burberry,DB ♥www.toptradea.com◆
paypal payment♥ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/b1d3e8cd259ca532?hl=en
* ♡〓♡Wholesale Fashion Jeans Prada,RMC,G-star,Cavalli,Iceberg,Levis,Coogi,BBC,
Laguna,True Religion Jeans www.toptradea.com ♡〓♡ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/eb5353583931a294?hl=en
* ●→●→Wholesale Nokia ,Iphone, Samsung, Blackberry, Sony, Motorola,etc brand
mobiles "www.toptradea.com" ◆ 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/ec04140d49adb25a?hl=en
* New release of the Dynace OO extension to C - 7 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/ee8689156295093c?hl=en
* negative powers of two - 5 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/50db9695edc9e79f?hl=en
* Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3? - 3 messages, 3
authors
http://groups.google.com/group/comp.lang.c++/t/40783f7f814400c9?hl=en
* Blog: C++ Code Smells - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/1aab587446556099?hl=en
* strcpy vs memcpy - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/71a5945deead500c?hl=en
* static inline functions - possible? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/0386357e12bd0064?hl=en
* dealing with lower level programmers - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/f708a2c0cfa8ce2d?hl=en
* ◆⊙→Www.toptradea.com Best mobile phones supplier Hot sale Nokia,8800arte,
8600,6300,5800,6500,E series E71,E66,E75, N seies N97,N96,N95,N86,N85,N81,N79,
N78,N72 //Our policy: order 1-3pce brand mobile with a free polo Tshirt - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/e81307217ccf57d1?hl=en

==============================================================================
TOPIC: ￠¤￠Wholesale Tshirt and Jeans BBC,Evis,POLO,Lacoste,Affliction ,Gucci,
Edhardy,Armani,LV,Christina Audigier ￠¤￠www.toptradea.com￠¤￠
http://groups.google.com/group/comp.lang.c++/t/07dfce3de48798b9?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 1 2009 9:39 am
From: "www.toptradea.com Toptradea"

==============================================================================
TOPIC: ◎●◎Sneaker of Nike,Jordan,Gucci,Adidas,Puma,EdhardyShox,Max,Free,
Rift◎Polo,Lacoste,BBC,Gucci,Armani,LV,Christina Audigier Tshirt and Jeans www.
toptradea.com◎●◎
http://groups.google.com/group/comp.lang.c++/t/c7a0c768bbfa8c83?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 1 2009 9:42 am
From: "www.toptradea.com Toptradea"

==============================================================================
TOPIC: ♥◆⊙→Fashion Handbags supplier ♂www.toptradea.com♀ Lady Handbags Juicy,
Gucci,LV,Prada,D&G,Edhardy,Chanel,Coach, Jimmy-Hoo,Burberry,DB ♥www.toptradea.
com◆ paypal payment♥
http://groups.google.com/group/comp.lang.c++/t/b1d3e8cd259ca532?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 1 2009 9:44 am
From: "www.toptradea.com Toptradea"

==============================================================================
TOPIC: ♡〓♡Wholesale Fashion Jeans Prada,RMC,G-star,Cavalli,Iceberg,Levis,
Coogi,BBC,Laguna,True Religion Jeans www.toptradea.com ♡〓♡
http://groups.google.com/group/comp.lang.c++/t/eb5353583931a294?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 1 2009 9:47 am
From: "www.toptradea.com Toptradea"

==============================================================================
TOPIC: ●→●→Wholesale Nokia ,Iphone, Samsung, Blackberry, Sony, Motorola,etc
brand mobiles "www.toptradea.com" ◆ 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/ec04140d49adb25a?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 1 2009 9:49 am
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, Motorola,etc
brand mobiles "www.toptradea.com" ◆ 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)

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: New release of the Dynace OO extension to C
http://groups.google.com/group/comp.lang.c++/t/ee8689156295093c?hl=en
==============================================================================

== 1 of 7 ==
Date: Sat, Aug 1 2009 10:32 am
From: "BGB / cr88192"

"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message
news:c67137f8-1a28-463e-8653-0f5bcfb4a7ae@s15g2000yqs.googlegroups.com...
> On 23 July, 15:26, "BGB / cr88192" <cr88...@hotmail.com> wrote:
>> "Richard Herring" <junk@[127.0.0.1]> wrote in message
>> news:E8KZCPFDjDaKFwRn@baesystems.com...
>> > In message <h487g9$lr...@news.albasani.net>, BGB / cr88192
>> > <cr88...@hotmail.com> writes
>> >>"Ian Collins" <ian-n...@hotmail.com> wrote in message
>> >>news:7co7v7F28he98U2@mid.individual.net...
>>
>> >>> Memory is only one resource a programme has to manage.
>>
>> >>it is, however, the main resource,
>>
>> > For some definition of "main".
>>
>> my experience:
>> memory is the primary resource;
>> most others are either minor, or virtual (as in, built on top of memory
>> objects).
>
> even things that are bult on top of memory may need specialised
> cleanup. Sockets, Database Connections, GDI handles.
>

depends on how this cleanup is designed to be done though...

the majority of memory objects can simply be garbage collected.
in much the same way, the majority of memory objects can be simply
destroyed...

some need destructors, ...

> Then there are application specific things. Like calls or
> messages or drawable objects. Even to use garbage collection
> requires that you remeber to forget about the object. The dead
> call has to be removed from the list of active calls *somehow*
>

this is called "semantic garbage", and, yes, this needs to be managed
somehow.
one possibility is to add customized "behavior" handlers to the garbage
collector.

another possibility is the use of weak references (in my GC, these can be
pulled off by a special box type, which is itself just a normal memory
object with specialized behavior handlers...).

>> >>and about the only resource whose
>> >>management becomes an application-scale issue...
>>
>> > In your world, possibly.
>>
>> > Memory has the useful property of being highly fungible, which makes it
>> > relatively easy to manage even with deferred release (GC) techniques.
>> > Other resources frequently are not, which puts a greater stress on
>> > timely
>> > release of each individual resource (e.g. think of interlocked database
>> > files being shared between multiple processes).
>>
>> open connection
>> perform transaction
>> close connection
>
> doesn't help in event driven code where things persist over
> multiple events.
>

not really "usually" a problem, as many things can be open/closed in the
event handlers.

consider a "save" event:
open file;
dump crap to file;
close file.

now, this leaves GUI, which is handled via a different strategy:
I confine the GUI to a small area of code, which goes through an "init" and
a "teardown" step;
then there is the window event handlers and similar, which typically just do
things like set some flags, or add items to a queue.

later on, another piece of code polls the queue, and maybe does something
with the event (such as re-dispatching it, or transcribing it to the next
queue).

some systems flatten the event system into a stack, which works in cases
where LIFO is an acceptable model...

forcing most of a codebase to deal directly with GDI or similar seems
terrible...

but, then again, I typically don't use native widgets, rather I typically do
my own GUIs (and, via visual inspection, have been able to largely fake the
"look and feel" of native widgets via GL...). not that it matters too much,
as many of my early GUIs used color-coded boxes, and this worked well
enough...

note that "traditional" event-driven programming is not particularly
compatible with soft-real-time systems (where, handlers may directly drive
large amounts of logic code), whereas the use of event queues mixes much
better (each "event" is then queued, and handled "when possible").

granted, it is a risk though, for example, the use of "open, dump, close"
for save operations, typically involves a minor stall for larger files...
similarly, splitting off the saver into its own thread carries the risk that
the data could be modified mid-save, and usually a save is regarded as a
"commit" (meaning, stall until done).

similarly, stalls are difficult to avoid for major load operations (although
minor loads can often be delayed some, such that the resource is "filled in"
until loaded, which can help avoid some of the stall).

I guess doing loads and saves in an event driven manner is possible, but I
had not considered this before, hmm...

== 2 of 7 ==
Date: Sat, Aug 1 2009 10:33 am
From: Juha Nieminen

Nick Keighley wrote:
> well, you've got to write your destructors correctly.

I think you are just trying to rationalize how RAII doesn't *really*
bring any benefit compared to manual scope management, as if it was
completely equivalent to have to perhaps write a destructor once and
have the compiler call it automatically from every place where the
object is used, and to have to basically inline destructors manually at
each usage point.

Besides, you are missing the point: "Writing destructors correctly" is
not a coding convention to *get around a limitation* in the language.
It's using a language feature for its intended purpose and to help
reduce the amount of coding conventions needed in the program.

== 3 of 7 ==
Date: Sat, Aug 1 2009 6:25 pm
From: "Tech07"

jacob navia wrote:
> Jerry Coffin wrote:
>>
>> The basic problem being dealt with is pretty simple. In C, you run
>> into two problems. First of all, about the only thing C provides for
>> dealing with dynamic data is malloc/calloc/realloc/free. Second, it
>> makes it essentially impossible to centralize the use of those tools.
>>
>
> The lcc-win C compiler provides a GC.

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

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

Programming without memory management isn't programming. ;)

> You just
> replace malloc by GC_malloc, and forget about free

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

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

== 4 of 7 ==
Date: Sat, Aug 1 2009 6:31 pm
From: "Tech07"

BGB / cr88192 wrote:
> "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...
>

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

== 5 of 7 ==
Date: Sat, Aug 1 2009 6:35 pm
From: "Tech07"

Phil Carmody wrote:
> "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?
>

"Ball is in your court", not mine: you've yet to show that you can read and
comprehend what was written. (I'm not dissing you if you can't
read/comprehend, really. I'm not the one to help you with that is all. No
need to get mad. Want me to chat with your guardian? Counselor? Parole
officer?).

== 6 of 7 ==
Date: Sat, Aug 1 2009 6:41 pm
From: "BGB / cr88192"

"Tech07" <tech07@nospam.hia> wrote in message
news:w%5dm.95231$eS5.48829@newsfe25.iad...
> BGB / cr88192 wrote:
>> "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...
>>
>
> Why is it, that when a GC thread emerges, that I feel like spray-painting
> on it?

I don't know...

either way, the technology works well for what it does...

== 7 of 7 ==
Date: Sat, Aug 1 2009 6:45 pm
From: "BGB / cr88192"

"Tech07" <tech07@nospam.hia> wrote in message
news:NV5dm.24356$sC1.1248@newsfe17.iad...
> jacob navia wrote:
>> Jerry Coffin wrote:
>>>
>>> The basic problem being dealt with is pretty simple. In C, you run
>>> into two problems. First of all, about the only thing C provides for
>>> dealing with dynamic data is malloc/calloc/realloc/free. Second, it
>>> makes it essentially impossible to centralize the use of those tools.
>>>
>>
>> The lcc-win C compiler provides a GC.
>
> You say that as if it was a lucrative feature. (hint, hint: not to me!).
>
>> This allows for much easier
>> programming what memory management is concerned.
>
> Programming without memory management isn't programming. ;)
>
>> You just
>> replace malloc by GC_malloc, and forget about free
>
> Keywords one hears all over the place: "you just...". Well, personally, "I
> don't wanna just.. " anything. :P
>
> Trying to sell "you don't have to think about it!" to thinkers (yes, the
> IQ on here is way above the average Joe/Jane) on USENET is doomed to
> failure. I suggest you not pursue a marketing career, cuz you really suck
> at it.
>

in my case, I use a GC, but typically treat it like a manual memory manager.
why? because that typically gives higher performance and more desirable
runtime behavior...

>
>

==============================================================================
TOPIC: negative powers of two
http://groups.google.com/group/comp.lang.c++/t/50db9695edc9e79f?hl=en
==============================================================================

== 1 of 5 ==
Date: Sat, Aug 1 2009 12:08 pm
From: Keith H Duggar

On Aug 1, 10:38 am, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
> In article <069cb282-77ec-45c0-bcd6-2aa88e53ec48
> @k6g2000yqn.googlegroups.com>, james.ka...@gmail.com says...
> > On Jul 31, 6:01 pm, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
> > > Whether this will be faster than pow() will depend -- for a
> > > lot of cases where the floating point is stored as a
> > > significand and a power of two, frexp will be something like a
> > > mask, shift and an integer subtraction to remove a bias in the
> > > exponent. As you'd expect, ldexp will pretty much reverse
> > > that: add the bias, shift to the right position, OR with the
> > > significand. Generally pretty fast. OTOH, if the native
> > > floating point representation is drastically different from
> > > that, they could end up pretty slow -- but machines with such
> > > strange floating point representations are pretty unusual.
>
> > Not really. I don't know of any mainframe which uses base 2 for
> > its floating point: IBM uses base 16, and both Unisys
> > architectures use base 8; Unisys MCP also normalizes in a
> > somewhat strange way. The fact that the bases are powers of two
> > means that the operation can still be done with masking and
> > shifting, but it requires a bit more than a base 2
> > representation would.
>
> You start by saying "not really", but from what I can see, you then
> go on to pretty much confirm what I said -- that while these machines
> aren't binary, they still work in a power of two, which means that
> frexp/ldexp will probably be faster than pow() for all of them.

You didn't claim anything about systems that "work in a power
of two". You specifically made a claim about systems that do not
store floating point "as a significand and a power of two". The
most obvious interpretation of that does not include systems
that store as a significand and a power of 8 or 16 etc. Though
it is possible your words also meant to include such powers of
powers of 2 as well, the operations you sketched for frexp seem
to indicate you did not mean to include them. So either James
correctly called you on your faulty assumptions and you are
backpedaling (as you have done elsewhere), or it was a totally
understandable miscommunication.

> I have to admit I'm a bit surprised though -- I thought IBM's
> mainframes used decimal floating point, not hexadecimal...

You are surprised that you were wrong? I'm not ...

By the way, are you just going to slither quietly away from the
goto debate after you were trounced or are you going to man up
and admit goto was faster and that your "analysis" (to use the
word extremely loosely) of modern machines that was filled with
numerous faulty assumptions (such as the possibility above) was
flawed?

http://groups.google.com/group/comp.lang.c++.moderated/msg/3ac2368e485e740d
http://groups.google.com/group/comp.lang.c++.moderated/msg/5d471364e76392d9

(First link presents hard data proving you wrong and the second
calls you out on your flawed understanding and assumptions and
challenges you to explain the data or provide new measurements
that correct the proven problems in your initial testing.)

You know, it really is quite liberating to admit when you are
wrong; there is no shame in learning. You should try doing it
sometime.

KHD

== 2 of 5 ==
Date: Sat, Aug 1 2009 2:28 pm
From: Jerry Coffin

In article <8b807dad-e6d5-41d4-8f07-9ffefe91bcc3
@g6g2000vbr.googlegroups.com>, duggar@alum.mit.edu says...
>
> On Aug 1, 10:38 am, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
> > In article <069cb282-77ec-45c0-bcd6-2aa88e53ec48
> > @k6g2000yqn.googlegroups.com>, james.ka...@gmail.com says...
> > > On Jul 31, 6:01 pm, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
> > > > Whether this will be faster than pow() will depend -- for a
> > > > lot of cases where the floating point is stored as a
> > > > significand and a power of two, frexp will be something like a
> > > > mask, shift and an integer subtraction to remove a bias in the
> > > > exponent. As you'd expect, ldexp will pretty much reverse
> > > > that: add the bias, shift to the right position, OR with the
> > > > significand. Generally pretty fast. OTOH, if the native
> > > > floating point representation is drastically different from
> > > > that, they could end up pretty slow -- but machines with such
> > > > strange floating point representations are pretty unusual.
> >
> > > Not really. I don't know of any mainframe which uses base 2 for
> > > its floating point: IBM uses base 16, and both Unisys
> > > architectures use base 8; Unisys MCP also normalizes in a
> > > somewhat strange way. The fact that the bases are powers of two
> > > means that the operation can still be done with masking and
> > > shifting, but it requires a bit more than a base 2
> > > representation would.
> >
> > You start by saying "not really", but from what I can see, you then
> > go on to pretty much confirm what I said -- that while these machines
> > aren't binary, they still work in a power of two, which means that
> > frexp/ldexp will probably be faster than pow() for all of them.
>
> You didn't claim anything about systems that "work in a power
> of two". You specifically made a claim about systems that do not
> store floating point "as a significand and a power of two".

Obviously you don't even know how to read. What I said was: "if the
native floating point representation is drastically different from
that, they could end up pretty slow"

Since apparently don't know English very well, and are just too
damned lazy to look it up, "drastically" is defined as: "Extreme,
severe; Acting rapidly or violently; Extremely severe or extensive"

In case that didn't make it obvious, NOT EVERY POSSIBLE DIFFERENCE IS
DRASTIC!

> The
> most obvious interpretation of that does not include systems
> that store as a significand and a power of 8 or 16 etc. Though
> it is possible your words also meant to include such powers of
> powers of 2 as well, the operations you sketched for frexp seem
> to indicate you did not mean to include them. So either James
> correctly called you on your faulty assumptions and you are
> backpedaling (as you have done elsewhere), or it was a totally
> understandable miscommunication.

Nonsense! What I said was that when/if the representation is
drastically different, that frexp/ldexp might be quite slow. When the
base isn't binary, but is still a power of two, there's no real
reason to believe that frexp or ldexp will be particularly slow.
Specifically, they will almost certainly still be substantially
faster than pow().

> By the way, are you just going to slither quietly away from the
> goto debate after you were trounced or are you going to man up
> and admit goto was faster and that your "analysis" (to use the
> word extremely loosely) of modern machines that was filled with
> numerous faulty assumptions (such as the possibility above) was
> flawed?

There's not "slithering" involved. There was a conscious decision to
ignore you because you're clearly an liar who simply started making
up nonsense rather than admitting that he was dead from from
beginning to end.

> http://groups.google.com/group/comp.lang.c++.moderated/msg/3ac2368e485e740d
> http://groups.google.com/group/comp.lang.c++.moderated/msg/5d471364e76392d9
>
> (First link presents hard data proving you wrong and the second
> calls you out on your flawed understanding and assumptions and
> challenges you to explain the data or provide new measurements
> that correct the proven problems in your initial testing.)

All you presented was a bunch of unsupported claims that didn't prove
anything.

> You know, it really is quite liberating to admit when you are
> wrong; there is no shame in learning. You should try doing it
> sometime.

I've done so many times, and when I'm wrong again, I'll do so again.

In this case, you're the one who was wrong, and you're the one who
has failed to admit it.

In this thread, you've not only been wrong, but clearly lied through
your teeth, not even attempting to quote me accurately at all. At
least previously you attempted to post your lies in a way that it was
difficult to prove them wrong. Now you're not only lying, but doing
it in an incredibly STUPID manner that was trivial to prove.

Go away and grow up you pathetic worm!

--
Later,
Jerry.

== 3 of 5 ==
Date: Sat, Aug 1 2009 3:18 pm
From: Jerry Coffin

In article <069cb282-77ec-45c0-bcd6-2aa88e53ec48
@k6g2000yqn.googlegroups.com>, james.kanze@gmail.com says...

[ ... ]

> Not really. I don't know of any mainframe which uses base 2 for
> its floating point: IBM uses base 16, and both Unisys
> architectures use base 8; Unisys MCP also normalizes in a
> somewhat strange way. The fact that the bases are powers of two
> means that the operation can still be done with masking and
> shifting, but it requires a bit more than a base 2
> representation would.

Since Kieth decided to jump in with his usual unprovoked and
inaccurate attack, I decided to do a bit of fact checking.

At: http://www.ibm.com/developerworks/library/pa-bigiron1/

IBM says: "The System/390 implemented the IEEE 754 BFP formats in
addition to HFP for the first time in 1995" (using "BFP" as an
abbreviation for "binary floating point"), so their mainframes have
had binary floating point for about 14 years now.

At:
http://portal.acm.org/citation.cfm?id=1241826
&dl=GUIDE&coll=GUIDE&CFID=46010576&CFTOKEN=73022622

is an article from the IBM Journal of Research and Development. The
full article is not free, but the abstract says:

[ ... ] Use of the newly defined decimal floating-point
(DFP) format instead of binary floating-point is
expected to significantly improve the performance of
such applications. System z9TM is the first IBM machine
to support the DFP instructions.

To summarize, then: current IBM mainframes support floating point in
three bases: hexadecimal, binary, and decimal. Support for the bases
was added in that order. Hexadecimal has been supported for decades,
binary for a decade and a half, and decimal for something like a year
and a half.

As far as the original question goes, the only time you're likely to
run into a substantial difference in speed when using frexp/ldexp
would be with decimal -- for either binary or hexadecimal (or octal),
ldexp() and frexp() will usually be pretty simple and fast, though
differences in (or lack of) normalization will have _some_ effect as
well.

--
Later,
Jerry.

== 4 of 5 ==
Date: Sat, Aug 1 2009 4:28 pm
From: Keith H Duggar

On Aug 1, 5:28 pm, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
> In article <8b807dad-e6d5-41d4-8f07-9ffefe91bcc3
> @g6g2000vbr.googlegroups.com>, dug...@alum.mit.edu says...
> > On Aug 1, 10:38 am, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
> > > In article <069cb282-77ec-45c0-bcd6-2aa88e53ec48
> > > @k6g2000yqn.googlegroups.com>, james.ka...@gmail.com says...
> > > > On Jul 31, 6:01 pm, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
> > > > > Whether this will be faster than pow() will depend -- for a
> > > > > lot of cases where the floating point is stored as a
> > > > > significand and a power of two, frexp will be something like a
> > > > > mask, shift and an integer subtraction to remove a bias in the
> > > > > exponent. As you'd expect, ldexp will pretty much reverse
> > > > > that: add the bias, shift to the right position, OR with the
> > > > > significand. Generally pretty fast. OTOH, if the native
> > > > > floating point representation is drastically different from
> > > > > that, they could end up pretty slow -- but machines with such
> > > > > strange floating point representations are pretty unusual.
>
> > > > Not really. I don't know of any mainframe which uses base 2 for
> > > > its floating point: IBM uses base 16, and both Unisys
> > > > architectures use base 8; Unisys MCP also normalizes in a
> > > > somewhat strange way. The fact that the bases are powers of two
> > > > means that the operation can still be done with masking and
> > > > shifting, but it requires a bit more than a base 2
> > > > representation would.
>
> > > You start by saying "not really", but from what I can see, you then
> > > go on to pretty much confirm what I said -- that while these machines
> > > aren't binary, they still work in a power of two, which means that
> > > frexp/ldexp will probably be faster than pow() for all of them.
>
> > You didn't claim anything about systems that "work in a power
> > of two". You specifically made a claim about systems that do not
> > store floating point "as a significand and a power of two".
>
> Obviously you don't even know how to read. What I said was: "if the
> native floating point representation is drastically different from
> that, they could end up pretty slow"

Obviously you don't know how to reasonably interpret what you read.
James' comment wasn't about them being slow or not. It was about your
usual faulty claims about implementations you are ignorant of being
"pretty unusual".

> Since apparently don't know English very well, and are just too
> damned lazy to look it up, "drastically" is defined as: "Extreme,
> severe; Acting rapidly or violently; Extremely severe or extensive"
>
> In case that didn't make it obvious, NOT EVERY POSSIBLE DIFFERENCE IS
> DRASTIC!

That's it, clutch to your "drastically" straw to cover up your faulty
assumptions.

> > The
> > most obvious interpretation of that does not include systems
> > that store as a significand and a power of 8 or 16 etc. Though
> > it is possible your words also meant to include such powers of
> > powers of 2 as well, the operations you sketched for frexp seem
> > to indicate you did not mean to include them. So either James
> > correctly called you on your faulty assumptions and you are
> > backpedaling (as you have done elsewhere), or it was a totally
> > understandable miscommunication.
>
> Nonsense! What I said was that when/if the representation is
> drastically different, that frexp/ldexp might be quite slow. When the
> base isn't binary, but is still a power of two, there's no real
> reason to believe that frexp or ldexp will be particularly slow.
> Specifically, they will almost certainly still be substantially
> faster than pow().

Again, this wasn't about your performance claims it was about your
"pretty usual" claims which you are now trying to link to your vague
"drastically" straw. One must wonder now what "drastic" even means to
you if it is to filter implementations in any meaningful way at all.
Maybe drastic to you means base != 2^n so maybe decimal is "drastic".
Maybe drastic to you means "anything that makes Jerry's performance
claims right". But then who can knows what you meant by such vague
words in a technical context.

> > By the way, are you just going to slither quietly away from the
> > goto debate after you were trounced or are you going to man up
> > and admit goto was faster and that your "analysis" (to use the
> > word extremely loosely) of modern machines that was filled with
> > numerous faulty assumptions (such as the possibility above) was
> > flawed?
>
> There's not "slithering" involved. There was a conscious decision to
> ignore you because you're clearly an liar who simply started making
> up nonsense rather than admitting that he was dead from from
> beginning to end.

LOL, prove it! All the evidence you need should be there: public
code, public timing data, public postings, etc. So back it up!
Demonstrate that I have lied or made something up. So far, about
the only thing you demonstrated in that forum is that you do not
know how to accurately profile, that you speculate wildly beyond
your technical knowledge, that you throw around completely bogus
assumptions about areas you are completely ignorant of (such as
digital geometry), and that when confronted with hard evidence
proving you wrong you either try to quietly slither away or
accuse your opponent of being a "liar".

> > http://groups.google.com/group/comp.lang.c++.moderated/msg/3ac2368e485e740d
> > http://groups.google.com/group/comp.lang.c++.moderated/msg/5d471364e76392d9
>
> > (First link presents hard data proving you wrong and the second
> > calls you out on your flawed understanding and assumptions and
> > challenges you to explain the data or provide new measurements
> > that correct the proven problems in your initial testing.)
>
> All you presented was a bunch of unsupported claims that didn't prove
> anything.

LOL, I think that is the first time I have ever seen someone try
to dismiss source code and timing data as "unsupported claims".
You, on the other hand, provided little beyond personal attacks,
broken profiling, speculation, and lack of comprehension.

> > You know, it really is quite liberating to admit when you are
> > wrong; there is no shame in learning. You should try doing it
> > sometime.
>
> I've done so many times, and when I'm wrong again, I'll do so again.
>
> In this case, you're the one who was wrong, and you're the one who
> has failed to admit it.

The evidence shows otherwise and you know it. That's why you are
ignoring it.

> In this thread, you've not only been wrong, but clearly lied through
> your teeth, not even attempting to quote me accurately at all. At

These "liar" claims are, honestly, truly amusing given how
ridiculous they are.

> least previously you attempted to post your lies in a way that it was
> difficult to prove them wrong.

It fact so far they have been *impossible* for you to prove them
wrong. Probably because they are, in fact, not lies but truths.
It is easy to try; just run the provided test suites and post
your results. That would speak far louder than your bluster.

> Now you're not only lying, but doing
> it in an incredibly STUPID manner that was trivial to prove.
>
> Go away and grow up you pathetic worm!

That's it, keep revealing your nasty disposition.

KHD

== 5 of 5 ==
Date: Sat, Aug 1 2009 4:36 pm
From: Keith H Duggar

On Aug 1, 6:18 pm, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
> In article <069cb282-77ec-45c0-bcd6-2aa88e53ec48
> @k6g2000yqn.googlegroups.com>, james.ka...@gmail.com says...
> > Not really. I don't know of any mainframe which uses base 2 for
> > its floating point: IBM uses base 16, and both Unisys
> > architectures use base 8; Unisys MCP also normalizes in a
> > somewhat strange way. The fact that the bases are powers of two
> > means that the operation can still be done with masking and
> > shifting, but it requires a bit more than a base 2
> > representation would.
>
> Since Kieth decided to jump in with his usual unprovoked and
> inaccurate attack, I decided to do a bit of fact checking.
>
> ...
>
> To summarize, then: current IBM mainframes support floating point in
> three bases: hexadecimal, binary, and decimal. Support for the bases
> was added in that order. Hexadecimal has been supported for decades,
> binary for a decade and a half, and decimal for something like a year
> and a half.
>
> As far as the original question goes, the only time you're likely to
> run into a substantial difference in speed when using frexp/ldexp
> would be with decimal -- for either binary or hexadecimal (or octal),
> ldexp() and frexp() will usually be pretty simple and fast, though
> differences in (or lack of) normalization will have _some_ effect as
> well.

Great. Now tell us whether you 1) consider decimal to be
"drastically" different 2) consider IBM mainframes to be
"pretty usual" 3) knew this about IBM mainframes before
your "Fact checking" wikipeducation trip.

KHD

==============================================================================
TOPIC: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?
http://groups.google.com/group/comp.lang.c++/t/40783f7f814400c9?hl=en
==============================================================================

== 1 of 3 ==
Date: Sat, Aug 1 2009 12:46 pm
From: frankenstein

On Jul 29, 12:14 am, Jon Harrop <j...@ffconsultancy.com> wrote:
> fft1976 wrote:

> If you're using VS then I highly recommend F# for numerical work, largely
> because it makes parallelism so easy.
>
> > Gambit-C Scheme (one of the best of LISPs, IMO): about 2x slower than
> > C (single core only), but you have to work to get within 2x (unlike
> > OCaml), and if you want it fast, it can't be safe (switch controlled).
>
> Bigloo?

Bigloo is a good option for numerical work and sometimes beats my
Fortran F90 code. I am not a Fortran 90 expert but that Bigloo stacks
up well compared to Fortran tells a lot.

Fact #1: We must forget about the language shootout page because it is
and always has been a kinda like of Micky Mouse benchmark (any idot
who thought he might make up for an excellent programmer posted crappy
code and once posted it is forever in google's history and a lot of
other idiots will use the result from the benchmark). RIP language
shotout page.

Fact 2: The performance of Bigloo especillay for larger problems where
your simulations will consume 12 hours and more on processor times and
will use 2GB of associated main memory and more does not come for
free. You will have to program your intended code with this in mind.
HOWEVER, turning Bigloo into a numerical powerhorse for large data
simulations is straightforward:

a) use from the very beginning on *fx, *fl ... native Bigloo operators
(IT IS VERY easy to use them and the compiler will help you out a lot
to spotting type mismatches; however, you won't have to use your gun
as you likely would by using OCaml and shooting yourself to stop the
battling for types).

b) use f32 or f64 arrays (I created my own array class) whenever
possible. especially use f32 for large data simulations since it makes
a whole lot of a difference if your data are half the size in the main
memory in 32-bits mode than as it would be in 64-bits even though
internal calculations are always automatically casted to Bigloo its C
type double.

c) use classes to make code clearer: classes are very fast in Bigloo.

d) whenever you have to read in binary data (note there are some
issues with f32 bits; read Bigloo its mailing list) use or check for
the following undocumented functions and your code will fly: (ieee-
string->double), (ieee-string->float), (double->ieee-string), (float-
>ieee-string), etc.

e) use -Obench option when compiling, -Obench covers more or less all
Bigloo to C related and associated compiler options with speed in mind
(no bound checking etc.).

f) add types to your code to make it readable for others and for your
pleasure to read and understand your own code during your debugging
excercise:

==
(define (add-vector::vector vec1::vector vec2::vector name::bstring
x::bint y::my-class)
(...))
==

I haven't realaesed it yet but I have fully fledged with a whole lot
of bells and whistles bindings to:

- full clapack (linear algebra package converted from Fortran to C by
f2c freely downloadable from the net)
- full DISLIN (high level plotting routine)
- binding to a random number generator
- binding to a mie scattering code
- a matrix class (for creating n dimensional f32 and f64 matrices,
mapping over n-dimensional matrices, pretty printing, slicing, etc.)
which does a fantastic job and is up to the task speed wise.

NOTE: Translating code from an imperative language lets say Fortran to
Bigloo is easy. A lot of Fortran code consists of do loops which
Bigloo you might uses as well:

==
(do ((i 0 (+fx i 1))
((=fx i dim))
(do ... etc.
==

The only issue: Bigloo like C is 0 based and in my case I always think
in row order instead of Fortran column order scheme.

If you don't use Bigloo and recipies and suggestions posted above
Bigloo is dog slow. However, it is really very simple and comes more
or less at no cost to tailor it to a bespoken powerhorse.

Whenever anyone writes a binding for a well respected external C
library which a lot of people might be interested in please make it
public (yes, yes, I for mself haven't done it yet for dislin and
clapack, etc.). In the hope scientists will stop using Micky Mouse
languages like Matlab or Python with is a pain in the ass.

Bigloo also makes available classes for java. However, I have no idea
if this works well or not and if there are people out there who are
using Bigloo in Java for numerical work.

That said: a big question mark: I haven't seen any detailed
descriptions of Bigloo and how to employ threads to use dual-core or
multi processors even in numerical code.

If anone likes to come forward please do so and report of your
experience using Bigloo in a multi processor farm.

Thanks, Rumpelstilzchen

== 2 of 3 ==
Date: Sat, Aug 1 2009 2:56 pm
From: Paul Rubin

frankenstein <klohmuschel@yahoo.de> writes:
> Fact #1: We must forget about the language shootout page because it is
> and always has been a kinda like of Micky Mouse benchmark (any idot
> who thought he might make up for an excellent programmer posted crappy
> code and once posted it is forever in google's history and a lot of
> other idiots will use the result from the benchmark). RIP language
> shotout page.

The shootout is reasonably informative when it's about languages that
have many active practitioners. If someone posts crappy slow code
that makes the language look bad for a while, someone else can come
along and post faster code. So there is ongoing competition between
GHC, Ocaml, C++ and so forth. It's only for the languages with fewer
practitioners (these can still be perfectly good languages) that the
early crappy submissions don't get improved regularly.

== 3 of 3 ==
Date: Sat, Aug 1 2009 4:28 pm
From: Jon Harrop

Paul Rubin wrote:
> frankenstein <klohmuschel@yahoo.de> writes:
>> Fact #1: We must forget about the language shootout page because it is
>> and always has been a kinda like of Micky Mouse benchmark (any idot
>> who thought he might make up for an excellent programmer posted crappy
>> code and once posted it is forever in google's history and a lot of
>> other idiots will use the result from the benchmark). RIP language
>> shotout page.
>
> The shootout is reasonably informative when it's about languages that
> have many active practitioners. If someone posts crappy slow code
> that makes the language look bad for a while, someone else can come
> along and post faster code. So there is ongoing competition between
> GHC, Ocaml, C++ and so forth. It's only for the languages with fewer
> practitioners (these can still be perfectly good languages) that the
> early crappy submissions don't get improved regularly.

No, I contributed dozens of optimized programs to the shootout only to have
them rejected for subjective reasons because the benchmarks are poorly
designed. Some of the benchmarks still on there have "deoptimized by Isaac
Gouy" written in them, for example. Consequently, you cannot draw any
useful conclusions about languages from it.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

==============================================================================
TOPIC: Blog: C++ Code Smells
http://groups.google.com/group/comp.lang.c++/t/1aab587446556099?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Aug 1 2009 3:19 pm
From: pasa

On Aug 1, 10:50 am, legalize+jee...@mail.xmission.com (Richard) wrote:
> <http://legalizeadulthood.wordpress.com/2009/07/30/c-code-smells/>
>
> A recent security bulletin from Microsoft highlights the dangers of
> certain constructs in C++. These constructs constitute a set of code
> smells for C++. In this post, I'll describe what I consider to be C++
> code smells and how to deal with them.

Why not read some books like Effective C++, C++ Gotchas, C++ Coding
Standard, etc instead? Those certainly list your discoveries in the
first couple items, and have a hundred more

== 2 of 2 ==
Date: Sat, Aug 1 2009 6:43 pm
From: Stephen Horne

On Sat, 1 Aug 2009 08:50:02 +0000 (UTC),
legalize+jeeves@mail.xmission.com (Richard) wrote:

>[Please do not mail me a copy of your followup]
>
><http://legalizeadulthood.wordpress.com/2009/07/30/c-code-smells/>
>
>A recent security bulletin from Microsoft highlights the dangers of
>certain constructs in C++. These constructs constitute a set of code
>smells for C++. In this post, I'll describe what I consider to be C++
>code smells and how to deal with them.

Pretty standard pet peaves, and as usual, it's pretty easy to find an
exception or two.

: void *
:
: Typeless pointers, or pointers to void — void *, are vestigal
: leftovers from C++'s compatability with C. If you are calling
: into some API that uses typeless pointers, you should immediately
: wrap that typeless construct into a strongly typed construct.

It's true that void* doesn't belong in a high-level API, but
nevertheless void* is important in low-level code. For example, if
you're writing a container class template, you may want to write it as
a thin wrapper around a type-unsafe data structure library - unless
you want to inflict template bloat on your libraries users.

Note that the low-level data structure library would naturally have an
API that uses typeless pointers, though only a few typesafe wrapper
template libraries should use that API.

"Never write type-unsafe code" is unrealistic in some kinds of
projects. "Restrict type-unsafe code to a few small-as-possible areas"
is much more realistic.

As for the (void) parameter list, true, I don't normally use it, as I
normally code in C++ only these days. But one of the main design
objectives for C++ was interoperability with C, and as the author
notes, in C the situation is different - using () means something
different to (void).

If a header may be #included into a C project, the function
declarations *MUST* use "(void)" for empty parameter lists, and even
for headers that are C++-only, some of the readers may be much more
familiar with C than C++. If your code is read by both C and C++
programmers then it is () which is potentially ambiguous (to human
readers), whereas (void) means the same in both languages and avoids
any possible confusion.

==============================================================================
TOPIC: strcpy vs memcpy
http://groups.google.com/group/comp.lang.c++/t/71a5945deead500c?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 1 2009 6:15 pm
From: "Tech07"

James Kanze wrote:
> On Jul 31, 5:04 pm, Maxim Yegorushkin <maxim.yegorush...@gmail.com>
> wrote:
>> Pallav singh wrote:
>>> when we should use strcpy( ) and when memcpy( ) ? is it w.r.t. to
>>> Data Type
>
>> It is quite easy: when you know the length of the source
>> string use memcpy(), otherwise strlcpy().
>
> There is no strlcpy in C or C++. There is a proposal for a TR
> to C with asafe strcpy_s, but for the moment, it's just a
> proposal, and at any rate, it will be a TR, and not part of the
> language (so I don't know what C++ will do with it). FWIW: it's
> implemented in VC++ (at least with the compiler options I use),
> but not in g++ under Linux (again, with the compiler options I
> usually use).

That's all maintenance stuff, who cares. Old people bothering young people
with their baggage. Sigh.

==============================================================================
TOPIC: static inline functions - possible?
http://groups.google.com/group/comp.lang.c++/t/0386357e12bd0064?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 1 2009 6:53 pm
From: Stephen Horne

On Fri, 31 Jul 2009 12:08:45 GMT, Juha Nieminen
<nospam@thanks.invalid> wrote:

>Balog Pal wrote:
>> With member functions you rarely spell "inline", as just defining the
>> function within the class makes it inline implicitly. And you must include
>> the definition of functions just as the definition of the class, so
>> separation here brings little more pain than just doing the definitions
>> right at the place.
>
> It's a question of style, but many people prefer separating the
>declaration of a class from the implementation of its inline functions,
>to keep the header tidy and clean. (After all, the class declaration
>often doubles as a kind of "reference manual" to the usage of the class,
>especially in the lack of better documentation, or if the documentation
>is impractical to read.)

Me included - a habit formed in languages like Modula 2 and Ada, and
an objection I have to some other languages. Even if your editor can
do "folding", can you assume that everyone elses can? And what about
printed listings?

Then again, there's always Doxygen.

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

== 1 of 1 ==
Date: Sat, Aug 1 2009 7:31 pm
From: Rafael Anschau

Here´s my take on it:

In school you learn that things have to be almost perfect
to get a good grade, even if takes two months to do it.

Then you move to the busyness world where things have to be
ready for yesterday, and as long as they work, it doesn´t mater
if they are inefficient, patchy, bloated and ugly. Bosses(clients,
internal or external)
prefer a bad working code today, than a perfect one in two months.

This often takes time to be accepted by some(it surely took for me,
and I don´t
fully yet accept that yet, but it´s slowly sinking in).

Another problem maybe in the communication:

I think the best way is to communicate in terms of problem/time/
suggestions/restrictions. 'I have
this problem that I need solved for a week. My suggestion is that you
use this, this
and this but if you can think up something, better go ahead. Oh there
´s also this
and this restriction"

But by all, means don´t behave like "I need a facade pattern"(who
knows he may think of something better!why would that ever be a
restriction ?) using this this this and this. And variables and
commentaries should be in this style."
(Go ahead pawn!)

Developers like to use their brains, and not just be the hands and
legs of someone
else´s brains.

Someone sayed: "Trying to manage programmers is like trying to herd
cats"

Have you ever tried to use Scrumm ? I think it´s a quality methodology
that suits your problem very well.

Good luck.

Rafael

==============================================================================
TOPIC: ◆⊙→Www.toptradea.com Best mobile phones supplier Hot sale Nokia,8800
arte,8600,6300,5800,6500,E series E71,E66,E75, N seies N97,N96,N95,N86,N85,N81,
N79,N78,N72 //Our policy: order 1-3pce brand mobile with a free polo Tshirt
http://groups.google.com/group/comp.lang.c++/t/e81307217ccf57d1?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 1 2009 7:32 pm
From: "www.toptradea.com Toptradea"

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

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

Saturday, August 1, 2009

comp.lang.c++ - 26 new messages in 13 topics - digest

No comments:

Blog Archive

About Me