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

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

comp.lang.c++@googlegroups.com

Today's topics:

* ◆⊙◆Website: WWW.FJRJTRADE.COM 2009 cheap price wholesale fashion True Relig
Jeans with high quality (paypal payment) - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/b75d38b9ffceefd6?hl=en
* Can anyone write this recursion for simple regexp more beautifully and
clearly than the braggarts - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/af69810e4522c696?hl=en
* "might be used uninitialized..." what? - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/b8f946d469d552ff?hl=en
* Selection algorithm - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/4d4bcabfc0f41d26?hl=en
* ▓▓2009 Cheap Wholesale brand&fashion swimming clothes (CA, Burberry, Gucci,
ED Hardy ect) at website: www.fjrjtrade.com (paypal payment) - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/5e363d976024aa73?hl=en
* An access issue -- programming on auto-pilot... - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/660a8f377649dc9b?hl=en
* wholesale jordan shoes discount new arrival jordan sneakers free shipping -
1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/4500f6f73d054aae?hl=en
* wholesale Air Jordan Fusions,discount jordan shoes, cheap kids jordans,Buy
wholesale shoes,Jordan 4.5 Fusion Men Shoes,womens nike sneakers - 1 messages,
1 author
http://groups.google.com/group/comp.lang.c++/t/8e32f6b82652dd6d?hl=en
* Rare Nike Sneakers, Retro Jordan Shoes,,Replica Ugg Boots,Best Quality
Jordans shoes,cheap gucci shoes from china on sale - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/568689b459a43fb3?hl=en
* A subtle access issue (may be advanced :-) ) - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/cfa68deb52dc50f5?hl=en
* std iostreams design question, why not like java stream wrappers? - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/113f40a37ea215c8?hl=en
* Weird warning about data type range - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/c0fda54bd4ba1f60?hl=en
* ♂♥♀♥๑Sale NBA jersey, Football jersey, Sex Edhardy Bikini, Fashion
Affliction Vest, Sunglasses, GHD hairstraightener ♂www.aoatrade.com♥ - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/8bffd9b61e1d6229?hl=en
* ❉♡❉HOT SALE Brand Sunglasses Gucci,Chanel,DG,Armani,LV,Coach,Edhardy,
Burberry,Prada,Ferri etc Sunglasses WWW.aoatrade.com - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/52756896adab894e?hl=en
* Pocket PCのテキサスホールデム, オンラインで大酒を飲む, ポーカー賭博, 簡単に
お金を, パソコン無料ゲーム, - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/19e896d0a03ba26f?hl=en
* g++ 3.4.5 doesn't zero-initialize - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/9c689fc29201ceec?hl=en

==============================================================================
TOPIC: ◆⊙◆Website: WWW.FJRJTRADE.COM 2009 cheap price wholesale fashion True
Relig Jeans with high quality (paypal payment)
http://groups.google.com/group/comp.lang.c++/t/b75d38b9ffceefd6?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 29 2009 10:09 am
From: candy

◆⊙◆Website: WWW.FJRJTRADE.COM 2009 cheap price wholesale fashion True
Relig Jeans with high quality (paypal payment)

Cheap Wholesale Jeans www.fjrjtrade.com

╃Men Size 30,32,34,36,38,40 Women Size 26,27,28,29,30,31 Cheap
Wholesale Jean

http://www.fjrjtrade.com/category-1261-b0-Jean.html

Wholesale True Relig Jeans (paypal payment)

http://www.fjrjtrade.com/category-1285-b0-True-Relig-Jean.html

Wholesale True Relig Men Jeans (paypal payment)

http://www.fjrjtrade.com/category-1289-b0-True-Relig-Man-Jean.html

Wholesale True Relig Women Jeans (paypal payment)

http://www.fjrjtrade.com/category-1290-b0-True-Relig-Women-Jean.html

╃Men Size 30,32,34,36,38,40 Women Size 26,27,28,29,30,31 Cheap
Wholesale Jean

http://www.fjrjtrade.com/category-1261-b0-Jean.html

Wholesale True Relig Jeans (paypal payment)

http://www.fjrjtrade.com/category-1285-b0-True-Relig-Jean.html

Wholesale True Relig Men Jeans (paypal payment)

http://www.fjrjtrade.com/category-1289-b0-True-Relig-Man-Jean.html

Wholesale True Relig Women Jeans (paypal payment)

http://www.fjrjtrade.com/category-1290-b0-True-Relig-Women-Jean.html

╃Men Size 30,32,34,36,38,40 Women Size 26,27,28,29,30,31 Cheap
Wholesale Jean

http://www.fjrjtrade.com/category-1261-b0-Jean.html

Wholesale True Relig Jeans (paypal payment)

http://www.fjrjtrade.com/category-1285-b0-True-Relig-Jean.html

Wholesale True Relig Men Jeans (paypal payment)

http://www.fjrjtrade.com/category-1289-b0-True-Relig-Man-Jean.html

Wholesale True Relig Women Jeans (paypal payment)

http://www.fjrjtrade.com/category-1290-b0-True-Relig-Women-Jean.html

╃Men Size 30,32,34,36,38,40 Women Size 26,27,28,29,30,31 Cheap
Wholesale Jean

http://www.fjrjtrade.com/category-1261-b0-Jean.html

Wholesale True Relig Jeans (paypal payment)

http://www.fjrjtrade.com/category-1285-b0-True-Relig-Jean.html

Wholesale True Relig Men Jeans (paypal payment)

http://www.fjrjtrade.com/category-1289-b0-True-Relig-Man-Jean.html

Wholesale True Relig Women Jeans (paypal payment)

http://www.fjrjtrade.com/category-1290-b0-True-Relig-Women-Jean.html

╃Men Size 30,32,34,36,38,40 Women Size 26,27,28,29,30,31 Cheap
Wholesale Jean

