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

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

comp.lang.c++@googlegroups.com

Today's topics:

* Boost serialization of intrusive_ptr? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/91f2531a63d0de44?hl=en
* links to a design pattern? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/42542a0c8cd2f701?hl=en
* Discount wholesale New era2 CAP Washington Nationals CAP < www.ecyoyo.cn >==
paypal payment - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/3cd96a0e4e5ec972?hl=en
* please help me in this area(returning class using recursion)...... - 9
messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/738a7434e286543a?hl=en
* カウンターをオンラインでプレイストライキ, オンラインバックギャモンお金, 位置
ポーカー, あなたが手っ取り早く金を稼ぐことができます, お金をオンライン火かき棒
を稼ぐ, コンピュータゲーム, - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/7ea7f99087dec366?hl=en
* Run-time-checking whether a pure virtual function has been implemented - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/71c3c8c3041ae524?hl=en
* "this" pointer - 4 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/30a6e2edc7379021?hl=en
* ☆ №⒈☆ wholesale cheap replica brand shoes in www.salewto.com - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/ecf603efbec9452c?hl=en
* std iostreams design question, why not like java stream wrappers? - 3
messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/113f40a37ea215c8?hl=en
* canceling noncopyable feature - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/5add783081f15e0e?hl=en

==============================================================================
TOPIC: Boost serialization of intrusive_ptr?
http://groups.google.com/group/comp.lang.c++/t/91f2531a63d0de44?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Aug 27 2009 9:59 pm
From: Bradley Wilson

A few days ago I stumbled upon the fact that the boost serialization
library does not support intrusive_ptr, and no one else seems to have
done this. I've spent days poking around google to no avail.

Has anyone done this? I've looked at the code for serializing
shared_ptr in the hopes I'd be able to write my own wrapper, but it
looks like I'm not quite up to par yet. (Recent C -> C++ convert for a
personal project.)

Extra credit: I also need to... uh... *hangs head in shame*...
serialize boost memory pools.

Yeah. Really.

If I can't find a way to do that I'm going to be bogged down in
translating my containers of memory-pool-allocated, intrusive_ptr-using
objects to regularly-allocated objects for serialization and I'm not
looking forward to debugging those kind of shennanigans.

== 2 of 2 ==
Date: Fri, Aug 28 2009 4:42 am
From: ytrembla@nyx.nyx.net (Yannick Tremblay)

In article <2009082721590075249-themindwalrus@gmailcom>,
Bradley Wilson <the.mind.walrus@gmail.com> wrote:
>A few days ago I stumbled upon the fact that the boost serialization
>library does not support intrusive_ptr, and no one else seems to have
>done this. I've spent days poking around google to no avail.
>
>Has anyone done this? I've looked at the code for serializing
>shared_ptr in the hopes I'd be able to write my own wrapper, but it
>looks like I'm not quite up to par yet. (Recent C -> C++ convert for a
>personal project.)
>
>Extra credit: I also need to... uh... *hangs head in shame*...
>serialize boost memory pools.
>
>Yeah. Really.
>
>If I can't find a way to do that I'm going to be bogged down in
>translating my containers of memory-pool-allocated, intrusive_ptr-using
>objects to regularly-allocated objects for serialization and I'm not
>looking forward to debugging those kind of shennanigans.
>

Could you explain what you expect to happen when you serialise an
intrusive pointer and then at a later point in time, somewhere else,
you deserialise it?

What do you intend to do with the serialised data? Do you send it or
store it? What receives it?

Yannick

==============================================================================
TOPIC: links to a design pattern?
http://groups.google.com/group/comp.lang.c++/t/42542a0c8cd2f701?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Aug 28 2009 1:28 am
From: James Kanze

On Aug 27, 2:40 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> On Tue, 25 Aug 2009 12:42:27 -0400, Victor Bazarov
> <v.Abaza...@comAcast.net> wrote:
> > SpreadTooThin wrote:
> >> I'm looking for a design pattern for an ISO 7 layer stack.
> >> Anybody got one?

> > Is that a C++ language question? In case it isn't, try asking in
> > 'comp.software.patterns'.

> Also, as I understand it the OSI stack is a failed thought
> experiment, which noone has ever implemented fully. Not in the
> past thirty or so years it has "existed".

You understand wrong. I've worked on applications where we've
used it; IIRC, there were several commercial versions available
to choose from. It's (or at least was, when I worked in the
field) widely used in telecoms. Note too that like the Internet
protocols, it's not a monolithic unity, but a collection of
protocols at different levels. Some of which are widely used
within the Internet. And significant parts of the upper levels
have found their way into many of the Internet application
protocols. Although some parts of it are less used (IP and TCP
dominate in the layers 3 and 4), it's hardly what one could call
a "failed" experiment.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

==============================================================================
TOPIC: Discount wholesale New era2 CAP Washington Nationals CAP < www.ecyoyo.
cn >==paypal payment
http://groups.google.com/group/comp.lang.c++/t/3cd96a0e4e5ec972?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Aug 28 2009 1:28 am
From: wholesale jerseys

