http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* ｡◕‿◕｡ 2009 HOT Sale ED Hardy Long Sleeve, G-star Long Sleeve, LV Long Sleeve
ect at www.fjrjtrade.com <Paypal Payment> - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/61bc29d3f5c39e34?hl=en
* Outlandish Particle Periodic Table update IX - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/5dd95a70782d96e3?hl=en
* Discount Chanel Shoes,LV shoes,D&G Shoes,Puma Shoes,Versace Boots,Dsquared
shoes,Gucci Shoes (www.vipchinatrade.com) - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/49e551275db72b81?hl=en
* C++ jobs down another 40% - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/6718a9cd2f3ecdbf?hl=en
* Interfacing C++ and assembler code - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/79272d2bf39c62ec?hl=en
* numeric_limits<>::max() - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/b7edfd57e70fae1a?hl=en
* Different types of cast - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/b5b881bc79379355?hl=en
* String not printing data on next line despite \n in the string - 1 messages,
1 author
http://groups.google.com/group/comp.lang.c++/t/35658d761ffe5130?hl=en
* workaround for auto_ptr<> in STL containers? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/ea539aaeae39cd19?hl=en
* Exception Misconceptions: Exceptions are for unrecoverable errors. - 2
messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/786cfdf0ab25866d?hl=en
* Saving a binary file into a string - 3 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/ddc89ddf30293133?hl=en
* "Reusable" operator overloading for enum? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/981ab2c7a0c2c5ff?hl=en
* Design patterns - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/c99eb0b17c6ad648?hl=en
* Event dispatcher, hooks and Interceptor pattern for C++? - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/a82e5c39e2fe1f12?hl=en
* 123 - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/df6ba3af9ed2fc11?hl=en
==============================================================================
TOPIC: ｡◕‿◕｡ 2009 HOT Sale ED Hardy Long Sleeve, G-star Long Sleeve, LV Long
Sleeve ect at www.fjrjtrade.com <Paypal Payment>
http://groups.google.com/group/comp.lang.c++/t/61bc29d3f5c39e34?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Dec 28 2009 8:04 am
From: "www.fjrjtrade.com"
｡◕‿◕｡ 2009 HOT Sale ED Hardy Long Sleeve, G-star Long Sleeve, LV Long
Sleeve ect at www.fjrjtrade.com <Paypal Payment>
Cheap wholesale Long Sleeve www.fjrjtrade.com
Cheap wholesale Long Sleeve
http://www.fjrjtrade.com/840-Long-Sleeve.html
Cheap wholesale Armani Long Sleeve
http://www.fjrjtrade.com/1916-Armani-Long-Sleeve.html
Cheap wholesale G-STAR Long Sleeve
http://www.fjrjtrade.com/1915-G-STAR-Long-Sleeve.html
Cheap wholesale A&F Long Sleeve
http://www.fjrjtrade.com/841-AF-Long-Sleeve.html
Cheap wholesale A&F Man Long Sleeve
http://www.fjrjtrade.com/842-AF-Man-Long-Sleeve.html
Cheap wholesale A&F Long Sleeve Women
http://www.fjrjtrade.com/2114-AF-Long-Sleeve-Women.html
Cheap wholesale Christan Audigier Long Sleeve
http://www.fjrjtrade.com/845-Christan-Audigier-Long-Sleeve.html
Cheap wholesale Christan Audigier Man Long Sleeve
http://www.fjrjtrade.com/846-Christan-Audigier-Man-Long-Sleeve.html
Cheap wholesale Christan Audigier Women Long Sleeve
http://www.fjrjtrade.com/847-Christan-Audigier-Women-Long-Sleeve.html
Cheap wholesale D&G Man Long Sleeve
http://www.fjrjtrade.com/849-DG-Man-Long-Sleeve.html
Cheap wholesale Ecko Long Sleeve
http://www.fjrjtrade.com/2115-Ecko-Long-Sleeve.html
Cheap wholesale ED Hardy Long Sleeve
http://www.fjrjtrade.com/850-ED-Hardy-Long-Sleeve.html
Cheap wholesale ED Hardy Man Long Sleeve
http://www.fjrjtrade.com/851-ED-Hardy-Man-Long-Sleeve.html
Cheap wholesale ED Hardy Women Long Sleeve
http://www.fjrjtrade.com/852-ED-Hardy-Women-Long-Sleeve.html
Cheap wholesale Gucci Long Sleeve
http://www.fjrjtrade.com/2116-Gucci-Long-Sleeve.html
Cheap wholesale Lacoste Long Sleeve
http://www.fjrjtrade.com/2117-Lacoste-Long-Sleeve.html
Cheap wholesale LV Long Sleeve
http://www.fjrjtrade.com/2118-LV-Long-Sleeve.html
Cheap wholesale Nike Long Sleeve
http://www.fjrjtrade.com/2119-Nike-Long-Sleeve.html
Cheap wholesale Ralph Lauren POLO Long Sleeve
http://www.fjrjtrade.com/2120-Ralph-Lauren-POLO-Long-Sleeve.html
More details at website:
http://www.fjrjtrade.com
==============================================================================
TOPIC: Outlandish Particle Periodic Table update IX
http://groups.google.com/group/comp.lang.c++/t/5dd95a70782d96e3?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Dec 28 2009 8:04 am
From: Tony Lance
Big Bertha Thing outlandish
OUTLANDISH PARTICLE PERIODIC TABLE
By Tony Lance Dip.Math(Open) 19th December 2009
Update IX from http://www.tonylance.talktalk.net/structur.html
.510998902 1.0D-09 1 1 80305 1 3224486665 1.0 SLC
For full table see link:-
http://www.tonylance.talktalk.net/aspire.html
username outlandish
password spirebell
Thany you
Tony Lance
tonylance@myinternetuk.com
==============================================================================
TOPIC: Discount Chanel Shoes,LV shoes,D&G Shoes,Puma Shoes,Versace Boots,
Dsquared shoes,Gucci Shoes (www.vipchinatrade.com)
http://groups.google.com/group/comp.lang.c++/t/49e551275db72b81?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Dec 28 2009 9:13 am
From: tradeyoyo
Cheap Wholesale Gucci Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale GUCCI Boots
Cheap Wholesale Lacoste Shoes
Cheap Wholesale LV Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale LV Boots
Cheap Wholesale Prada Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Timberland Shoes
Cheap Wholesale D&G Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale D&G Boots
Cheap Wholesale Puma Shoes
Cheap Wholesale Puma AAA (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale UGG Boots Shoes
Cheap Wholesale Bikkem Bergs Shoes (free shipping)
Cheap Wholesale Mauri Shoes Man
Cheap Wholesale Versace Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Versace Boots
Cheap Wholesale Paul Smith Shoes (free shipping)
Cheap Wholesale BOSS Shoes
Cheap Wholesale Burberry Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Dsquared shoes
Cheap Wholesale Dior Shoes (free shipping)
Cheap Wholesale Dior Boots
Cheap Wholesale ED Hardy Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale ED Hardy Boots
Cheap Wholesale ED Hardy Shoes Man (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Fendi Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Fendi Boots
Cheap Wholesale AFF Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Evisu Shoes (free shipping)
Cheap Wholesale 4US Shoes
Cheap Wholesale Sebago Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Supra Shoes
Cheap Wholesale Hight Converse Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Coach Boots
Cheap Wholesale Coach Shoes
Women Christian Louboutin (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Chanel Shoes
Cheap Wholesale Chanel Boots (free shipping)
Cheap Wholesale Bape Shoes
Cheap Wholesale Adidas Shoes (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Adicolor (free shipping)
Cheap Wholesale Adidas 35TH (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Adidas NBA
Cheap Wholesale Adidas Running (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Adidas Y3
Cheap Wholesale Soccer Shoes (paypal payment)
(www.vipchinatrade.com )
==============================================================================
TOPIC: C++ jobs down another 40%
http://groups.google.com/group/comp.lang.c++/t/6718a9cd2f3ecdbf?hl=en
==============================================================================
== 1 of 2 ==
Date: Mon, Dec 28 2009 9:16 am
From: "Bo Persson"
BGB / cr88192 wrote:
> "Bo Persson" <bop@gmb.dk> wrote in message
> news:7pouahFmkjU1@mid.individual.net...
>> io_x wrote:
>>> "tanix" <tanix@mongo.net> ha scritto nel messaggio
>>> news:hh6heo$2lo$1@news.eternal-september.org...
>>>> In article <hh66vr$scn$1@news.albasani.net>, "BGB / cr88192"
>>>> <cr88192@hotmail.com> wrote:
>>> bla bla bla
>>>
>>> again
>>> one general language
>>> 1) using a portable thypes
>>> eg u8 == unsigned 32 bits
>>> u32== unsigned 32 bits
>>> i32== int 32 bits
>>> etc and operation on them
>>> 2) eliminate all the undefinited behaviour on the languages
>>> --------------------
>>> 1) or use one PC virtual machine (all x86 + hardware of one pc,
>>> all virtual) that rapresent x86 PC and whatever you want: eg
>>> compiler etc and install that in each machine even if have
>>> different cpu and hardware
>>
>> Nothing stops you from writing code that is limited to x86
>> machines. Specifying the language as x86 only, stops these guys
>> from using
>> it: http://www-03.ibm.com/systems/z/
>>
>>
>> Hardly a great idea!
>>
>
> yeah, x86 only is pretty weak...
>
> even with x86 only, there is still 32 vs 64 bit x86, which creates
> all sorts of troubles...
>
> using 32-bit x86 and either interpreting or JIT'ing it, is a little
> better, but still kind of a nasty option...
>
> however, doing some of the code in 32-bit x86 and JIT'ing it for
> the 64-bit case has been something I had been considering, even if
> it is nasty...
>
> MSIL / CIL is possibly a little better option, but CIL is a big and
> complicated format.
> JBC (Java ByteCode) is also available, but JBC is hardly
> general-purpose (can't really do C, ...).
>
And it also needs a hardware assist to run Java properly on the
mainframes. :-)
http://www-03.ibm.com/systems/z/advantages/zaap/index.html
Using the "implementation defined" loopholes in the C++ standard, C++
runs natively on these machines.
Bo Persson
== 2 of 2 ==
Date: Mon, Dec 28 2009 3:12 pm
From: "BGB / cr88192"
"Bo Persson" <bop@gmb.dk> wrote in message
news:7ps7faFo0qU1@mid.individual.net...
> BGB / cr88192 wrote:
>> "Bo Persson" <bop@gmb.dk> wrote in message
>> news:7pouahFmkjU1@mid.individual.net...
>>> io_x wrote:
>>>> "tanix" <tanix@mongo.net> ha scritto nel messaggio
>>>> news:hh6heo$2lo$1@news.eternal-september.org...
>>>>> In article <hh66vr$scn$1@news.albasani.net>, "BGB / cr88192"
>>>>> <cr88192@hotmail.com> wrote:
>>>> bla bla bla
>>>>
>>>> again
>>>> one general language
>>>> 1) using a portable thypes
>>>> eg u8 == unsigned 32 bits
>>>> u32== unsigned 32 bits
>>>> i32== int 32 bits
>>>> etc and operation on them
>>>> 2) eliminate all the undefinited behaviour on the languages
>>>> --------------------
>>>> 1) or use one PC virtual machine (all x86 + hardware of one pc,
>>>> all virtual) that rapresent x86 PC and whatever you want: eg
>>>> compiler etc and install that in each machine even if have
>>>> different cpu and hardware
>>>
>>> Nothing stops you from writing code that is limited to x86
>>> machines. Specifying the language as x86 only, stops these guys from
>>> using
>>> it: http://www-03.ibm.com/systems/z/
>>>
>>>
>>> Hardly a great idea!
>>>
>>
>> yeah, x86 only is pretty weak...
>>
>> even with x86 only, there is still 32 vs 64 bit x86, which creates
>> all sorts of troubles...
>>
>> using 32-bit x86 and either interpreting or JIT'ing it, is a little
>> better, but still kind of a nasty option...
>>
>> however, doing some of the code in 32-bit x86 and JIT'ing it for
>> the 64-bit case has been something I had been considering, even if
>> it is nasty...
>>
>> MSIL / CIL is possibly a little better option, but CIL is a big and
>> complicated format.
>> JBC (Java ByteCode) is also available, but JBC is hardly
>> general-purpose (can't really do C, ...).
>>
>
> And it also needs a hardware assist to run Java properly on the
> mainframes. :-)
>
> http://www-03.ibm.com/systems/z/advantages/zaap/index.html
>
can't say I know much about IBM's technology...
>
> Using the "implementation defined" loopholes in the C++ standard, C++ runs
> natively on these machines.
>
C and C++ run natively on lots of machines, likely due, in part, to the
language being "flexible" in order to bend to some extent to whatever HW it
is running on, whereas the JVM is very specific and assumes that all code
should run "about the same".
for example, one may note when implementing a JIT for JBC, there are a few
edge cases where the bytecode assumes 32-bit memory spots (for both the
locals and the stack), and it requires a bit of ugly hackery to work around
these (for example, if JIT'ing on a 64-bit processor, or converting the
bytecode into an SSA-like form, ...).
in this case, it would have been better had the bytecode been working with
abstract "stack items".
well, that and the lack of type declaration for local variables, ... (one
has to instead figure out the type of a variable via the operations applied
to it, ...).
then again, it is far less nasty than x86 would be, and still much simpler
than MSIL (even if MSIL is cleaner in a few ways).
>
>
> Bo Persson
>
>
==============================================================================
TOPIC: Interfacing C++ and assembler code
http://groups.google.com/group/comp.lang.c++/t/79272d2bf39c62ec?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Dec 28 2009 9:24 am
From: "Bo Persson"
Jorgen Grahn wrote:
> On Sat, 2009-12-26, Branimir Maksimovic wrote:
> ...
>> This is implementation of my Window class, I think, everything is
>> clear here, how you can do it in win32, unfortunately microsoft
>> has banned assembler from 64 bit environment there you can only
>> write separate assembler modules:
>
> I don't do Win32 programming, but your example makes it reasonably
> clear that they did *not* ban assembly; they simply removed the C++
> extensions for inline assembly from their compiler. Some would say
> that was a wise choice.
>
Yes, most of the "interesting" instructions are available as compiler
intrinsics, so you can still use them.
Mixing a few assembly instructions in the middle of a C or C++
function tended to disturb the optimizer so that the surrounding code
was less well optimized. That took away most of the advantage of using
assembly to gain extra speed, so any performance bottlenecks would
generally have to be coded separately anyway.
Bo Persson
==============================================================================
TOPIC: numeric_limits<>::max()
http://groups.google.com/group/comp.lang.c++/t/b7edfd57e70fae1a?hl=en
==============================================================================
== 1 of 2 ==
Date: Mon, Dec 28 2009 9:41 am
From: "Bo Persson"
Victor Bazarov wrote:
> Rolf Magnus wrote:
>> I'd like to know why std::numeric_limits<>::max (and some, but not
>> all other values in numeric_limits) was chosen to be a function
>> instead of just being a constant.
>
> You should post to 'comp.std.c++' then. There decisions and the
> rationales behind the Standard and any of its parts are discussed.
> Some folks *here* might remember how those things (functions) came
> to be functions, of course, but 'c.s.c++' is more reliable.
I believe it was because the floating point values could not be const
static members initialized in the class definition. So it was
considered more consistent to make them all functions. That way, at
least they could be inlined.
>
>> I would have needed it in a template argument, but can't use it
>> there, because it's not a constant expression.
It doesn't help you here, but in C++0x the members of numeric_limits
will be declared constexpr, to make them usable as constant
expressions, even though they remain functions. A new language
feature!
Bo Persson
== 2 of 2 ==
Date: Mon, Dec 28 2009 1:16 pm
From: James Kanze
On Dec 28, 5:41 pm, "Bo Persson" <b...@gmb.dk> wrote:
> Victor Bazarov wrote:
> > Rolf Magnus wrote:
> >> I'd like to know why std::numeric_limits<>::max (and some,
> >> but not all other values in numeric_limits) was chosen to
> >> be a function instead of just being a constant.
> > You should post to 'comp.std.c++' then. There decisions and
> > the rationales behind the Standard and any of its parts are
> > discussed. Some folks *here* might remember how those
> > things (functions) came to be functions, of course, but
> > 'c.s.c++' is more reliable.
> I believe it was because the floating point values could not
> be const static members initialized in the class definition.
> So it was considered more consistent to make them all
> functions.
They have to all be functions, or none, or you can't very easily
use the value in a template.
--
James Kanze
==============================================================================
TOPIC: Different types of cast
http://groups.google.com/group/comp.lang.c++/t/b5b881bc79379355?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Dec 28 2009 11:11 am
From: "Johannes Schaub (litb)"
Johannes Schaub (litb) wrote:
> James Kanze wrote:
>
>> On Dec 24, 4:39 pm, "Johannes Schaub (litb)" <schaub-johan...@web.de>
>> wrote:
>>> Ian Collins wrote:
>>> > Tomislav Novak wrote:
>>> >> On 2009-12-24, Christof Warlich <cwarl...@gmx.de> wrote:
>> [...]
>>> >>> reinterpret_cast allows any cast.
>>
>>> >> Of course, it works for pointer types only (just to clarify further).
>>
>>> > No, it works for any type with the same size. But it can't
>>> > be used to cast away const or volatile.
>>
>>> No, you are wrong. reinterpret_cast only allows very limited
>>> And it does not allow casting to void* from another pointer,
>>> or from void* to another pointer.
>>
>> Yes it does. It allows converting any object pointer type to
>> any other object pointer type (and in this context, void* is
>> considered an object type). Even if the two pointers have
>> different sizes, e.g. void* and int* on some machines. It also
>> allows converting any pointer to function type to any other
>> pointer to function type; it does not, however, allow converting
>> pointer to object (including void*) to or from pointer to
>> function, even if the two have the same size, as if often the
>> case (and is required by Posix, and I think at least indirectly
>> by Windows). Note that quite a few Unix compilers err here, and
>> accept the cast.
>>
>
> void* is not a "pointer to an object" - it's a "pointer to void". The
> reinterpret_cast paragraph precisely only allows casting for two pointers
> if both are pointers to object types. There is no mentioning of void
> types.
>
> The pointer type category is defined at 3.9.2/1 as "pointers to void or
> objects or functions (including static members of classes) of a given
> type", they are three different categories.
>
> There was some work under way to define the word "object pointer" and use
> it in reinterpret_cast to include "pointer to void" - but this work has
> not yet been included into any draft. See http://www.open-
> std.org/jtc1/sc22/wg21/docs/cwg_active.html#573
>
Actually the current draft n3000 uses reinterpret_cast<void*>(P) in the
specification of safely-derived pointers at 3.7.3.4/3 - so i think it's
actually needed to include the above "object pointer" fix, or something
similar, into the final C++0x Standard.
==============================================================================
TOPIC: String not printing data on next line despite \n in the string
http://groups.google.com/group/comp.lang.c++/t/35658d761ffe5130?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Dec 28 2009 12:03 pm
From: James Kanze
On Dec 26, 9:35 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
> Paavo Helde wrote:
> >> (not wanting to make debate here, but there are reasons to
> >> choose one or another in different contexts, many not
> >> particularly relevant to the language as seen/written by
> >> humans, and many not related to the "majority" of
> >> projects).
> > I cannot see any reason to knowingly leave a potential UB
> > bug in the program. God knows there are many of them already
> > left unknowingly, no reason to add one!
> Hm, microsoft had practice to allow write in deallocated
> memory in order for some important applications to work on
> windows.
In the earliest versions of C (pre-standard), the rule was that
the pointer to realloc had to be the last pointer that was
freed. In those days, it was considered acceptable to use freed
memory up until the next call to malloc.
In those days, of course, there was no multithreading, and
programs weren't connected to the internet.
> I don;t see how this is problem.
Using a dangling pointer is a serious security hole.
--
James Kanze
==============================================================================
TOPIC: workaround for auto_ptr<> in STL containers?
http://groups.google.com/group/comp.lang.c++/t/ea539aaeae39cd19?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Dec 28 2009 12:14 pm
From: James Kanze
On Dec 28, 9:35 am, Michael Doubez <michael.dou...@free.fr> wrote:
> On 25 déc, 13:40, James Kanze <james.ka...@gmail.com> wrote:
> > On Dec 24, 8:34 am, Michael Doubez <michael.dou...@free.fr> wrote:
> > > On 23 déc, 20:07, Christof Warlich <cwarl...@gmx.de> wrote:
[...]
> > That, of course, is the question. In the case of a lot of
> > GUI objects, lifetime is in some way related to the display.
> > Destruction should occur when the containing display object
> > is disposed of, and ceases to become displayable. It's a
> > design issue (since destruction could in some cases result
> > in concrete actions occuring; the object deregistering
> > itself for mouse events, for example).
> > Whether this is "difficult" is a matter open to discussion,
> > but it's an aspect that has to be addressed, at the design
> > level. (I see a containment hierarchy -- containment being
> > used here in its everyday sense, and not the OO sense. And
> > I can't see where the difficulty would come from.)
> > > > Thus, I considered using std::auto_ptr<> to overcome
> > > > this, but auto_ptr<> does not seem to be compatible with
> > > > STL containers, where I want to keep my shapes in some
> > > > sort of list.
> > auto_ptr also doesn't have the required semantics.
> > > > Any ideas how this (i.e. auto-deletion of unreferenced
> > > > objects) could be handled in a generic way while using
> > > > STL containers?
> > > How do you known you should auto-delete them ? They could
> > > be on the stack.
> > That's a question of the class' semantics. I think it
> > reasonable to forbid GUI types from being on the stack.
> Yes.
> The underlying question was "how do you know that auto_ptr<>
> would have been a alternative ?"
> If a container of auto_ptr<> (such has a list<> rather than a
> vector<>) had been an alternative, it only means the lifetime
> of the object would have been tied to the lifetime of the
> container (or its presence in the container). If that's the
> case, I don't see from where the "complex case" come from.
I'm beginning to loose a little bit of context here. But off
hand: a (standard) container doesn't own objects it points to;
that's not part of its semantics. In a GUI, it is a reasonable
design for the containing element (panel, etc.) to own the
elements it contains, however, and using a standard container of
boost::shared_ptr is one way of achieving this. A bit
misleading, possibly, since "shared_ptr" suggests shared
ownership, but not to a point that a simple comment couldn't
correct the impression. It does result in a somewhat strange
idiom for shared_ptr, in that you don't allow shared_ptr to
escape the containing element (calling get() and returing a raw
pointer if you want to return a pointer to a contained element),
but technically, it works: the semantics of containment pretty
much guarantee the absence of cycles, for example.
--
James Kanze
==============================================================================
TOPIC: Exception Misconceptions: Exceptions are for unrecoverable errors.
http://groups.google.com/group/comp.lang.c++/t/786cfdf0ab25866d?hl=en
==============================================================================
== 1 of 2 ==
Date: Mon, Dec 28 2009 12:31 pm
From: James Kanze
On Dec 27, 2:32 pm, "Balog Pal" <p...@lib.hu> wrote:
> "James Kanze" <james.ka...@gmail.com>
> >> So you use the same tech -- the destructor sits there to
> >> carry out the responsibility that is left over.
> > There is a similarity: additional actions may be needed when
> > an exception has been thrown. But the word "resource" (or
> > even "responibility") seems too limiting. I prefer talking
> > in terms of program coherence (in which invariants are
> > maintained): the coalition takes place in the other sense:
> > when the program is coherent, for example, no one holds a
> > mutex lock, or other resources that won't be used.
> Hm, to me that is what sounds strange. To me mutex locking
> means a ctirical section of code, and has nothing to do with
> invariants or coherence.
Well, I won't insist on it; I don't generally think of it in
terms of program coherence either. But I do remember reading
(by someone who I respect, but I've forgotten who) that you
could consider whether the mutex is locked or not part of the
program state (it certainly is, when it comes down to it), and
the "coherent state", or the program invariant (which you may
violate temporarily, but only provided you return to a "coherent
state" later) is that all mutex's are unlocked.
It's certainly a possible point of view. I won't go much beyond
that.
> And invariant means something that holds. And supposed to. It
> may be broken for some special technical reason (like not
> having atomic multi-assign), but it better be avoided.
As you said, it may be broken for some special technical reason,
within a single operation. In Eiffel, I believe, invariants are
checked when a call is entered from outside the object, and
again when you return from that call; they are not checked when
calling within the obect. Translated to C++, that would mean
that the invariants must hold when you call a public function,
and when you return from that function, but they may be broken
(temporarily) when you are in the function.
That's the standard definition of "class invariant" that I know
from programming by contract. Extending it to include program
state, of course (as opposed to simply class invariants) is
perhaps a bit risky, and I'd certainly be more adverse to
breaking program invariants (accross classes). But again, it's
all a question of point of view.
> While critical sections are totally meant to be entered, and
> perfectly natural.
It's also perfectly natural to temporarily violate class
invariants within a member function. At least, it has been
traditionally held to be so.
[...]
> > The swap idiom is just a fairly simple way of
> > expressing it in C++ (and letting destructors handle the
> > clean-up in both the error cases and the normal case). But if
> > you're interested, an analysis of the constructor code for
> > boost::shared_ptr is illuminating; doing things correctly
> > requires some thought.
> I did study that constructor when it was a new thing (guess
> like a decade ago), and it was definitely illuminating. IIRC
> it was before Herb's Exceptional... books, and the Abrahams
> guarantees were either in the future or new stuff.
> By today the scene hopefully is different, that material is
> considered fundamental for a long time. And have high
> attention in interviews for a C++ position and code reviews.
But boost::shared_ptr remains illuminating, because of its
particular post conditions: the object will be deleted
(guaranteed) as soon as there are no boost::shared_ptr referring
to it. Which means that if construction of the
boost::shared_ptr can fail (and it can), then there will be no
boost::shared_ptr pointing to it, and the object it points to
will be deleted.
[...]
> > Defining clearly what pointers have to be freed, when. In
> > general, the implementation doesn't require much effort,
> > once you've defined clearly what has to be done.
> In normal cases we want to avoid that very problem.
Then use garbage collection:-). But in practice, even with
garbage collection, you can't simply ignore the lifetime of an
object. Or at least, not of all objects. (It is your design
which must decide which objects can be ignored, with regards to
lifetime. And in my experience, those are often value objects,
which you generally won't allocate on the stack anyway.)
--
James Kanze
== 2 of 2 ==
Date: Mon, Dec 28 2009 1:25 pm
From: tanix@mongo.net (tanix)
Watch the thread Subject header.
You are still talking on one of those atrophied threads.
Modify subject to this one to keep it all on one thread when you respond.
Re: Exception Misconceptions: Exceptions are for unrecoverable errors.
In article
<c0fa711c-b84d-41b3-9887-b05ec9231699@m25g2000yqc.googlegroups.com>, James
Kanze <james.kanze@gmail.com> wrote:
>On Dec 27, 2:32 pm, "Balog Pal" <p...@lib.hu> wrote:
>> "James Kanze" <james.ka...@gmail.com>
>
>> >> So you use the same tech -- the destructor sits there to
>> >> carry out the responsibility that is left over.
>
>> > There is a similarity: additional actions may be needed when
>> > an exception has been thrown. But the word "resource" (or
>> > even "responibility") seems too limiting. I prefer talking
>> > in terms of program coherence (in which invariants are
>> > maintained): the coalition takes place in the other sense:
>> > when the program is coherent, for example, no one holds a
>> > mutex lock, or other resources that won't be used.
>
>> Hm, to me that is what sounds strange. To me mutex locking
>> means a ctirical section of code, and has nothing to do with
>> invariants or coherence.
>
>Well, I won't insist on it; I don't generally think of it in
>terms of program coherence either. But I do remember reading
>(by someone who I respect, but I've forgotten who) that you
>could consider whether the mutex is locked or not part of the
>program state (it certainly is, when it comes down to it), and
>the "coherent state", or the program invariant (which you may
>violate temporarily, but only provided you return to a "coherent
>state" later) is that all mutex's are unlocked.
>
>It's certainly a possible point of view. I won't go much beyond
>that.
>
>> And invariant means something that holds. And supposed to. It
>> may be broken for some special technical reason (like not
>> having atomic multi-assign), but it better be avoided.
>
>As you said, it may be broken for some special technical reason,
>within a single operation. In Eiffel, I believe, invariants are
>checked when a call is entered from outside the object, and
>again when you return from that call; they are not checked when
>calling within the obect. Translated to C++, that would mean
>that the invariants must hold when you call a public function,
>and when you return from that function, but they may be broken
>(temporarily) when you are in the function.
>
>That's the standard definition of "class invariant" that I know
>from programming by contract. Extending it to include program
>state, of course (as opposed to simply class invariants) is
>perhaps a bit risky, and I'd certainly be more adverse to
>breaking program invariants (accross classes). But again, it's
>all a question of point of view.
>
>> While critical sections are totally meant to be entered, and
>> perfectly natural.
>
>It's also perfectly natural to temporarily violate class
>invariants within a member function. At least, it has been
>traditionally held to be so.
>
> [...]
>> > The swap idiom is just a fairly simple way of
>> > expressing it in C++ (and letting destructors handle the
>> > clean-up in both the error cases and the normal case). But if
>> > you're interested, an analysis of the constructor code for
>> > boost::shared_ptr is illuminating; doing things correctly
>> > requires some thought.
>
>> I did study that constructor when it was a new thing (guess
>> like a decade ago), and it was definitely illuminating. IIRC
>> it was before Herb's Exceptional... books, and the Abrahams
>> guarantees were either in the future or new stuff.
>
>> By today the scene hopefully is different, that material is
>> considered fundamental for a long time. And have high
>> attention in interviews for a C++ position and code reviews.
>
>But boost::shared_ptr remains illuminating, because of its
>particular post conditions: the object will be deleted
>(guaranteed) as soon as there are no boost::shared_ptr referring
>to it. Which means that if construction of the
>boost::shared_ptr can fail (and it can), then there will be no
>boost::shared_ptr pointing to it, and the object it points to
>will be deleted.
>
> [...]
>> > Defining clearly what pointers have to be freed, when. In
>> > general, the implementation doesn't require much effort,
>> > once you've defined clearly what has to be done.
>
>> In normal cases we want to avoid that very problem.
>
>Then use garbage collection:-). But in practice, even with
>garbage collection, you can't simply ignore the lifetime of an
>object. Or at least, not of all objects. (It is your design
>which must decide which objects can be ignored, with regards to
>lifetime. And in my experience, those are often value objects,
>which you generally won't allocate on the stack anyway.)
>
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
==============================================================================
TOPIC: Saving a binary file into a string
http://groups.google.com/group/comp.lang.c++/t/ddc89ddf30293133?hl=en
==============================================================================
== 1 of 3 ==
Date: Mon, Dec 28 2009 12:53 pm
From: James Kanze
On Dec 27, 3:39 pm, Dominik Schmidt <dominikschmi...@gmx.net> wrote:
> I'm new to C++, so I have a very basic question.
> I wrote a function which opens a file and saves it into a
> string variable. Another function can save a string variable
> into a file. I tried to combine those two functions, because
> in combination they should make an exact copy of a file. And
> it seems to work, in every case the copy had the exact same
> hash value (MD5) as the original file.
> I'd like to know if I made an error, so if there's any
> possibility that my functions won't work in some case?
The question is: how portable do you want to be?
> Just to be sure: 1 Byte can have 2^8 = 256 different states,
> so each "character" of a string variable can have those 256
> states, right?
On most machines. (I know of at least one where bytes have 9
bits, and 512 possible states. And more than one where a signed
char would have 2^n-1 possible states, rather than 2^n; but on
all of those machines, plain char is unsigned---probably in
order to avoid such problems.)
> Every byte of a file can be saved in a string variable?
Yes. Getting it from the file into the string variable isn't
necessarily trivial, however. In fact, it's impossible to do
"portably", if by portably, you mean for all legal
implementations of C++.
For this sort of thing, I'd generally prefer vector< char >, but
string will work too.
> If this is true, there can be no file which can *not* be
> copied by my functions (except it's too big)?
> ================
> Here is my code:
> ================
> int main()
> {
> string var1;
> var1 = OpenFile("D:\\myfile1.bin");
> SaveFile("D:\\myfile1-copy.bin", var1);
> return 0;
Not related to your question, but if either OpenFile or SaveFile
fails, you shouldn't return 0.
> }
> string OpenFile(string FilePath)
> {
> string Out1;
> ifstream file1;
> char Chr1;
> string Str1;
> long long filesize;
Strictly speaking, long long isn't portable (yet). Also
strictly speaking, it may not be large enough to hold the size
of a file (but practically, I can't imagine this being a problem
anytime soon).
> filesize = GetFileSize(FilePath);
> file1.open (FilePath.c_str(), ios::binary);
> if (file1.is_open())
> {
> for (long long i = 0; i < filesize; i++)
> {
> file1.read (&Chr1, 1);
> Str1 = Chr1;
> Attach (&Out1, Str1);
> }
> }
> file1.close ();
All of which is doing things the hard way. Why not simply:
char tmp;
while ( file1.get( tmp ) )
Out1 += tmp;
if ( !file1.eof() )
// read error...
(once you've verified that the open has succeeded, of course)?
Or even:
string Out1( (std::istreambuf_iterator< char >( file1 )),
(std::istreambuf_iterator< char >()) );
(About the only way you'll get a read error here is through an
exception.)
> return Out1;
> }
> void SaveFile(string FilePath, string FileContent)
> {
> ofstream file1;
> long long filesize;
> char Chr1;
> filesize = FileContent.length();
> if (FileExists(FilePath)) KillFile(FilePath);
> if (FileExists(FilePath)) return;
> if (filesize < 0) return;
If filesize < 0, here, you've got a very serious bug in your
implementation.
> file1.open (FilePath.c_str(), ios::binary);
> if (file1.is_open())
> {
> for (long long i = 0; i < filesize; i++)
> {
> Chr1 = FileContent[i];
> file1.write (&Chr1, 1);
> }
> }
Again, what's wrong with:
for ( std::string::const_iterator iter = FileContent.begin();
iter != FileContent.end();
++ iter )
file1.put( *iter );
? Or just:
std::copy( FileContent.begin(), FileContent.end(),
std::ostreambuf_iterator< char >( file1 ) );
> file1.close();
And you have to check the status of file1 after the close, and
report an error.
(While I'm at it, what's with these file1? It's output, or what
ever, or even file, given the context, but without the 1.)
> }
> //Here are the dependencies:
> long long GetFileSize(string FilePath)
> {
> long long Out1 = -1;
> ifstream file1;
> file1.open (FilePath.c_str());
> if (file1.is_open())
> {
> file1.seekg(0, ios::end);
> Out1 = file1.tellg();
Formally, this is not guaranteed to work. Practically, it
doesn't work under Windows if the file is opened in text mode
(as you've done). Nor under most other systems: Unix is the
exception.
> }
> file1.close();
> return Out1;
> }
> bool FileExists(string FilePath)
> {
> //http://msdn.microsoft.com/en-us/library/aa365740%28VS.85%29.aspx
> WIN32_FIND_DATA FindFileData;
> HANDLE hFind = FindFirstFile(FilePath.c_str(), &FindFileData);
> if (hFind == INVALID_HANDLE_VALUE || (FindFileData.dwFileAttributes &
> FILE_ATTRIBUTE_DIRECTORY))
> {
> return false;
> }
> else
> {
> return true;
> }
> }
If you're using system specific code... Use system specific
versions of open/read/write/close. They should offer the
necessary options for causing open to fail if the file doesn't
exist (input) or causing your file to replace any existing file
(output). For that matter, IIRC, this is guaranteed when you
open an ifstream or an ofstream, so you don't need any of this
anywhere.
> void Attach(string *OldString, string AddString, bool InNewLine)
> {
> if (InNewLine)
> {
> *OldString += Cr;
> *OldString += Lf;
> }
> *OldString += AddString;
And what on earth is this? (You only pass two arguments to
Attach, so your code shouldn't even compile.)
> }
> bool KillFile(string FilePath)
> {
> int Out1;
> Out1 = remove(FilePath.c_str());
> return Out1 == 0;
> }
Just for the record, this can have interesting consequences
under Unix, and might not be what you want.
--
James Kanze
== 2 of 3 ==
Date: Mon, Dec 28 2009 12:56 pm
From: James Kanze
On Dec 27, 6:11 pm, Dominik Schmidt <dominikschmi...@gmx.net> wrote:
> On Sun, 27 Dec 2009 09:39:12 -0800 (PST), Rune Allnor wrote:
[...]
> > If you want to work with binary files, use std::vector<char>
> > or something like that, instead of std::string. That way all
> > characters are treated as arbitrary numbers, with no special
> > significance attached to any of them.
> Actually I thought my code would already do this by using
> "ios::binary" in both functions?
It should. There could still formally be a problem, since
formally, implementations aren't required to recognize the end
of file correctly for binary files; e.g. you might read 128
bytes, when the input really only contained 10. But in
practice, systems where this would occur are almost non-existent
today.
--
James Kanze
== 3 of 3 ==
Date: Mon, Dec 28 2009 1:00 pm
From: James Kanze
On Dec 28, 6:07 am, Kaz Kylheku <kkylh...@gmail.com> wrote:
> On 2009-12-27, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
[...]
> >> void SaveFile(string FilePath, string FileContent)
> > You should learn to use references; that's better written as
> > void SaveFile(const string& path, const string& s)
> Under any sanely implemented compiler, there is no difference.
So g++, VC++ and Sun CC aren't sanely implemented. (Avoiding
the copy is very tricky, since the legality of the optimization
cannot be determined until link time.)
--
James Kanze
==============================================================================
TOPIC: "Reusable" operator overloading for enum?
http://groups.google.com/group/comp.lang.c++/t/981ab2c7a0c2c5ff?hl=en
==============================================================================
== 1 of 2 ==
Date: Mon, Dec 28 2009 1:10 pm
From: James Kanze
On Dec 27, 7:30 pm, nick <nick...@fastmail.fm> wrote:
[...]
> Marcel, your solution works perfectly. I like how it
> 'documents' the enum as being a flag set. I'm using this for
> now with a few small additions, but now I'm curious why people
> seem generally opposed to macros...
Because they don't obey scope. In this case, all of the other
solutions have worse problems, so macros are the way to go,
> Anyway, I have a few other small questions if you guys are
> still interested. Balog, you mentioned the ~ operator would
> not be predictable, and it sounds like it's because the way
> enums are stored in memory is not predictable?
No. It's because formally, the results may be a value which is
not in the legal range of the enum (which in your case is
effectively the or of all of the values). In practice, there
won't be any problem, so I wouldn't worry about it (assuming, of
course, that you do convert the value back to the target type).
> This makes me wonder if I should cast to unsigned as in
> Marcel's example, or signed as in Saeed's example and as I was
> doing before. Of course I'll only want to use positive numbers
> for my flag sets, but enums seem to handle negative numbers
> just fine, so I'm not sure what the right thing to do is here.
The safest solution is probably just to use unary + for the
conversion, e.g.:
MyEnum
operator|( MyEnum lhs, MyEnum rhs )
{
return static_cast< MyEnum >( +lhs | +rhs );
}
(The unary + operator is an arithmetic operator, so forces the
conversion of the enum into the underlying type, just as -
would.) If this looks too weird or exotic, there's always
"+ 0" instead.
> So, I guess my question is: is there a way to explicitly store
> an enum as an int, or an unsigned int, or whatever, either
> using a language construct or some kind of compiler
> instrucion? I'm using GCC 4.3.
I have some template metacode somewhere which evaluates the
underlying type, but IIRC, it's a bit hairy. Most of the time,
you don't need variables of the underlying type, however, and
the unary + trick is sufficient.
--
James Kanze
== 2 of 2 ==
Date: Mon, Dec 28 2009 2:32 pm
From: "Johannes Schaub (litb)"
nick wrote:
> Thanks for all the great replies!
>
> Marcel, your solution works perfectly. I like how it 'documents' the
> enum as being a flag set. I'm using this for now with a few small
> additions, but now I'm curious why people seem generally opposed to
> macros...
>
> Anyway, I have a few other small questions if you guys are still
> interested. Balog, you mentioned the ~ operator would not be
> predictable, and it sounds like it's because the way enums are stored
> in memory is not predictable?
>
> This makes me wonder if I should cast to unsigned as in Marcel's
> example, or signed as in Saeed's example and as I was doing before. Of
> course I'll only want to use positive numbers for my flag sets, but
> enums seem to handle negative numbers just fine, so I'm not sure what
> the right thing to do is here.
>
> So, I guess my question is: is there a way to explicitly store an enum
> as an int, or an unsigned int, or whatever, either using a language
> construct or some kind of compiler instrucion? I'm using GCC 4.3.
>
This one shows how you can find the right type:
http://stackoverflow.com/questions/1528374/how-can-i-extend-a-lexical-cast-
to-support-enumerated-types/1528436#1528436 . Doing "get_etype<sizeof
find_etype(EnumType())>::type" should give the type that can store all the
enum's values.
That's not the underlying type though - so its sizeof and the one of the
enum may differ, but I think that doesn't matter as long as you can store
all values.
==============================================================================
TOPIC: Design patterns
http://groups.google.com/group/comp.lang.c++/t/c99eb0b17c6ad648?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Dec 28 2009 4:25 pm
From: Jayson Cormier
Bean it! Everything... bean-able. Enterprise Java Bean, Netbeans...
==============================================================================
TOPIC: Event dispatcher, hooks and Interceptor pattern for C++?
http://groups.google.com/group/comp.lang.c++/t/a82e5c39e2fe1f12?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Dec 28 2009 5:54 pm
From: Pavel
Lothar Behrens wrote:
> On 27 Dez., 02:21, Pavel
> <pauldontspamt...@removeyourself.dontspam.yahoo> wrote:
>> Lothar Behrens wrote:
>>> Are there any documents available about the interceptor pattern?
>>
>>> I have a class that registers an event handler to be called on a given
>>> event. The interceptor pattern then should be used to add restrictions
>>> or other things to the function.
>>
>>> I could implement that in my dispatcher class (like an event
>>> dispatcher pattern), but I think there are patterns also usable for
>>> this issue in C++.
>>
>>> I have cases where I register event handlers per class and others per
>>> instance (by adding the pointer to the event name). Thus when I have
>>> an event handler per instance, but a interceptor
>>> per class I have to strip the pointer from the event name (after
>>> resolving it from the number) to locate the handler correctly.
>>
>>> Any help out there?
>>
>>> Thanks
>>
>>> Lothar
>>
>> RTTI in C++ is not sophisticated enough to get you a static function if
>> you have a typeid or another "runtime id" of the event class.
>>
>> You could probably construct your own metadata ("Runtime Class") so you
>> could refer to an instance of "RunTime class" from a virtual method of
>> your event or from "dispatchEvent" or similar method of your event
>> dispatcher, based on the result of some virtual method of the event
>> returning some form of its class id (maybe even typeid).
>>
>> Alternatively, with somewhat lesser flexibility, you could put your
>> intercepting logic into the method of the event itself, something along
>> these lines:
>>
>> class Event;
>> class EventHandler {
>> public:
>> virtual void handle(Event *)=0;
>>
>> };
>>
>> class Event {
>> public:
>> void process() {
>> if (!intercept())
>> handler_.handle(this);
>> } // I assume that's what you meant by "adding pointer to the event name"
>> virtual bool intercept(Event *) = 0;
>> private:
>> EventHandler handler_;
>>
>> };
>>
>> class ConcreteEvent : public Event {
>> public:
>> bool intercept() {
>> // one algorithm per event class here
>> // so no need to register
>> }
>>
>> };
>>
>> I am not sure I captured your problem fully; it would help if you posted
>> some source code to illustrate the issue.
>>
>> -Pavel
>
> The C++ language may not have the same capabilities as java, so I need
> a dispatcher where I register my callbacks to names or ID's.
> The event handler pattern is not the problem, as I use it since some
> years.
>
> The interceptor as I do understad, is a pre and post condition I could
> activate on demand to change the plain behavior for sample to
> add permission handling.
>
> My problem is if this interceptor pattern is also usable if I have a
> class (that is a database form) and I have different form instances
> and thus different interceptors are required to add logic depending on
> the particular form. Thus I may have more than one interceptor per
> form. The form it self is a dynamic implementation to be used for
> different data to be shown, thus there may also different
> interceptors.
>
> My main issue is about saving code. Another function I previously have
> implemented is inside of the handlers. I don't like to keep adding
> any more if I can do the same with interceptors. (application hooks
> will become interceptors)
>
> Lothar
I guess I am slightly confused then. I thought you wanted one
interceptor per class (even though I could not clearly understand -- per
event class, event source class or event handler class; in my example, I
assumed you wanted one interceptor per event class).
From your last post, however, I cannot see a difference between event
handler and event interceptor other than that you want some interceptors
to be called before and some after event handlers for same event. I
think you can achieve this without introducing new concept of an
Interceptor, simply with event handlers you already have. You could
register event handlers in a priority queue (with the priorities like
enum { PRE_INTERCEPTOR_PTY, REGULAR_HANDLER_PTY, POST_INTERCEPTOR_PTY }
) or two or three separate lists (two or three depending on whether you
want both "pre-" and "post-" interceptors). Also, if you want to be able
to stop event handling in an interceptor (to "veto" an event in terms of
Java or Interceptor pattern), you will need a boolean "processed"
attribute in events or alternatively you could make "handleEvent" return
bool.
If you require even more complex interactions between event handlers
(for example, you want to be able to skip some handlers but still
execute the last "logging" interceptor), you may need to add more
complex information to an event.
-Pavel
==============================================================================
TOPIC: 123
http://groups.google.com/group/comp.lang.c++/t/df6ba3af9ed2fc11?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Dec 28 2009 8:34 pm
From: "xfan"
i don't speak english!~~sorry!~~
"xfan" <xfan1216@qq.com> дÈëÏûÏ¢ÐÂÎÅ:hgt5jh$8uo$1@www.shinco.com...
>
>
>
==============================================================================
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
No comments:
Post a Comment