http://www.fjrjtrade.com/category-1261-b0-Jean.html

Wholesale True Relig Jeans (paypal payment)

http://www.fjrjtrade.com/category-1285-b0-True-Relig-Jean.html

Wholesale True Relig Men Jeans (paypal payment)

http://www.fjrjtrade.com/category-1289-b0-True-Relig-Man-Jean.html

Wholesale True Relig Women Jeans (paypal payment)

http://www.fjrjtrade.com/category-1290-b0-True-Relig-Women-Jean.html

Website:
http://www.fjrjtrade.com

==============================================================================
TOPIC: Can anyone write this recursion for simple regexp more beautifully and
clearly than the braggarts
http://groups.google.com/group/comp.lang.c++/t/af69810e4522c696?hl=en
==============================================================================

== 1 of 3 ==
Date: Sat, Aug 29 2009 10:16 am
From: bolega

On Aug 29, 8:53 am, A.L. <alewa...@aol.com> wrote:
> On Sat, 29 Aug 2009 07:10:59 -0700, JustBoo <B...@boowho.com> wrote:
> >bolega wrote:
> >> This braggart admits that he had to put this code in TWO books and
> >> visit it twice to be explained. I am puting the excerpt from pp2-4
> >> of this book and the C code.
> >[...]
>
> >Well, witness yet another way, boy and girls, to market a book. We'll
> >be seeing a lot of it from now on I'm sure. Meh. Enjoy.
>
> Very good way to market a book. Something criticized on c.l.l. must be
> really good.
>
> Ordered from Amazon 5 minutes ago.
>
> A.L.

please dont derail my thread, BUT, you ordered the wrong book. The one
you SHOULD have ordered is this one:

Book Review
--------------------------------------------------------------------------------
Advanced C Struct Programming by John W.L. Ogilvie
Highly Recommended
ISBN: 0-471-51943-X Publisher: Wiley Pages: 405pp
Price: £22.95

Categories: advanced c data structures
Reviewed by Francis Glassborow in C Vu 3-2 (Jan 1991)

This is the kind of book that I might easily miss on a casual visit
to
my local bookshop. In all honesty my first impression when I opened
it
was not that good. It is aimed at people who wish to take programming
seriously yet it first seemed more like the kind of text that I am
used to finding on the hobbyists shelves. It is much better than
that.
When you have mastered the foothills of programming in C, have a good
runtime library reference on your shelf and, perhaps, have invested
in
a book on data structures and another on programming algorithms or
techniques what do you get to help you develop good medium size
programs (all right large ones if you must)?

If you had asked my advice a month ago, I would have hummed and hawed
and come up with a couple of titles and then suggested that what you
really wanted was a book on program/data design rather than one on C.

Advanced C Struct Programming tackles this need. The author's
declared
intent is to present a practical method for designing and
implementing
complex (complicated) data structures in C. In doing so he leads you
through experience (sometimes of false trails) in tackling a number
of
different programming problems.

The book does not include complete applications or libraries of
source
code. It is a book to be worked through. By the time you have
finished
it you should be a much better programmer. Let me warn you that it is
not a book to dip into in that odd spare moment. If that is all you
have time for then go and do something else.

On the other hand it is not like some of the books above that will
take you years to fully grasp (if ever). Buy this book, set aside a
regular time to work at it, stick to your routine and find yourself
becoming far more professional in your programming.

Yes, I like it and it is not machine dependant. For once I am glad
that the supporting discs are relatively expensive ($39.95 in IBM and
Apple Mac formats) as I think that you will only get the full benefit
by grafting at the keyboard yourself.

--------------------------------------------------------------------------------
Last Update - 13 May 2001.

To link to this review, please use the URL:
http://www.accu.org/bookreviews/public/reviews/a/a000142.htm

== 2 of 3 ==
Date: Sat, Aug 29 2009 10:56 am
From: A.L.

On Sat, 29 Aug 2009 10:16:20 -0700 (PDT), bolega <gnuist006@gmail.com>
wrote:

>On Aug 29, 8:53 am, A.L. <alewa...@aol.com> wrote:
>> On Sat, 29 Aug 2009 07:10:59 -0700, JustBoo <B...@boowho.com> wrote:
>> >bolega wrote:
>> >> This braggart admits that he had to put this code in TWO books and
>> >> visit it twice to be explained. I am puting the excerpt from pp2-4
>> >> of this book and the C code.
>> >[...]
>>
>> >Well, witness yet another way, boy and girls, to market a book. We'll
>> >be seeing a lot of it from now on I'm sure. Meh. Enjoy.
>>
>> Very good way to market a book. Something criticized on c.l.l. must be
>> really good.
>>
>> Ordered from Amazon 5 minutes ago.
>>
>> A.L.
>
>please dont derail my thread, BUT, you ordered the wrong book. The one
>you SHOULD have ordered is this one:
>
>Book Review
>--------------------------------------------------------------------------------
>Advanced C Struct Programming by John W.L. Ogilvie
>Highly Recommended
>ISBN: 0-471-51943-X Publisher: Wiley Pages: 405pp
>Price: £22.95

I have this book already.

Regarding this one that I ordered - Amazon has 30 days return
policy...

A.L.

== 3 of 3 ==
Date: Sat, Aug 29 2009 4:02 pm
From: Chris McDonald

Ed Morton <mortonspam@gmail.com> writes:

>On Aug 28, 11:35=A0pm, bolega <gnuist...@gmail.com> wrote:
>> This braggart admits that he had to put this code in TWO books and
>> visit it twice to be explained. I am puting the excerpt from pp2-4 of
>> this book and the C code.

>You should post this to comp.lang.c.

> Ed.

He did, and I smelt a Bilges sock puppet.

--
Chris.