Discount wholesale Aff CAP
Discount wholesale Bape Baseball CAP ( www.ecyoyo.cn ) (paypal
payment)
Discount wholesale C CAP
Discount wholesale CA CAP
Discount wholesale Cincinnati Reds CAP
Discount wholesale Colorado Rockies CAP ( www.ecyoyo.cn ) (paypal
payment)
Discount wholesale Coogi CAP
Discount wholesale DC Baseball CAP
Discount wholesale Detroit Tigers CAP
Discount wholesale ED CAP ( www.ecyoyo.cn ) (paypal payment)
Discount wholesale ED Winter hat
Discount wholesale Gucci CAP
Discount wholesale Gucci Winter hat ( www.ecyoyo.cn ) (paypal
payment)
Discount wholesale Houston Astros CAP
Discount wholesale Jordan CAP
Discount wholesale Kansas City Royals CAP
Discount wholesale DSQ CAP
Discount wholesale LA CAP ( www.ecyoyo.cn ) (paypal payment)
Discount wholesale LV CAP
Discount wholesale Minnesota Twins CAP
Discount wholesale POLO CAP
Discount wholesale NBA CAP ( www.ecyoyo.cn ) (paypal payment)
Discount wholesale NEWERA CAP
Discount wholesale New era1 CAP
Discount wholesale New era2 CAP ( www.ecyoyo.cn ) (paypal payment)
Discount wholesale New Era Winter hat
Discount wholesale Oakland Athletics CAP
Discount wholesale P CAP
Discount wholesale Philadelphia Phillies CAP ( www.ecyoyo.cn )
(paypal payment)
Discount wholesale Red Bull CAP
Discount wholesale San Diego Padres CAP
Discount wholesale Sf Baseball CAP
Discount wholesale Smet CAP ( www.ecyoyo.cn ) (paypal payment)
Discount wholesale Sox CAP
Discount wholesale St. Louis Cardinals CAP
Discount wholesale Texas Rangers CAP
Discount wholesale Washington Nationals CAP ( www.ecyoyo.cn )
(paypal payment)

==============================================================================
TOPIC: please help me in this area(returning class using recursion)......
http://groups.google.com/group/comp.lang.c++/t/738a7434e286543a?hl=en
==============================================================================

== 1 of 9 ==
Date: Fri, Aug 28 2009 1:32 am
From: James Kanze

On Aug 27, 9:17 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> manohar wrote:
> >http://pastebin.com/m4338968e

> This:

> small=small*ptr[i]/(ptr[i]=small);

> is not only needlessly obfuscated, but probably also undefined
> behavior. (And even if it wasn't, I would never recommend
> writing such code. Even after watching it for minutes I can't
> tell what is it that that line is trying to do.)

It's definitely undefined behavior. And like you, I can't
figure out what it's supposed to be---if you separate it into
two expressions:
ptr[ i ] = small ;
small = small * ptr[ i ] / ptr[ i ] ;
it doesn't make much sense, either (especially the last one).

== 2 of 9 ==
Date: Fri, Aug 28 2009 2:47 am
From: Francesco

On 28 Ago, 10:32, James Kanze <james.ka...@gmail.com> wrote:
> On Aug 27, 9:17 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>
> > manohar wrote:
> > >http://pastebin.com/m4338968e
> > This:
> > small=small*ptr[i]/(ptr[i]=small);
> > is not only needlessly obfuscated, but probably also undefined
> > behavior. (And even if it wasn't, I would never recommend
> > writing such code. Even after watching it for minutes I can't
> > tell what is it that that line is trying to do.)
>
> It's definitely undefined behavior. And like you, I can't
> figure out what it's supposed to be---if you separate it into
> two expressions:
> ptr[ i ] = small ;
> small = small * ptr[ i ] / ptr[ i ] ;
> it doesn't make much sense, either (especially the last one).

Hi, sorry again for dropping in out of blue, I just want to understand
this UB thing.

First of all, this line:
small=small*ptr[i]/(ptr[i]=small);
seems just a weird way to swap the variables.

Simplifying the names...
s=s*p/(p=s);
...and being that the / operator associates left to right, i.e it
evaluates "s*p" first and "(p=s)" last, it would give something like:
sp = s*p;
s = sp/(p=s);

Or in other (less clear) "words"...
t = s;
// s=s*p/(p=s); // since "(p=s) == s" this becomes...
// s=s*p/s; // since "s*p/s == p" this becomes...
s = p;
p = t;

Now the question: does the associativity of operators enter in account
when considering the UB issue "evaluated twice in the same expression"
- or whatever it is called?

Francesco

== 3 of 9 ==
Date: Fri, Aug 28 2009 3:06 am
From: Francesco