==============================================================================
TOPIC: "might be used uninitialized..." what?
http://groups.google.com/group/comp.lang.c++/t/b8f946d469d552ff?hl=en
==============================================================================

== 1 of 4 ==
Date: Sat, Aug 29 2009 10:39 am
From: "Thomas J. Gritzan"

Alf P. Steinbach schrieb:
> It's possible that I'm blind on both eyes.
>
> After all, it's late in the day (or morning) for me.
>
> But, I have this code which adds a string to a list of strings:
>
> virtual cppx::Index add(
> cppx::WideString const& s, cppx::WideString const& data
> )
> {
> int const id = myStrings.add( data );

// Line 1

> try
> {
> return Base::basicAdd( s, id );
> }
> catch( ... )
> {
> myStrings.remove( id );
> throw;
> }
> }
>
> Compiling with g++ 3.4.5, options (copy/paste from the IDE's build log)
>
> -Wall -O -pedantic -Wall -g -O -pedantic -Wall -std=c++98
> -Wno-long-long -Wwrite-strings
>
> the compiler complains that
>
> warning: 'id' might be used uninitialized in this function
[...]
> What is it that the compiler sees that I don't see?

If the 'add' call throws an exception, 'id' will be uninitialized. The
code in the catch clause won't be reached, but it uses id. The compiler
might contain a bug, so that it wrongly traces the usage of id and
outputs this warning.

In your toy example, the add function does never throw, so the compiler
doesn't warn.

Of course, this is only a theory. You are free to prove or disprove it ;-)

--
Thomas

== 2 of 4 ==
Date: Sat, Aug 29 2009 12:35 pm
From: "Alf P. Steinbach"

* Victor Bazarov:
> Alf P. Steinbach wrote:
>> It's possible that I'm blind on both eyes.
>>
>> After all, it's late in the day (or morning) for me.
>>
>> But, I have this code which adds a string to a list of strings:
>>
>> virtual cppx::Index add(
>> cppx::WideString const& s, cppx::WideString const& data
>> )
>> {
>> int const id = myStrings.add( data );
>>
>> try
>> {
>> return Base::basicAdd( s, id );
>> }
>> catch( ... )
>> {
>> myStrings.remove( id );
>> throw;
>> }
>> }
>>
>> Compiling with g++ 3.4.5, options (copy/paste from the IDE's build log)
>>
>> -Wall -O -pedantic -Wall -g -O -pedantic -Wall -std=c++98
>> -Wno-long-long -Wwrite-strings
>>
>> the compiler complains that
>>
>> warning: 'id' might be used uninitialized in this function
>
> Which line?

The reported line number points to the declaration of id.

> And why do use such an old compiler, don't they already have v4.x?

No, this is under Windows.

However there's a 4.4.1 version of g++ for Windows available from TDM, <url:
http://www.tdragon.net/recentgcc/>.

"The TDM-GCC builds are unofficial replacements for the official MinGW releases
of GCC binaries. TDM-GCC was previously recommended for experimentation purposes
only, but constant use in day-to-day development and a total download count of
over 50,000 have proven the TDM-GCC releases to be at least as usable as the
most recent official MinGW GCC release. Therefore, TDM-GCC is now heartily
endorsed for production use in any non-critical environment, with only the
following caveats: "

But it's a bit of a risk to use an "unofficial" in-advance build of a voluntary
working-for-free team's porting efforts of this free compiler.

I don't think it would solve anything really.

Cheers,

- Alf

== 3 of 4 ==
Date: Sat, Aug 29 2009 2:00 pm
From: Ian Collins

Thomas J. Gritzan wrote:
> Alf P. Steinbach schrieb:
>> It's possible that I'm blind on both eyes.
>>
>> After all, it's late in the day (or morning) for me.
>>
>> But, I have this code which adds a string to a list of strings:
>>
>> virtual cppx::Index add(
>> cppx::WideString const& s, cppx::WideString const& data
>> )
>> {
>> int const id = myStrings.add( data );
>
> // Line 1
>
>> try
>> {
>> return Base::basicAdd( s, id );
>> }
>> catch( ... )
>> {
>> myStrings.remove( id );
>> throw;
>> }
>> }
>>
>> Compiling with g++ 3.4.5, options (copy/paste from the IDE's build log)
>>
>> -Wall -O -pedantic -Wall -g -O -pedantic -Wall -std=c++98
>> -Wno-long-long -Wwrite-strings
>>
>> the compiler complains that
>>
>> warning: 'id' might be used uninitialized in this function
> [...]
>> What is it that the compiler sees that I don't see?
>
> If the 'add' call throws an exception, 'id' will be uninitialized.

It can't be uninitialised, it's a const.

--
Ian Collins

== 4 of 4 ==
Date: Sat, Aug 29 2009 2:14 pm
From: "Alf P. Steinbach"

* Ian Collins:
> Thomas J. Gritzan wrote:
>> Alf P. Steinbach schrieb:
>>> It's possible that I'm blind on both eyes.
>>>
>>> After all, it's late in the day (or morning) for me.
>>>
>>> But, I have this code which adds a string to a list of strings:
>>>
>>> virtual cppx::Index add(
>>> cppx::WideString const& s, cppx::WideString const& data
>>> )
>>> {
>>> int const id = myStrings.add( data );
>>
>> // Line 1
>>
>>> try
>>> {
>>> return Base::basicAdd( s, id );
>>> }
>>> catch( ... )
>>> {
>>> myStrings.remove( id );
>>> throw;
>>> }
>>> }
>>>
>>> Compiling with g++ 3.4.5, options (copy/paste from the IDE's build log)
>>>
>>> -Wall -O -pedantic -Wall -g -O -pedantic -Wall -std=c++98
>>> -Wno-long-long -Wwrite-strings
>>>
>>> the compiler complains that
>>>
>>> warning: 'id' might be used uninitialized in this function
>> [...]
>>> What is it that the compiler sees that I don't see?
>>
>> If the 'add' call throws an exception, 'id' will be uninitialized.
>
> It can't be uninitialised, it's a const.

This is a bug in g++ 3.4.5, apparently fixed in later versions.

The following ULRs report the same problem, even in standard library code!:

<url: http://gcc.gnu.org/ml/gcc-help/2005-05/msg00303.html>

<url:
http://sourceforge.net/tracker/index.php?func=detail&aid=2617155&group_id=2435&atid=102435>

<url:
http://cboard.cprogramming.com/cplusplus-programming/107970-uninitialized-var-list.html>

Newer versions of MinGW g++ than the 3.4.5 of the MinGW site are available at:

4.4.1: <url: http://www.tdragon.net/recentgcc/>

4.3.3: <url: http://nuwen.net/mingw.html>

I haven't tried yet, but I'm pretty confident that a newer compiler version will
fix the problem (unfortunately it seems that some of the folks who discussed the
problem think that turning off the warning is the way to go, but it's a very
useful warning when it's correct, just not when it's incorrect!).

Cheers & thanks for all replies,

- Alf

==============================================================================
TOPIC: Selection algorithm
http://groups.google.com/group/comp.lang.c++/t/4d4bcabfc0f41d26?hl=en
==============================================================================

== 1 of 3 ==
Date: Sat, Aug 29 2009 11:27 am
From: Stuart Golodetz

For what it's worth, partial_sort also sorts the k smallest elements,
whereas nth_element doesn't: if you don't care about the order of the
elements afterwards, I guess you'd expect nth_element to involve less
work, but I don't know how much difference it would make in practice
without profiling it.

The bit in Effective STL I was referring to was Item 31, in case it's
useful.

Regards,
Stu

Giuliano Bertoletti wrote:
>
> Hello,
>
> I guess that perfectly suits may needs. Thank you.
>
> Not only I do not care if the elements get rearranged, but I also need
> to erase the remaining n-k.
>
> So a partial_sort followed by a resize of the vector should be ok.
>
> The algorithm is meant to expand and evaluate the n branches of a tree
> node and then keep only k of them where the search continues.
>
> Cheers,
> Giulio.
>
>
>
> SG ha scritto:
>> On 29 Aug., 17:29, Giuliano Bertoletti <gbe32...@libero.it> wrote:
>> There's std::partial_sort which does what you want. But it obviously
>> modifies the vector. If you don't want to alter that vector you can
>> process the sequence in one pass and remember the k smallest elements.
>> I think you can do that with a little heap. Checkout std::push_heap,
>> std::pop_heap. The complexity should be something like O(log(k)*n).
>>
>> Cheers!
>> SG

== 2 of 3 ==
Date: Sat, Aug 29 2009 3:48 pm
From: Jerry Coffin

In article <4a99494c$0$43589$4fafbaef@reader1.news.tin.it>, gbe32241
@libero.it says...
>
> Hello,
>
> is there a better way to find the first k ranked elements of a vector of
> size n (with k < n) without sorting it first.
>
> Roughly I have n in the range [200..2000] and k = 3 or 4.
>
> Sorting would cost at least n*log(n) which in my opinion is a waste of time.
>
> Maybe I could hardwire a loop with a few comparisons for a given k (say
> k=3). I mean specialize a function for a certain k.

std::partial_sort should do the job reasonably well. Technically it
does a little more than you need (the first N elements are sorted)
but for small k, the difference is unlikely to mean much.

--
Later,
Jerry.

== 3 of 3 ==
Date: Sat, Aug 29 2009 5:38 pm
From: Jerry Coffin

In article <5c6afd17-467c-4557-b81f-8ffea93e0d21
@p15g2000vbl.googlegroups.com>, s.gesemann@gmail.com says...

[ ... ]

> There's std::partial_sort which does what you want. But it
> obviously modifies the vector. If you don't want to alter that
> vector you can process the sequence in one pass and remember the k
> smallest elements.

Or look up std::partial_sort_copy.

--
Later,
Jerry.

==============================================================================
TOPIC: ▓▓2009 Cheap Wholesale brand&fashion swimming clothes (CA, Burberry,
Gucci, ED Hardy ect) at website: www.fjrjtrade.com (paypal payment)
http://groups.google.com/group/comp.lang.c++/t/5e363d976024aa73?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 29 2009 11:27 am
From: candy

▓▓2009 Cheap Wholesale brand&fashion swimming clothes (CA, Burberry,
Gucci, ED Hardy ect) at website: www.fjrjtrade.com (paypal payment)

Various brand products in www.fjrjtrade.com

Discount Swimming clothes

http://www.fjrjtrade.com/category-1323-b0-Swimming.html

Swimming clothes:

CA swimming

http://www.fjrjtrade.com/category-1967-b0-CA-Swimming.html

Burberry swimming

http://www.fjrjtrade.com/category-1324-b0-Burberry-Swimming.html

Chanel swimming

http://www.fjrjtrade.com/category-1325-b0-Chanel-Swimming.html

ED Hardy swimming

http://www.fjrjtrade.com/category-1326-b0-Ed-Hardy-Swimming.html

Gucci swimming

http://www.fjrjtrade.com/category-1327-b0-Gucci-Swimming.html

LV swimming

http://www.fjrjtrade.com/category-1328-b0-LV-Swimming.html

Touse swimming

http://www.fjrjtrade.com/category-1329-b0-Touse-Swimming.html

Various brand products in www.fjrjtrade.com

Discount Swimming clothes

http://www.fjrjtrade.com/category-1323-b0-Swimming.html

Swimming clothes:

CA swimming

http://www.fjrjtrade.com/category-1967-b0-CA-Swimming.html

Burberry swimming

http://www.fjrjtrade.com/category-1324-b0-Burberry-Swimming.html

Chanel swimming

http://www.fjrjtrade.com/category-1325-b0-Chanel-Swimming.html

ED Hardy swimming

http://www.fjrjtrade.com/category-1326-b0-Ed-Hardy-Swimming.html

Gucci swimming

http://www.fjrjtrade.com/category-1327-b0-Gucci-Swimming.html

LV swimming

http://www.fjrjtrade.com/category-1328-b0-LV-Swimming.html

Touse swimming

http://www.fjrjtrade.com/category-1329-b0-Touse-Swimming.html

Various brand products in www.fjrjtrade.com

Discount Swimming clothes

http://www.fjrjtrade.com/category-1323-b0-Swimming.html

Swimming clothes:

CA swimming

http://www.fjrjtrade.com/category-1967-b0-CA-Swimming.html

Burberry swimming

http://www.fjrjtrade.com/category-1324-b0-Burberry-Swimming.html

Chanel swimming

http://www.fjrjtrade.com/category-1325-b0-Chanel-Swimming.html

ED Hardy swimming

http://www.fjrjtrade.com/category-1326-b0-Ed-Hardy-Swimming.html

Gucci swimming

http://www.fjrjtrade.com/category-1327-b0-Gucci-Swimming.html

LV swimming

http://www.fjrjtrade.com/category-1328-b0-LV-Swimming.html

Touse swimming

http://www.fjrjtrade.com/category-1329-b0-Touse-Swimming.html

Website:
http://www.fjrjtrade.com

==============================================================================
TOPIC: An access issue -- programming on auto-pilot...
http://groups.google.com/group/comp.lang.c++/t/660a8f377649dc9b?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 29 2009 12:23 pm
From: "Alf P. Steinbach"

* Fraser Ross:
> "Alf P. Steinbach"
>> Since others' errors can be enlightening, here's one of mine.
>>
>> Without really thinking, apparently on complete auto-pilot, I'd
>> written code equivalent to
>>
>> class Base
>> {
>> protected:
>> class Interface {};
>> };
>>
>> class Derived
>> : public Base
>> , protected Base::Interface
>> {
>> };
>>
>> int main()
>> {
>> }
>>
>> This actually compiles with MSVC 7.1! :-(
>>
>>
>> Cheers & hth.,
>>
>> - Alf
>
> It should compile. Comeau has a bug. Did you compare it to Comeau?

Yes.

Comeau C/C++ 4.3.10.1 (Oct 6 2008 11:28:09) for ONLINE_EVALUATION_BETA2
Copyright 1988-2008 Comeau Computing. All rights reserved.
MODE:strict errors C++ C++0x_extensions

"ComeauTest.c", line 10: error: class "Base::Interface" (declared at line 5) is
inaccessible
, protected Base::Interface
^

1 error detected in the compilation of "ComeauTest.c".

> Look at clause 11/6 and 7. The example is almost the same. It says
> "Similarly, the use of A::B
> as a base-specifier is well-formed because D is derived from A, so
> checking of base-specifiers must be deferred until the entire
> base-specifier-list has been seen.".

Heh, I'm better on auto-pilot than the darned compilers! ;-)

Thanks, I thought it was the code that was incorrect.

Cheers,

- Alf

==============================================================================
TOPIC: wholesale jordan shoes discount new arrival jordan sneakers free
shipping
http://groups.google.com/group/comp.lang.c++/t/4500f6f73d054aae?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 29 2009 12:39 pm
From: "www.vipshoeshop.com"

vipshoeshop Co.,Ltd( www.vipshoeshop.com ) wholesale nike jordan
sneakers big cheap air jordan sneakers for sale.discount china nike
dunk sb shoes,nike exclusive jordan sneakers,custom nike air force one
sneakers,nike dunk cheap,nike jordan sneakers wholesale,discount supra
shoes wholesale new balance shoes puma shoes,cheap adidas
shoes,authentic jordan sneakers,wholesale nike max 90 sheos,china
supplier nike max 87 max 2009 max 360 shoes,hot max 95 shoes,free
shipping prada shoes,nike retro jordan snekaers,other nike running
shoes,wholesale nike lebron james 6 sneakers,cheap nike zoom kobe 4
sneakers free shipping, kids jordan sneakers wholesale, nike air force
one 1 fusion jordan sneakers,buy sneaker for cheap,nike air max
premium leather sneakers,gucci tennis shoes for discount,high quality
gucci shoes,wholesale jordan fusion sneakers from china supply,cheap
air bape sneakers, China Nike product manufacturer,gucci shoes,supply
puma sneakers timberland shoes,discounts Jordans kicks shoes Cheap
Discount Basketball Sneakers on Sale, Nike Retro Air Jordan Melo M5

==============================================================================
TOPIC: wholesale Air Jordan Fusions,discount jordan shoes, cheap kids jordans,
Buy wholesale shoes,Jordan 4.5 Fusion Men Shoes,womens nike sneakers
http://groups.google.com/group/comp.lang.c++/t/8e32f6b82652dd6d?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 29 2009 12:47 pm
From: "www.vipshoeshop.com"

==============================================================================
TOPIC: Rare Nike Sneakers, Retro Jordan Shoes,,Replica Ugg Boots,Best Quality
Jordans shoes,cheap gucci shoes from china on sale
http://groups.google.com/group/comp.lang.c++/t/568689b459a43fb3?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 29 2009 12:48 pm
From: "www.vipshoeshop.com"

==============================================================================
TOPIC: A subtle access issue (may be advanced :-) )
http://groups.google.com/group/comp.lang.c++/t/cfa68deb52dc50f5?hl=en
==============================================================================

== 1 of 3 ==
Date: Sat, Aug 29 2009 2:25 pm
From: "Alf P. Steinbach"

* James Kanze:
> On Aug 29, 9:11 am, "Alf P. Steinbach" <al...@start.no> wrote:
>> The following code compiles as-is with g++ and Comeau Online,
>> but not when then the commented lines are uncommented:
>
>> <code>
>> #include <stddef.h>
>
>> template< class T > T* create();
>
>> class Base
>> {
>> template< class T > friend T* create();
>> private:
>> static void* operator new( size_t size )
>> {
>> return ::operator new( size );
>> }
>
>> // static void operator delete( void* p )
>> // {
>> // ::operator delete( p );
>> // }
>
>> protected:
>> virtual ~Base() {}
>>
>> };
>
>> class Derived
>> : public Base
>> {
>> public:
>> Derived() {}
>> virtual ~Derived() {}
>> };
>
>> template< class T >
>> T* create() { return new T; }
>
>> int main()
>> {
>> create<Derived>();
>> }
>> </code>
>
>> With uncommenting the commented code both compilers complain
>> that the Derived destructor can't access Base::operator
>> delete.
>
> Correctly (more or less).

As you write further down, you don't *know* that.

And neither do I. :-)

But one might suspect that the destructor needing access is correct wrt. to the
standard, and that the standard therefore ideally should be corrected, for
access has nothing to do with machine code.

> There are two potential problems, the
> first I'm certain of, the second less so:
>
> The first is simple: anytime you have a new expression, the
> compiler must be able to access operator delete at the point of
> the new expression, since if the constructor exits by an
> exception, the corresponding delete will be called. (I.e. if it
> is a placement new, placement delete will be called.)

Yes, since I explained that further down in the (very short) original article, I
know that.

> The second is a bit more subtle, and I'm not too sure what the
> standard says (and I'm not sure where it says it, and am too
> lazy to spend a quarter of an hour or more looking for it in all
> of the possible places), but one frequent implementation of
> destructors implies passing a hidden argument stating whether
> operator delete should be called or not from the destructor.
> The reason for this is that the correct operator delete is the
> one which is correct for the most derived class, and the
> compiler can't know which one this is in the delete expression;
> some derived class may have provided its class specific delete.
> I seem to recall, vaguely, that the standard endorses this
> solution by requiring access control on operator delete in the
> destructor---but as I said, I'm not sure, and I have even less
> of an idea where to look in the standard to find it.

Yes, I explained also this further down in the (very short) original article.

The issue is, however, why the heck *access* should be affected.

Given that the code compiles fine with at least one common compiler it's not a
problem for the compiler to generate machine code to do what the (uncommented)
code expresses, and then the access rules should ideally be unaffected by the
implementation detail of how exactly things are done at the machine code level.

For access isn't about machine code.

It's about logical access.

Cheers & thanks (but didn't help, and I think standard's probably screwed up),

- Alf

== 2 of 3 ==
Date: Sat, Aug 29 2009 6:16 pm
From: ld

On 29 août, 09:11, "Alf P. Steinbach" <al...@start.no> wrote:
> The following code compiles as-is with g++ and Comeau Online, but not when then
> the commented lines are uncommented:
>
> <code>
> #include <stddef.h>
>
> template< class T > T* create();
>
> class Base
> {
> template< class T > friend T* create();
> private:
> static void* operator new( size_t size )
> {
> return ::operator new( size );
> }
>
> // static void operator delete( void* p )
> // {
> // ::operator delete( p );
> // }
>
> protected:
> virtual ~Base() {}
>
> };
>
> class Derived
> : public Base
> {
> public:
> Derived() {}
> virtual ~Derived() {}
>
> };
>
> template< class T >
> T* create() { return new T; }
>
> int main()
> {
> create<Derived>();}
>
> </code>
>
> With uncommenting the commented code both compilers complain that the Derived
> destructor can't access Base::operator delete.
>
> They don't complain that the Derived constructor can't access Base::operator new.
>
> I can understand the lack of complaint for the constructor: the constructor
> doesn't need to access the allocation function, which is invoked by the new
> expression which is in the context of the create function which has access.
>
> I don't understand the complaint for the destructor. The new expression has to
> potentially deallocate, if an expression is thrown. But it manages well to use
> the allocation function, so why can't it also use the deallocation function?
>
> In short, why this different treatment?
>
> It almost seems as if the standard supports an implementation technique where
> the call to the deallocation function is made directly from *within* the most
> derived class' destructor?

yes, this is exactly for this reason. From the standard, the only
reference I can see is the first sentence in the section of delete (c+
+98 §5.3.5) "The delete-expression operator destroys a most derived
object or array created by a new-expression". There is no motivation
for this statement in the standard, but you can find the explanation
in TCPL3 (SE) in §15.6 (Free Store).

The operator delete must know the size of the object to destroy. Since
the delete operator is always static and it's first argument is of
type void*, the two solutions to know the object's size are either the
operator delete is called from the destructor of the most derived
class where the exact object's size is known and passed (e.g.
Base::operator delete(p, sizeof(Derived))), either the size is stored
with the object (or elsewhere) and the delete operator knows how to
retrieve it (e.g. malloc-like implementation). In fact these two
approach are equivalent and depend on the implementation which is
unspecified by the standard. This explains why some implementation
require the access to the operator delete of Base from the destructor
of Derived (i.e. called within ~Derived()) and some don't (called
outside ~Derived()). Since the former is more efficient in both space
and speed, it tends to be the common behavior of decent compilers.