On 28 Ago, 11:47, Francesco <entul...@gmail.com> wrote:
> On 28 Ago, 10:32, James Kanze <james.ka...@gmail.com> wrote:
>
>
>
> > On Aug 27, 9:17 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>
> > > manohar wrote:
> > > >http://pastebin.com/m4338968e
> > > This:
> > > small=small*ptr[i]/(ptr[i]=small);
> > > is not only needlessly obfuscated, but probably also undefined
> > > behavior. (And even if it wasn't, I would never recommend
> > > writing such code. Even after watching it for minutes I can't
> > > tell what is it that that line is trying to do.)
>
> > It's definitely undefined behavior. And like you, I can't
> > figure out what it's supposed to be---if you separate it into
> > two expressions:
> > ptr[ i ] = small ;
> > small = small * ptr[ i ] / ptr[ i ] ;
> > it doesn't make much sense, either (especially the last one).
>
> Hi, sorry again for dropping in out of blue, I just want to understand
> this UB thing.
>
> First of all, this line:
> small=small*ptr[i]/(ptr[i]=small);
> seems just a weird way to swap the variables.
>
> Simplifying the names...
> s=s*p/(p=s);
> ...and being that the / operator associates left to right, i.e it
> evaluates "s*p" first and "(p=s)" last, it would give something like:
> sp = s*p;
> s = sp/(p=s);
>
> Or in other (less clear) "words"...
> t = s;
> // s=s*p/(p=s); // since "(p=s) == s" this becomes...
> // s=s*p/s; // since "s*p/s == p" this becomes...
> s = p;
> p = t;
>
> Now the question: does the associativity of operators enter in account
> when considering the UB issue "evaluated twice in the same expression"
> - or whatever it is called?
>
> Francesco

Sorry, I mistaken the meaning of "associativity". But the point
remains, because * and / have the same precedence, they _should_ be
evaluated left to right. So then, is this something to keep in account
when considering the UB issue of sequence points and double
evaluation?

That's quite slippery ground for me :-/

Francesco

== 4 of 9 ==
Date: Fri, Aug 28 2009 3:31 am
From: Vladimir Jovic

Francesco wrote:
> First of all, this line:
> small=small*ptr[i]/(ptr[i]=small);
> seems just a weird way to swap the variables.

Don't forget that line, so you never do anything similar.

== 5 of 9 ==
Date: Fri, Aug 28 2009 3:47 am
From: Francesco

On 28 Ago, 12:31, Vladimir Jovic <vladasp...@gmail.com> wrote:
> Francesco wrote:
> > First of all, this line:
> > small=small*ptr[i]/(ptr[i]=small);
> > seems just a weird way to swap the variables.
>
> Don't forget that line, so you never do anything similar.

I will! Or, in other words, I won't. I won't forget and I won't write
similar stuff ;-)

By the way, I recall having read something about a trick used in
Assembly, where you swap two variables without using a temporary... is
it related to the above expression or to its compilation? I guess they
are completely different things.

Regards,
Francesco

== 6 of 9 ==
Date: Fri, Aug 28 2009 4:35 am
From: Juha Nieminen

Francesco wrote:
> By the way, I recall having read something about a trick used in
> Assembly, where you swap two variables without using a temporary... is
> it related to the above expression or to its compilation? I guess they
> are completely different things.

It involves doing three bitwise xor operations. It's completely
counter-productive because the xors will usually be slower, or at most
as fast, as the classical way of swapping.

== 7 of 9 ==
Date: Fri, Aug 28 2009 4:37 am
From: Juha Nieminen

Francesco wrote:
> s=s*p/(p=s);
> ...and being that the / operator associates left to right, i.e it
> evaluates "s*p" first and "(p=s)" last

I would be surprised if the standard required for the left part to be
evaluated before the right part. As long as the result of the expression
is correct, it doesn't matter in which order the elements are evaluated.

== 8 of 9 ==
Date: Fri, Aug 28 2009 4:46 am
From: Francesco

On 28 Ago, 13:35, Juha Nieminen <nos...@thanks.invalid> wrote:
> Francesco wrote:
> > By the way, I recall having read something about a trick used in
> > Assembly, where you swap two variables without using a temporary... is
> > it related to the above expression or to its compilation? I guess they
> > are completely different things.
>
> It involves doing three bitwise xor operations. It's completely
> counter-productive because the xors will usually be slower, or at most
> as fast, as the classical way of swapping.

So then it is a completely different thing. Thank you for the details,
Juha.

Francesco

== 9 of 9 ==
Date: Fri, Aug 28 2009 4:55 am
From: Francesco

On 28 Ago, 13:37, Juha Nieminen <nos...@thanks.invalid> wrote:
> Francesco wrote:
> > s=s*p/(p=s);
> > ...and being that the / operator associates left to right, i.e it
> > evaluates "s*p" first and "(p=s)" last
>
> I would be surprised if the standard required for the left part to be
> evaluated before the right part. As long as the result of the expression
> is correct, it doesn't matter in which order the elements are evaluated.

Pulling apart that I mistaken the meaning of "association" - because
it involves grouping and not evaluation order - later on I thought
that the two involved operands _ensured_ the evaluation order. Looking
at the operators precedence, I would have said that "(p=s)" _had_ to
be evaluated first, just like James said. The problem is that my GCC
evaluates "s*p" first. And it seems to do so systematically. I'm about
to test it further.