BTW, why don't you declare Base::operator delete as protected instead
of private since its role is more or less the same as the destructor
~Base() ?

Cheers,

ld.

== 3 of 3 ==
Date: Sat, Aug 29 2009 7:42 pm
From: "Alf P. Steinbach"

* ld:
> On 29 août, 09:11, "Alf P. Steinbach" <al...@start.no> wrote:
>> The following code compiles as-is with g++ and Comeau Online, but not when then
>> the commented lines are uncommented:
>>
>> <code>
>> #include <stddef.h>
>>
>> template< class T > T* create();
>>
>> class Base
>> {
>> template< class T > friend T* create();
>> private:
>> static void* operator new( size_t size )
>> {
>> return ::operator new( size );
>> }
>>
>> // static void operator delete( void* p )
>> // {
>> // ::operator delete( p );
>> // }
>>
>> protected:
>> virtual ~Base() {}
>>
>> };
>>
>> class Derived
>> : public Base
>> {
>> public:
>> Derived() {}
>> virtual ~Derived() {}
>>
>> };
>>
>> template< class T >
>> T* create() { return new T; }
>>
>> int main()
>> {
>> create<Derived>();}
>>
>> </code>
>>
>> With uncommenting the commented code both compilers complain that the Derived
>> destructor can't access Base::operator delete.
>>
>> They don't complain that the Derived constructor can't access Base::operator new.
>>
>> I can understand the lack of complaint for the constructor: the constructor
>> doesn't need to access the allocation function, which is invoked by the new
>> expression which is in the context of the create function which has access.
>>
>> I don't understand the complaint for the destructor. The new expression has to
>> potentially deallocate, if an expression is thrown. But it manages well to use
>> the allocation function, so why can't it also use the deallocation function?
>>
>> In short, why this different treatment?
>>
>> It almost seems as if the standard supports an implementation technique where
>> the call to the deallocation function is made directly from *within* the most
>> derived class' destructor?

[snip explanation of machine code level -- I don't think it should influence
access!]

> BTW, why don't you declare Base::operator delete as protected instead
> of private since its role is more or less the same as the destructor
> ~Base() ?

That's what I had to do, but the reason for the "private:" is to express in the
language that a derived class' code can't do 'delete this'.

With protected access it can. :-(

>
> Cheers,
>
> ld.

Thanks :-) Although I disagree (very strongly) that access rules should be
affected by possible implementation techniques for the compiler.

Cheers,

- Alf

==============================================================================
TOPIC: std iostreams design question, why not like java stream wrappers?
http://groups.google.com/group/comp.lang.c++/t/113f40a37ea215c8?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 29 2009 3:48 pm
From: Jerry Coffin

In article <0d7e57cf-c1bd-42df-a187-bb5b3ee6bda5
@x6g2000prc.googlegroups.com>, joshuamaurice@gmail.com says...

[ ... ]

> And remind me again, exactly what does the iostream library without
> <locale> do again?

Nothing, of course -- since it depends on locale, it won't compile
without locale, and code that doesn't compile almost never does much
of anything.

> It handles newlines for you if not in binary mode,
> and uhh... is it with facet support that it handles printing integers
> and floats into human readable strings? So, back to my original
> complaint of why a separate streambuf and iostream class hierarchies