Well, after all I'm not the OP and all of this is just a chance to
learn new things.

Best regards,
Francesco

==============================================================================
TOPIC: カウンターをオンラインでプレイストライキ, オンラインバックギャモンお金,
位置ポーカー, あなたが手っ取り早く金を稼ぐことができます, お金をオンライン火か
き棒を稼ぐ, コンピュータゲーム,
http://groups.google.com/group/comp.lang.c++/t/7ea7f99087dec366?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Aug 28 2009 1:36 am
From: sell maier

カウンターをオンラインでプレイストライキ, オンラインバックギャモンお金, 位置ポーカ
ー, あなたが手っ取り早く金を稼ぐことができます, お金
をオンライン火かき棒を稼ぐ, コンピュータゲーム,

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

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
+
+
+

ポーカーモバイルゲーム
ポーカーチップテキサスホールデムのゲームを保持する
マルチプレイヤーポーカーインターネットで遊ぶ
オンラインポーカー PartyPoker.comの
ポーカー戦略カードゲームのポーカー
american ポーカーの2ゲームを買う無料でインターネットでお金を稼ぐ
インターネット上でお金を稼ぐお風呂の火かき棒ヴュルテンベルグ
solitaerオンラインゲームパーティーポーカー
テキサスホールデムを再生せずにオセロゲーム

http://suche.aol.de/aol/search?query=ポーカーをプレーしない+inurl%3Afor-um&invocationType=no.omittWeb&filter=false

==============================================================================
TOPIC: Run-time-checking whether a pure virtual function has been implemented
http://groups.google.com/group/comp.lang.c++/t/71c3c8c3041ae524?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Aug 28 2009 1:39 am
From: James Kanze

On Aug 27, 8:05 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> mzdude wrote:
> > On Aug 27, 9:04 am, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> >> Nordlöw wrote:
> >>> Is it possible to do runtime-checks whether a virtual
> >>> base-class pure virtual function has been implemented in
> >>> an inherited class?
> >> Run-time? Check? Why? Besides, what would be the point?
> >> If you have the object, it can't be of the abstract base
> >> type, can it? An object cannot be instantiated with the
> >> type that is abstract. If you have the pointer to the base
> >> class, the virtual function table (the usual way to
> >> implement the mechanism) contains the pointer to the final
> >> overrider for that function, not the unimplemented pure
> >> 0...

> >> What problem are you trying to solve?

> > I take to mean

> > #include <iostream>
> > using namespace std;

> > class Foo {
> > public:
> > virtual void bar() = 0 { cout << "Hello "; }
> > };

> > class Bar : public Foo
> > {
> > public:
> > virtual void bar() { cout << "World\n"; }
> > };

> > int main()
> > {
> > Bar b;

> > // Some kind of test to see if
> > // Foo::bar is implemented

> You mean there is a definition of that pure virtual function,
> yes?

I'm not too sure what he is asking, but I don't think it has
anything to do with this---he did say "implemented in an
inherited class". (Of course, taken literally, the answer is
simple: there's no runtime check, because if it isn't
implemented in a derived class, you can't instantiate objects of
that type.)

> > b.Foo::bar();
> > b.bar();

> > return 0;
> > }

> Code that calls a pure virtual function has undefined
> behavior.

No. Code that would resolve dynamically to a pure virtual
function is undefined behavior, but code that doesn't use
dynamic resolution can use it.

> Is that what you're trying to avoid?

> There is no portable way to determine that a pure virtual
> function has been implemented, AFAICT.

It has been implemented. Otherwise, you can't instantiate
objects of the type. If the inheritance hierarchy is more than
two levels, however, there's no way to know whether it was
instantiated in the most derived class, or in one of the
intermediate classes. (Maybe that's what he's asking. Maybe
not.)

==============================================================================
TOPIC: "this" pointer
http://groups.google.com/group/comp.lang.c++/t/30a6e2edc7379021?hl=en
==============================================================================

== 1 of 4 ==
Date: Fri, Aug 28 2009 1:58 am
From: James Kanze

On Aug 27, 2:44 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> Coltrane wrote:
> > how does a member function obtain the "this" pointer? I
> > thought it was past into a function via the stack. Is this
> > correct?

> Stack, register, whatever. It doesn't matter how it gets
> there, really. The 'this' pointer in a non-static member
> function is what's known as "the hidden argument". We don't
> know how that argument arrives to the function, we only know
> that it does.

Formally, it's not even an argument. Although I can't imagine
how you'd implement it otherwise, all the standard requires is
that it be present once you're in the function. (Practically,
of course, all the implementations I know pass it as a hidden
first argument, using the same conventions that they would for
any other argument. Why, I don't know---on an Intel processor,
I'd pass it in EBX, even though any other argument would be
passed on the stack, but the Intel compilers I have access to
don't do that.)

> If you need the implementation details, look at the assembly
> produced by your compiler. Or read "Inside the C++ Object
> Model" by Lippman.