Because they do entirely different sorts of things. A stream buffer
is a standardized interface to some sort of stream. An iostream is a
formatter. Yes, a lot of the default formatting is locale specific,
but it doesn't really change much. _Something_ has to connect the
bits and pieces in a locale and apply them to a stream, and that code
certainly does NOT belong in a stream buffer, because it's entirely
unrelated to anything a stream buffer does.

> when something like the Java Writer hierarchy or the Java OutputStream
> hierarchy seems so much clearer and simpler IMHO?

Of course, it's impossible to answer why you hold a particular
opinion -- especially a positive opinion of a hierarchy like Java's
OutputStream and relatives, that its own inventors think little
enough of that they've deprecated its use (in favor of the rather
more complex OuputWriter hierarchy).

[ ... ]

> I fully recognize that templates do not solve everything, and that
> you need to be able to work on a generic stream which uses dynamic
> dispatch to do the actual work, for compilation speed reasons, code
> bloat reasons (and thereby runtime speed and size reasons), etc. My
> solution offers both. With it, you would only pay for the virtual
> overhead when you actually need to use it. (Note that
> jjm:istream_wrapper should probably be buffered by default.) I haven't
> thought this through fully, but enough to ask "Why isn't it done this
> way which seems superior?"

Although a lot has been modified and added to iostreams along the
way, the _basic_ design goes back to (for one thing) long before the
existence of templates. I'm pretty sure that if anybody was designing
them today, they'd come out rather different than they are now.

I guess that's a rather roundabout way of saying that your design may
well be superior, but unless you're willing to put in a _lot_ of work
(to turn it into something the committee might accept as a real
proposal for an addition to the standard) it's probably not going to
go much of anywhere. At least to me, it appears that most users of
C++ just don't care very much.

This highlights one major difference between Java and C++. In C++
it's _much_ easier to bypass the built-in I/O primitives (or almost
any other part of the standard library) and do something else (often
system-specific) when/if it's a problem. They work well enough most
of the time, and they're easy to ignore when they're a real problem.
In Java, if the built-in I/O facilities are inadequate, it's _much_
more difficult to just ignore them and put something together on your
own.

--
Later,
Jerry.

==============================================================================
TOPIC: Weird warning about data type range
http://groups.google.com/group/comp.lang.c++/t/c0fda54bd4ba1f60?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 29 2009 5:35 pm
From: Digital Puer

Thanks for everyone's help.

What I am really trying to do is to test if
characters in a std::string are alphanumeric
characters in the Latin-1 encoding. I have
the following:

#define IS_ALPHANUMERIC(x) ( \
((x) >= 48 && (x) <= 57 ) || \
((x) >= 65 && (x) <= 90 ) || \
((x) >= 97 && (x) <= 122) || \
((x) >= 192 && (x) <= 214) || \
((x) >= 216 && (x) <= 246) || \
((x) >= 248 && (x) <= 255) )

string s = getLatin1Text();
int len = s.size();
for (int i = 0; i < len; i++)
{
if (! IS_ALPHANUMERIC(s.at(i)))
{
...
}
}