And don't forget that neither exhausts all of the possibilities.

== 2 of 4 ==
Date: Fri, Aug 28 2009 2:07 am
From: James Kanze

On Aug 27, 3:31 pm, Coltrane <tendenga...@yahoo.com> wrote:
> On Aug 27, 9:04 am, Stuart Golodetz

[...]
> > > I was asked this on an interview and I thought it was on
> > > the stack but I also thought it was implementation
> > > specific.

> > Interview for what type of job, out of interest? Just
> > wondering why they might have asked the question. I guess if
> > it was a job programming compilers, then it might make sense
> > to ask...

> It was for a financial firm. they wanted a "C++ expert". I
> was surprised they asked it. I remember when I first learned
> C++ back, about 20 years ago, that it was on the stack at
> least for a microsoft compiler. I also seem to remember that
> it was compiler specific. Well it doesn't matter now, I didn't
> get the job.

Maybe luckily. Companies that ask that kind of question
generally don't know what they want or need, and are generally
confused elsewhere as well. Which doesn't make working for them
very pleasant.

If it makes you feel better, I was once rejected for a post
because of a similar sort of thing: the question was "what does
the keyword static mean?" and the answer they were looking for
was "not on the stack". They took the fact that I gave a twenty
line answer explaining different meanings in different contexts
as an indication that I didn't really understand C++.

Don't worry about it. Not all companies are that stupid.

== 3 of 4 ==
Date: Fri, Aug 28 2009 2:13 am
From: James Kanze

On Aug 27, 9:25 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> Pascal J. Bourguignon wrote:
> > Coltrane <tendenga...@yahoo.com> writes:

> >> how does a member function obtain the "this" pointer? I
> >> thought it was past into a function via the stack. Is this
> >> correct?

> > Conceptually, yes, via the stack.

No. Formally, it's a value, not an object, so it isn't
"passed", any more than the constant 42 is passed when you use
it. In both cases, it's up to the compiler to ensure that you
get the right value.

And of course, it also depends on what you mean by "stack".
Since the language supports recursive functions, all parameters
and local variables can be thought of as being on a stack,
abstractly. Practically, however, when people speak of "the
stack" (rather than "a stack"), they mean the machine stack.

> > In practice, the compilers may choose a different ABI, and
> > pass it thru a register (like for the other parameters), but
> > this is implementation specific detail you shouldn't care
> > about.

> Is taking the address of the 'this' pointer valid?

No. It's a value, not a variable or an object. (In C++ terms,
an rvalue, but for some reason, the C++ standard describes it in
C terms: a non-lvalue.) It has no address. (An rvalue only has
an address if it has class type. Dixit the standard---I've
worked on systems where doubles were actually in memory.)

== 4 of 4 ==
Date: Fri, Aug 28 2009 2:18 am
From: James Kanze

On Aug 27, 11:56 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> robertwess...@yahoo.com wrote:
> > On Aug 27, 2:25 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> >> Is taking the address of the 'this' pointer valid?

> > No it's not. Nor may you assign to it.

> Those requirements are enforced by the language, and in no way
> do they prove or disprove that the value of 'this' is passed
> on the stack or otherwise.

They don't say anything about how the compiler implements it,
no. But in one very real sense, "this" can't be "passed", on
the stack or otherwise, because it doesn't exist until you're in
the function. What the compiler passes is some interal
information that is uses to evaluate the value.

> 'this' is an expression that yields an rvalue, I suppose.

Yep. And since it has pointer type, the usual rules for
built-in operators apply: you can't use it in any expression
that requires an lvalue. (On the other hand, something like
"this + 1" is perfectly legal. I'd have some doubts concerning
the sanity of the programmer who used it, however.)

==============================================================================
TOPIC: ☆ №⒈☆ wholesale cheap replica brand shoes in www.salewto.com
http://groups.google.com/group/comp.lang.c++/t/ecf603efbec9452c?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Aug 28 2009 2:23 am
From: salewto

wholesale high quality and low price Adidas Shoes in www.salewto.com
wholesale high quality and low price Air Force one in www.salewto.com
wholesale high quality and low price Air Jordan in www.salewto.com
wholesale high quality and low price Amauri Shoes in www.salewto.com
wholesale high quality and low price Bape Shoes in www.salewto.com
wholesale high quality and low price Bikkembergs Shoes in www.salewto.com
wholesale high quality and low price BOSS Shoes in www.salewto.com
wholesale high quality and low price Burberry Shoes in www.salewto.com
wholesale high quality and low price Chanel Shoes in www.salewto.com
wholesale high quality and low price Coach Shoes in www.salewto.com
wholesale high quality and low price D&G Shoes in www.salewto.com
wholesale high quality and low price Diesel Shoes in www.salewto.com
wholesale high quality and low price Dior Shoes in www.salewto.com
wholesale high quality and low price DSQUARED Shoes in www.salewto.com
wholesale high quality and low price ED Hardy Shoes in www.salewto.com
wholesale high quality and low price Evisu Shoes in www.salewto.com
wholesale high quality and low price Fendi Shoes in www.salewto.com
wholesale high quality and low price FootBall in www.salewto.com
wholesale high quality and low price Gucci Shoes in www.salewto.com
wholesale high quality and low price LV Shoes in www.salewto.com
wholesale high quality and low price Nike AirMax in www.salewto.com
wholesale high quality and low price Nike Shox in www.salewto.com
wholesale high quality and low price Prada Shoes in www.salewto.com
wholesale high quality and low price Puma Shoes in www.salewto.com
wholesale high quality and low price RICH Shoes in www.salewto.com
wholesale high quality and low price SEBAGO Shoes in www.salewto.com
wholesale high quality and low price Timberland in www.salewto.com
wholesale high quality and low price UGG Boots Shoes in www.salewto.com
wholesale high quality and low price Versace Shoes in www.salewto.com
wholesale high quality and low price Y3 Shoes in www.salewto.com

we supply all kinds of brands shoes for women, men and kids.

Our advantages:
1) A rate quality wholesale price.
2) rapid and safe delivery time: 4-6days
3) no minute order requirement.
4) different styles, colors and sizes in stock for your reference
Whatever you need, you are free to contact me.

==============================================================================
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 3 ==
Date: Fri, Aug 28 2009 2:29 am
From: James Kanze

On Aug 27, 8:51 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> On Aug 27, 3:21 am, James Kanze <james.ka...@gmail.com> wrote:
> > On Aug 27, 8:52 am, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> > > I'd also say that it's convoluted given that it doesn't
> > > really solve any problems. Sure, it correctly handles the
> > > systems end of line, and it correctly uses the right code
> > > points for converting an integer to string representation
> > > for the locale, and cool stuff like a comma or a period
> > > for the thousand separators and "1 to tenths" separator.
> > > However, the entire iostream library is overkill if those
> > > are the only problems it solves, hence convoluted.

> > You seem to be confusing the issues. The iostream library
> > isn't concerned about much of that. The iostream library
> > provides:

> > -- a standard interface for data sinks and sources
> > (std::streambuf), along with two sample implementations
> > covering the most frequence cases (files and strings),

> > -- a standard interface for formatting, using the strategy
> > pattern to cleanly separate sinking and sourcing bytes from
> > the formatting---the formatting interface uses overloading
> > so that client code can extend it for types it's never heard
> > of,

> Except for system specific newline handling for non-binary
> mode, but I can live with that.

That's *not* in iostream, per se. It's a detail of one
particular subclass of streambuf (and it concerns more than just
newline handling---try reading a file which contains
"abc\032xyz\n" in text mode under Windows, for example).

> I think. Not exactly sure how that works.

> > -- a standard error handling strategy (which is rather
> > simplistic), and

> > -- a couple of wrapper classes to make it easier to set up the
> > most common cases (reading or writing from a file or a
> > string).

> > For all localization issues, it defers to <locale>, which is
> > overly complicated for what it does (which isn't really
> > enough).

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

Read the two points I just made above. Some of the predefined
formatting functions do use locale, but that's just an
implementation detail, and not part of the basic concept. And
the formatting functions you write don't have to use locale
unless you want them to.

> It handles newlines for you if not in binary mode, and uhh...

No it doesn't.

> is it with facet support that it handles printing integers and
> floats into human readable strings?

It provides the basic structure which allows formatting for any
type. Some of the actual formatters do use locale, but that's
rather secondary to iostream.

> So, back to my original complaint of why a separate streambuf
> and iostream class hierarchies when something like the Java
> Writer hierarchy or the Java OutputStream hierarchy seems so
> much clearer and simpler IMHO?

The Java OutputStream and Writer hierarchies are the Java
equivalent of streambuf. For formatting, you need
java.text.Format, and if you think that's simpler than iostream,
you've never used it.

== 2 of 3 ==
Date: Fri, Aug 28 2009 2:31 am
From: James Kanze

On Aug 27, 9:05 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> On Aug 27, 3:21 am, James Kanze <james.ka...@gmail.com> wrote:

> > On Aug 27, 8:52 am, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> > > On Aug 26, 8:07 pm, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
> > > > An awful lot of programs can get by quite nicely with just
> > > > using whatever locale the user wants, and C++ makes it
> > > > pretty easy to access that one -- an empty name gets it for
> > > > you.
> > > Only if you enjoy serving English speakers.

> > We use it all the time for French, with no problem. Under Unix,
> > locale( "" ) means pick up the correct locale from the user's
> > environment variables.

> Meh. Let me slightly correct myself. It's sufficient for most
> Latin scripts if you're not doing any sort of text
> transformtions (like substring), and it's generally sufficient
> for English which doesn't have combining characters, weird
> non-lexicogprahic sort rules, or anything else nasty.

If you're using non-Latin scripts, you're probably using
wchar_t. But you're write that there's no real standard support
for things like combining characters. In any language I know.
(The standard comparison operators for string, both in C++ and
in Java, are very naïve.)

== 3 of 3 ==
Date: Fri, Aug 28 2009 4:35 am
From: James Kanze