When I compile that, the last check (x <= 255)
gives the same warning that I showed in my
original post:

warning: comparison is always true due to limited range of data type

I guess I will have to isolate away the last check
with a #IF statement.

==============================================================================
TOPIC: ♂♥♀♥๑Sale NBA jersey, Football jersey, Sex Edhardy Bikini, Fashion
Affliction Vest, Sunglasses, GHD hairstraightener ♂www.aoatrade.com♥
http://groups.google.com/group/comp.lang.c++/t/8bffd9b61e1d6229?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 29 2009 7:28 pm
From: Gao wendy

♂♥♀♥๑Sale NBA jersey www.aoatrade.com, Football jersey www.aoatrade.com,
Sex Edhardy Bikini www.aoatrade.com, Fashion Affliction Vest www.aoatrade.com,
Sunglasses www.aoatrade.com, GHD hairstraightener ♂ www.aoatrade.com♥

==============================================================================
TOPIC: ❉♡❉HOT SALE Brand Sunglasses Gucci,Chanel,DG,Armani,LV,Coach,Edhardy,
Burberry,Prada,Ferri etc Sunglasses WWW.aoatrade.com
http://groups.google.com/group/comp.lang.c++/t/52756896adab894e?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 29 2009 7:31 pm
From: Gao wendy

❉♡❉HOT SALE Brand Sunglasses Gucci Sunglasses www.aoatrade.com,
Chanel Sunglasses www.aoatrade.com,
DG Sunglasses www.aoatrade.com,
Armani Sunglasses www.aoatrade.com,
LV Sunglasses www.aoatrade.com,
Coach Sunglasses www.aoatrade.com,
Edhardy Sunglasses www.aoatrade.com,
Burberry Sunglasses www.aoatrade.com,
Prada Sunglasses www.aoatrade.com,
Ferri etc Sunglasses www.aoatrade.com

==============================================================================
TOPIC: Pocket PCのテキサスホールデム, オンラインで大酒を飲む, ポーカー賭博, 簡
単にお金を, パソコン無料ゲーム,
http://groups.google.com/group/comp.lang.c++/t/19e896d0a03ba26f?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 29 2009 7:47 pm
From: super mario

Pocket PCのテキサスホールデム, オンラインで大酒を飲む, ポーカー賭博, 簡単にお金を, パソ
コン無料ゲーム,

+
+++ ポーカーをオンライン +++ オンラインポーカー +++ ポーカースクール +++

http://WWW.ONLINE-POKER-JAPAN.NL
http://WWW.ONLINE-POKER-JAPAN.NL
http://WWW.ONLINE-POKER-JAPAN.NL
http://WWW.ONLINE-POKER-JAPAN.NL
http://WWW.ONLINE-POKER-JAPAN.NL
http://WWW.ONLINE-POKER-JAPAN.NL
http://WWW.ONLINE-POKER-JAPAN.NL
http://WWW.ONLINE-POKER-JAPAN.NL
http://WWW.ONLINE-POKER-JAPAN.NL
http://WWW.ONLINE-POKER-JAPAN.NL
http://WWW.ONLINE-POKER-JAPAN.NL
+
+
+

金融インターネットでオンラインでお金を稼ぐ
テキサスホールデムのCOM 高速かつ安全な現金を
ポーカーチップお金のフォーラムを稼ぐ
テキサスホールデムを再生せずにラミー
あなたがオンラインでお金を稼ぐことができる携帯ゲーム無料
お金を稼ぐダブルオンラインゲーム頭
サインアップなしでポーカーをプレーする無料ゲーム
私が簡単に現金独占オンラインギャンブル

http://suche.aol.de/aol/search?query=テキサス無料日火かき棒を保持する+inurl%3Afor-um&invocationType=no.omittWeb&filter=false

==============================================================================
TOPIC: g++ 3.4.5 doesn't zero-initialize
http://groups.google.com/group/comp.lang.c++/t/9c689fc29201ceec?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 29 2009 8:29 pm
From: "Alf P. Steinbach"

Grr.

What's wrong with this code?

struct WndClassEx: WNDCLASSEX
{
WndClassEx(
cppx::WideString const& name,
Params const& params
)
: WNDCLASSEX()
{
cbSize = sizeof( WNDCLASSEX );
style = params.style();
lpfnWndProc = &DefWindowProc;
hInstance = params.module();
hCursor = ::LoadCursor( 0, IDC_ARROW );
hbrBackground = reinterpret_cast<HBRUSH>( COLOR_BTNFACE + 1 );
lpszClassName = name.cStr();
}

WndClassEx const* ptr() const
{
return this;
}
};

Answer: nothing in particular, at least when one knows that it's just a little
local helper class where 'name' arg has lifetime guaranteed to be enough.

But MinGW g++ doesn't zero-initialize the WNDCLASSEX as it should (this is a
plain struct with no constructor, provided by the Windows API).

Argh!

I knew old MSVC doesn't always zero-initialize /arrays/ when told to.

But I didn't know that g++ doesn't zero-initialize /structs/ when told to.

And by the way, the gdb debugger is driving me crazy. Ignoring breakpoints and
telling me the source code for some stack frame is at arbitrary location in
arbitrary file. And yes, optimizations turned off, which is another annoyance,
since g++ needs optimizations on to e.g. warn about uninitialized things.

Not to mention the Code::Blocks IDE's debugger output display, which doesn't
display anything of interest, just a bunch of info lines about internal details
of the debugger, and actively *swallows* trace output, which is what I'd need.

Happily it's possible to view a (nearly, almost, but of course not 100%)
complete log of the IDE's interaction with the brain-damaged debugger beast, and
there one can present stderr output. But. Oh well.

I need coffee.

- Alf

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

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 29, 2009

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

No comments:

Blog Archive

About Me