On Aug 28, 12:49 am, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
> In article <4b281a0e-4957-477f-a3a5-
> a67de8159...@b15g2000yqd.googlegroups.com>, james.ka...@gmail.com
> says...
> > On Aug 27, 5:07 am, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
> > > In article <fdb1cf7f-9851-49e1-90a4-7adb771fdad2
> [ ... ]

> > > > It's also entirely convoluted and complex, and doesn't
> > > > support simple things like changing from one encoding to
> > > > another.

> > > I beg your pardon?

> > The issue is complex, and he's at least partially right.

> Yes -- I was thinking in terms of the supposed inability to
> change from one encoding to another, which most certainly IS
> possible. Admittedly (and as you've pointed out) there's a
> bit of a problem with changing encoding when buffering is
> involved.

> I'd note that this is really just an instance of a much larger
> problem though. Buffering is intended to decouple the actions
> on the two sides of the buffer, and it does that quite well.
> In this case, however, we care about the state on the "far"
> side of the buffer -- exactly what the buffer is supposed to
> hide from us.

Certainly, and I don't know of a system which really supports it
fully. In general, you can pass from a one-to-one (byte)
encoding to something more complex, but once you've started with
something more complex, you can't go back. About the only
difference between C++ and Java here is that C++ documents this
fact. (Or else... IIRC, Java does the encoding after the
buffering, so the problems should be less.)

> [ ... ]
> > > At least they didn't do like Java and decree that wide
> > > characters were, and would always remain, 16 bits. A C++
> > > implementation can get things right or wrong, but a Java
> > > implementation is stuck with being wrong.

> > :-). In practice, there's nothing "wrong" with the Java
> > solution (UTF-16).

> Sort of true -- it's certainly true that UTF-16 (like UTF-8)
> is a much "nicer" encoding than things like the old shift-JIS.
> At least it's easy to recognize when you're dealing with a
> code point that's encoded as two (or more) words.

And it's trivial to resynchronize if you get lost.

> At the same time, you do still need to deal with the
> possibility that a single logical character will map to more
> than one 16-bit item, which keeps most internal processing
> from being as clean and simple as you'd like.

But if you're doing any serious text processing, that's true for
UTF-32 as well. \u0302\u0071 is a single character (a q with a
circumflex accent), even if it takes two code points to
represent. And if you're not concerned down to that level,
UTF16 will usually suffice.

But speaking from experience... Handling multibyte characters
isn't that difficult, and I find UTF8 the most appropriate for
most of what I do.

> Then again, at least in the Java code I've seen, the internal
> code is kept clean and simple -- which is fine until somebody
> feeds it the wrong data, and code that's been "working" for
> years suddenly fails completely...

Yes and no. Where I live, there are very strong arguments to go
beyond ISO 8859-1---the Euro character, the oe ligature, etc.,
not to mention supporting foreign names. But everything must be
in a Latin script; anything not Latin script is "wrong data".
In this case (and it's a frequent one in Europe), whether the
byte is a surrogate or a CKJ character really doesn't
matter---it's wrong data, and must be detected as such.

> > Nor with either of the two widespread C++ solutions. Or
> > with my solution of using UTF-8 and char. What might be
> > considered "wrong" is imposing one, and only one, on all
> > code. But I don't know of any system which offers both
> > UTF-16 and UTF-32; Java imposes one "right" solution,
> > whereas C++ allows the implementation to choose (guess?)
> > which solution is right for its customers.

> IMO, UTF-16 causes the biggest problem. The problem arises
> when the "length" of a string is ambiguous -- the number of
> characters differs from the number of units of storage.

But that's just as true with UTF-8 (which I regularly use), and
in a very real sense, with UTF-32 as well (because of combining
diacritical marks).

> With UTF-8, those differences are large enough and common
> enough that a mistake in this area will cause visible problems
> almost immediately.

> With UCS-4/UTF-32, there's never a difference, so no problem
> ever arises.

> With UTF-16, however, there's only rarely a difference -- and
> even when there is, it's often small enough that if (for
> example) your memory manager rounds up memory allocation
> sizes, you can use buggy code almost indefinitely without the
> bug becoming apparent. Then, (Murphy still being in charge)
> exactly when it's most crucial for it to work, the code fails
> _completely_, but duplicating the problem is next to
> impossible...

OK. I can almost see that point. Almost, because I'm still not
sure from where you're getting the length value for the
allocator. If you have a routine for counting characters that
is intelligent enough to handle surrogates correctly (where two
code points form a single character), then it might be
intelligent enough to handle combining diacritical marks
correctly as well, and the same problem will occur with UTF32.

> > Of course, the real reason why C++ is so open with regards
> > to what an implementation can do with wchar_t is because C
> > is. And the reason C is so open is because when C was being
> > normalized, no one really knew what encodings would end up
> > being the most wide spread; Unicode hadn't really become the
> > standard back then.

> At the time, Unicode was still _competing_ with ISO 10646
> rather than cooperating with it.

The Unicode Consortium was incorporated in January, 1991, and
the C adopted wchar_t sometime in the late 1980's---certainly
before 1988, when the final committee draft was voted on. And
ISO attributes standard numbers successively, which means that
ISO 10646 was adopted after ISO 9899 (the C standard). At the
time, I think that while it was generally acknowledged that
characters should be more than 8 bits, there was absolutely no
consensus as to what they should be.

> I think there's more involved though: C++ (like C) embodies a
> general attitude toward allowing (and even embracing)
> variation. While I think in recent years it has moderated to a
> degree, I think for a while (and still, though to a lesser
> degree) there was rather an amount of pride taken in leaving
> the languages loosely enough defined that they could be
> implemented on almost any machine (past or future), including
> some for which there was no realistic hope of anybody actually
> porting an implementation.

I think this is a good point---an essential point in some ways.
Don't formally standardize until you know what the correct
solution is. Today (2009), I think it's safe to say that the
"correct" solution is to support all of the Uncode encoding
formats (UTF-8, UTF-16 and UTF-32), and let the user choose; if
I were designing a language from scratch today, that's what I'd
do. Today, however, both Java and C++ have existing code to
deal with, which complicates the issues---Java has an additional
problem in that evolutions of the language must still run on the
original JVM. (But Java could define a new character type for
UTF-32 at the language level, using 'int' to implement it at the
JVM level. Except that some knowledge of the class String is
built into the language.)

FWIW: I'm not really convinced that we know enough about what is
"correct" even today to dare build it into the language (which
means casting it in stone). For the moment, I think that the
C++ solution is about the most we dare do.

==============================================================================
TOPIC: canceling noncopyable feature
http://groups.google.com/group/comp.lang.c++/t/5add783081f15e0e?hl=en
==============================================================================

== 1 of 3 ==
Date: Fri, Aug 28 2009 4:06 am
From: "Fraser Ross"

Will you be suggesting this change to the Boost administrators?

Fraser.

== 2 of 3 ==
Date: Fri, Aug 28 2009 4:39 am
From: James Kanze

On Aug 27, 3:02 pm, Michal <rabbi...@tenbit.pl> wrote:

> The following simple program allows for copying non-copyable
> function.

> #include <boost/noncopyable.hpp>
> #include <iostream>

> using namespace std;

> class Original: boost::noncopyable {

> public:
> Original() {
> cout << "Original constructor" << endl;
> }
> Original(const Original& rhs) {
> // this definition is the reason!!!!
> }
> };

> int main(int argc, char *argv[])
> {
> Original o;
> Original o2 = o;
> return 0;
> }

> Do You know how is it possible?

You lied to the compiler (and to the reader of your code).
First, you said that the object wasn't copiable, then you said
it was. I may be of the old school, but I find lying
despicable.

The simple solution to this problem is to fire the person who
wrote the code.

== 3 of 3 ==
Date: Fri, Aug 28 2009 4:47 am
From: James Kanze

On Aug 27, 8:25 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> mzdude wrote:
> > On Aug 27, 11:55 am, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> >> Fraser Ross wrote:
> >>> Thats a big problem. noncopyable doesn't do its job as
> >>> well as I thought.
> >> It doesn't necessarily means that it's not doing its job
> >> *as intended*, and what you thought isn't necessarily what
> >> was intended. What do you think it would do? Make any
> >> descendant class non-copyable?

> > Yes. Perhaps changing the boost::noncopyable object to hide
> > it's default ctor would help.

> > Then if you have a class derrived from it

> > class MyClass : boost::noncopyable
> > {
> > MyClass() : boost::noncopyable( some_trait ) {}

> > // then
> > MyClass( const MyClass &tocpy ) {}

> > would error because the compiler would subsitute the default
> > ctor for noncopyable which would be hidden.

> I don't think that noncopyable is meant to keep you from
> blowing your brains out. It's meant to be a somewhat language
> enforced method of documenting a known aspect of an interface.
> Anything that derives from noncopyable is not meant to be
> copied, that's what the relationship is documenting.

I'd agree if you restrict it to directly deriving. When you
derive from boost::noncopyable, you're saying that copying is
*not* allowed. According to the LSP, however, a class which
derives from MyClass, above, is (and should be) allowed to
reactivate copy, since it is a loosening of the
"pre-conditions". (I know, the LSP generally applies to
functions, and not to objects. But I think you get the idea---a
derived class may add functionality, as long as all of the
functionality of the base class still works.)

FWIW, it's not totally inexistant in my derived classes to add a
private copy constructor, to support cloning, even though the
base class forbids copying (by deriving from
Gabi::Util::UncopiableObject---which is probably identical to
boost::noncopyable, but a bit older).

> The rest just keeps the compiler from self-generating the
> copyable interface...I don't think it was ever meant to try
> rescuing people from their own stupidity and I don't see how
> it even could.

The problem with trying to make anything idiot proof is that
nature keeps coming up with better idiots. No matter what you
do, it will fail in the end.

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

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

Friday, August 28, 2009

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

No comments:

Blog Archive

About Me