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

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

comp.lang.c++@googlegroups.com

Today's topics:

* On the Square-Rectangle Problem - 7 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/17378f3e6e3294ba?hl=en
* Seeking typical C++ source code. Help please! - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/772085c9212fa2e7?hl=en
* MySQL connector/driver behaviour with Visual C++ CLR/CLI project - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/738ca35dc8623177?hl=en
* ◈•_•◈ Hot sale cheap shoes, T-shirts, handbags, purses, caps, underwears etc
www.ecyaya.com FASHION !!! - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/3fce90d2262f1ce2?hl=en
* Incomplete types and std::vector - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/b0741c38fc15b5f7?hl=en
* ◆⊙◆ Cheap wholesale Chanel scarf, Burberry Scarf, LV scarf ect at www.rijing-
trade.com <Paypal Payment> - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/a7e4516ddd40dce0?hl=en
* isspace - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/89ca303518428e34?hl=en
* Static member vs global variable - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/39598a6a81930f50?hl=en
* system("ls") - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/ea8887c99b1a8b02?hl=en
* struct containing vector? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/d0ba6cd9c3737991?hl=en
* ordered unordered_map - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/3743266d80703cfb?hl=en
* What are the key differences between operator new and operator new[]? - 6
messages, 5 authors
http://groups.google.com/group/comp.lang.c++/t/0711f4e6de411900?hl=en

==============================================================================
TOPIC: On the Square-Rectangle Problem
http://groups.google.com/group/comp.lang.c++/t/17378f3e6e3294ba?hl=en
==============================================================================

== 1 of 7 ==
Date: Wed, Feb 3 2010 12:10 am
From: tonydee

On Feb 2, 1:47 am, "Alf P. Steinbach" <al...@start.no> wrote:
> * Stefan Ram:
>
>
>
> > r...@zedat.fu-berlin.de (Stefan Ram) writes:
> >> It has been solved by me some years ago - I don't know if
> >> anyone else has published this solution, but I guess so:
>
> > I have been looking around and found:
>
> >http://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_...)
>
> > Using the terms from this article, I can define a function:
>
> > *: T -> T*
>
> > that maps a type T of values to a type T* of storage cells
> > for such values, and the essential assertion then becomes:
>
> > * is contravariant.
>
> > That is, using »<=« from this article:
>
> > square <= rectangle, but
> > rectangle* <= square*.
>
> > So, obviously, many computer scientists are aware of
> > contravariance - just some authors of web articles about
> > »the square-rectangle problem« are not.
>
> Not sure if I follow the above, it looks like obfuscation.
>
> I discussed the ellipse/circle problem in my "pointers" tutorial, which is now
> off-web. Perhaps I should put it on Google docs. Essentially, as you point out,
> it is about an immutable-values-view versus a modifiable-variables view.
>
> And yes, understanding it is essential for understanding the Liskov substitution
> principle (contra-variance and co-variance), and it ties in with "const" in C++.
> It also ties in with "in", "in/out" and "out" in languages that support such,
> e.g. the partial support in C#.
>
> Cheers,
>
> - Alf

Hi Alf,

I would agree that the problem only arises for mutable values, but I
wouldn't agree that the problem is _about_ constness/mutability.
Still, enforced constness may be a legitimate solution, encouraging
robust usage... whether it's actually more natural and intuitive for
developers may depend upon their educational background and
experience....

I do hope you'll have time to put your articles back online....

> For C++ the only such support is half hidden and
> very limited, namely co-variance for pointer or reference function results.

Good point - an explicit way to mark "out" parameter would be great.
Tuples and structs help somewhat but can be clumsy.

Regards,
Tony

== 2 of 7 ==
Date: Wed, Feb 3 2010 12:13 am
From: Nilone

On Feb 3, 9:23 am, tonydee <tony_in_da...@yahoo.co.uk> wrote:
> On Feb 3, 3:50 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>
> > tonydee <tony_in_da...@yahoo.co.uk> writes:
> > >explore what happens when you map that conclusion most simply/naively
> > >into an object model: a Circle object as a special case (subclass) of
> > >a more general Ellipse. The answer is that you have Circles that
> > >can't do what is reasonable to ask of an Ellipse, namely, alter the
> > >ratio of width to height, without ceasing to be Circles. You hide
>
> > Such an object does not truly model a circle, because a
> > circle cannot be modified.
>
> Indeed :-).
>
> > Instead it seem to model a
> > circle storage, which is something different from a circle.
> > The essential property of an ellipse storage is an ellipse
> > /requirement/: It requires a value to be an ellipse (in order
> > to become accepted for storage). Since every circle is an
> > ellipse, every ellipse requirement R also accepts circles. Thus:
>
> > x e C ==> x e E (if x is a circle, then x is an ellipse)
> > R a C <== R a E (if R accepts ellipses, then R accepts circles)
>
> > The transition from objects to requirements is what actually
> > inverts the direction of the arrow above. It happens to apply
> > to stores, because stores for type T require values to be of type T.
>
> The issue is not with storage: an ellipse can store a circle. But
> your statement "if R accepts ellipses, then R accepts circles" is
> wrong, given a function R that accepts an ellipse by reference and
> attempts to change its height:width ratio.

I understood R to refer specifically to ellipse stores. A method
which modifies an ellipse store cannot operate on circle stores, since
mutator methods aren't inherited covariantly *in subtyping*. They are
in OO inheritance, which is one of the reasons OO inheritance isn't
subtyping. Another is dynamic dispatch.

> That's the flaw in the
> naive OO model... itself an important insight, but again -
> understanding this is primarily a basis for discussing how to model
> Circles and Ellipses in a more inherently robust fashion....
>
> > >form Mrs Liskov spotlight. You can try to mitigate the mess by having
> > >the Circles throw exceptions, return a success indicator, assert or
>
> > You are calling something a Circle here, what is really a
> > circle storage . This is like calling a numeric variable a
> > number : It is alright as long as you know that it really is
> > storage, not a value.
>
> Wrong. I clearly defined "Circle" and "Ellipse" above in terms of
> naive OO modeling, in which Circle is subclassed from Ellipse and
> therefore inherits its Ellipse storage.

OO inheritance isn't subtyping.

== 3 of 7 ==
Date: Wed, Feb 3 2010 12:59 am
From: ram@zedat.fu-berlin.de (Stefan Ram)

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>x e C ==> x e E (if x is a circle, then x is an ellipse)
>R a C <== R a E (if R accepts ellipses, then R accepts circles)

This can also be put in this wording:

Let us call 0 and 1 »small values«.

Let us call a function that accepts a small value as an
argument a »small function«, while a function that accepts
any int argument an is called an »int function«.

Then we have:

Every small value is an int value.

Every int function is a small function.

(Note the interchange of directions.)

Now, when we have a store, it can be set to a value:

store.set( value )

The set-function of a small store is a small function,
the set-function of an int store is an int function.

So the contravariance actually only holds for the
set functions of a storage object, while the get functions
(which return the stored value) are covariant.

So to avoid confusion one needs to talk about values
and functions.

Whole interfaces (i.e., sets of functions) might not be
covariant or contravariant, but a mixture of both
(with regard to a value type).

== 4 of 7 ==
Date: Wed, Feb 3 2010 1:31 am
From: Philip Potter

On 03/02/2010 05:02, Stefan Ram wrote:
> Philip Potter <pgp@doc.ic.ac.uk> writes:
>> A square store is guaranteed to hold a square. A rectangle store has no
>> such guarantee.
>> A rectangle store which currently holds a nonsquare rectangle is
>> certainly not useful as a square store.
>
> If a rectangle store can store a width and a height, then it
> can store a square by storing the width and the height of
> the square (which happen to be equal to each other for a square).
>
> Assuming for simplicity rectangles and squares with borders
> that are parallel to the axes of the coordinate system, both
> have only the width and height as their properties.
>
> (However, you might define some of these terms in other ways,
> and then you would be right. So here, everything depends on the
> definitions used for these terms.)

My problem isn't that a rectangle store can't store a square -- it can
-- it's that a rectangle store is able to store things other than a
square, while a square store promises to only hold squares.

Imagine a function 'void f (SquareStore &x)' which takes a reference to
a square store, and expects that store to come preloaded with a square
value. It will throw an exception if the store is empty, but it assumes
that if the store is not empty then it contains a square value.

Now, suppose I call that function with a rectangle store instead. That
function now has a rectangle value where it was expecting a square value.

These statements are contradictory, and one has to go:

* A rectangle store makes every promise that a square store makes.
* A square store will only ever hold a square.
* A rectangle store can store non-square rectangles.

Phil

== 5 of 7 ==
Date: Wed, Feb 3 2010 1:49 am
From: ram@zedat.fu-berlin.de (Stefan Ram)

Philip Potter <pgp@doc.ic.ac.uk> writes:
>My problem isn't that a rectangle store can't store a square -- it can
>-- it's that a rectangle store is able to store things other than a
>square, while a square store promises to only hold squares.

I see. That is an other meaning than the one I had in mind.

== 6 of 7 ==
Date: Wed, Feb 3 2010 2:09 am
From: Nilone

On Feb 3, 11:31 am, Philip Potter <p...@doc.ic.ac.uk> wrote:
> On 03/02/2010 05:02, Stefan Ram wrote:
>
>
>
>
>
> > Philip Potter <p...@doc.ic.ac.uk> writes:
> >> A square store is guaranteed to hold a square. A rectangle store has no
> >> such guarantee.
> >> A rectangle store which currently holds a nonsquare rectangle is
> >> certainly not useful as a square store.
>
> > If a rectangle store can store a width and a height, then it
> > can store a square by storing the width and the height of
> > the square (which happen to be equal to each other for a square).
>
> > Assuming for simplicity rectangles and squares with borders
> > that are parallel to the axes of the coordinate system, both
> > have only the width and height as their properties.
>
> > (However, you might define some of these terms in other ways,
> > and then you would be right. So here, everything depends on the
> > definitions used for these terms.)
>
> My problem isn't that a rectangle store can't store a square -- it can
> -- it's that a rectangle store is able to store things other than a
> square, while a square store promises to only hold squares.
>
> Imagine a function 'void f (SquareStore &x)' which takes a reference to
> a square store, and expects that store to come preloaded with a square
> value. It will throw an exception if the store is empty, but it assumes
> that if the store is not empty then it contains a square value.
>
> Now, suppose I call that function with a rectangle store instead. That
> function now has a rectangle value where it was expecting a square value.
>
> These statements are contradictory, and one has to go:
>
> * A rectangle store makes every promise that a square store makes.
> * A square store will only ever hold a square.
> * A rectangle store can store non-square rectangles.
>
> Phil- Hide quoted text -
>
> - Show quoted text -

Since the parameter is in/out, arguments would have to comply with the
intersection of covariant inheritance of value properties and
contravariant inheritance of variable mutators, i.e. you could only
pass a square store and not a rectangle store.

A pure in-parameter would be able to accept any square value including
values of subtypes of square.

A pure out-parameter would be able to accept any square store
including stores of supertypes of square.

As for the contradictory statements, a rectangle store promises to
store square values, just like a square store does. Whether the value
in it is a square or a rectangle isn't a property of the store, but of
the value itself.

== 7 of 7 ==
Date: Wed, Feb 3 2010 3:43 am
From: Philip Potter

On 03/02/2010 10:09, Nilone wrote:
> On Feb 3, 11:31 am, Philip Potter <p...@doc.ic.ac.uk> wrote:
>> My problem isn't that a rectangle store can't store a square -- it can
>> -- it's that a rectangle store is able to store things other than a
>> square, while a square store promises to only hold squares.
>>
>> Imagine a function 'void f (SquareStore &x)' which takes a reference to
>> a square store, and expects that store to come preloaded with a square
>> value. It will throw an exception if the store is empty, but it assumes
>> that if the store is not empty then it contains a square value.
>>
>> Now, suppose I call that function with a rectangle store instead. That
>> function now has a rectangle value where it was expecting a square value.
>>
>> These statements are contradictory, and one has to go:
>>
>> * A rectangle store makes every promise that a square store makes.
>> * A square store will only ever hold a square.
>> * A rectangle store can store non-square rectangles.
>>
> Since the parameter is in/out, arguments would have to comply with the
> intersection of covariant inheritance of value properties and
> contravariant inheritance of variable mutators, i.e. you could only
> pass a square store and not a rectangle store.

Which parameter is in/out? A slight variation, 'void f (const
SquareStore &x)', has the same problem, but it's definitely not in/out
wrt to the function.

If you're talking about in/out wrt the store itself, I'm afraid that any
definition of "store" which doesn't let you put things in and take
things out is not one I'm willing to accept.

> A pure in-parameter would be able to accept any square value including
> values of subtypes of square.
>
> A pure out-parameter would be able to accept any square store
> including stores of supertypes of square.

If this is the problem, how would you prevent a SquareStore being used
as an in/out parameter?

> As for the contradictory statements, a rectangle store promises to
> store square values, just like a square store does. Whether the value
> in it is a square or a rectangle isn't a property of the store, but of
> the value itself.

What you say is true, but it leaves out the fact that a square store is
guaranteed to give me a square out of it, while a rectangle store makes
no such promise.

Having read Stefan's comments elsethread, I think I finally get it.

These are guaranteed:

* A rectangle store can accept any square value
* A square store will only emit rectangle values

BUT these are not guaranteed:

* A square store can accept any rectangle value
* A rectangle store will only emit square values

If the stores are write-only, a rectangle store is (substitutable for) a
square store. Code that wants to stuff a square somewhere can use either.

If the stores are read-only, a square store is (substitutable for) a
rectangle store. Code that wants to get a rectangle value can use either.

But if (for some reason) you expect both behaviours, then there is no
simple relationship between square store and rectangle store, and that
is my problem with Stefan's original post.

The key thing for me in the Square-Rectangle problem, and the thing that
this analysis doesn't really cover, is Liskov substitutability. A
derived class must keep all the promises a base class makes. The problem
only arises if a Rectangle makes a promise a Square can't keep, or vice
versa. If this is the case, then Rectangle and Square cannot be directly
descended from each other, though they might be siblings.

Phil

==============================================================================
TOPIC: Seeking typical C++ source code. Help please!
http://groups.google.com/group/comp.lang.c++/t/772085c9212fa2e7?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 12:14 am
From: Alan Mackenzie

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> On Tue, 2010-02-02, Alan Mackenzie wrote:
>> Hi, clc++,

>> Would somebody please recommend some hopefully not too big C++ FOSS
>> project which contains source which makes liberal use of C++'s
>> features, in particular templates (ideally both using them and
>> defining them).

>> I could do with this since I maintain Emacs C++ mode and need a
>> realistic test file, although I'm hardly a C++ hacker.

> Then I'm not sure if you should mess around with it too much -- writing
> code without using it or understanding how people use it is typically a
> Bad Idea.

> No offense intended, .....

None taken. :-)

> ...., and I'm of course grateful for your work in that area. It's just
> that I use c++-mode heavily and am very pleased with it, arguing that
> Emacs is the best C++ editor in the world and so on ...

Thanks!

> I'd hate to see regressions.

Not as much as I would hate it. ;-) But there are bugs in C++ Mode to do
with template brackets, and I've just fixed one. I'd like to hammer some
real code with it before I release it. The bug is to do with code like:

if (x < 0 || y < 0 || x >= 9) {

(hi, Kevin!), where C++ Mode can misinterpret < and > as template
brackets if the >= is deleted and reinserted.

It's actually impossible, in the general case to distinguish "template
open/close" from "less/greater than" without doing semantic analysis,
i.e. using a compiler. Who on Earth decided to use these tokens as
delimiters instead of something unambiguous like, say, <{ and }> ?

> I'm also not sure heavily templated code should be the main test
> vector. But perhaps you ask for it because you have plenty of plain
> C++ code already.

Well, see above!

> /Jorgen

--
Alan Mackenzie (Nuremberg, Germany).

==============================================================================
TOPIC: MySQL connector/driver behaviour with Visual C++ CLR/CLI project
http://groups.google.com/group/comp.lang.c++/t/738ca35dc8623177?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 12:24 am
From: Michael Foukarakis

On Feb 3, 6:48 am, 0 <jeffrey.whites...@gmail.com> wrote:
> Hello. i'm having an issue getting the MySQL connector/driver to
> behave proberly with a Visual C++ CLR/CLI project.... my issue is
> best described by this screen capture:http://img97.imageshack.us/i/mysqlissue.jpg/
>
> The host name that MySQL is trying to resolve is a series of strange
> characters.... certainly not the "string" that is passed into the
> connector function. The exception handler is saying: Unknown MySQL
> server host 'U‹ìWVS ì ' (11004)... clearly it is not trying to
> connect to tcp://bluetech
>
> Has anyone see this? Could it have to do with language/character sets
> or something? I've already tried: this->con = this->driver->connect
> (L"tcp://bluetech:3306",L"SC",L"SC"); but, the connect function is
> looking for a std::string.
>
> Can someone please help me?
>
> Thanks!

You are hiding the driver's implementation, so there's not much to
say. I'll assume you're using the non-deprecated mysql_real_connect()
function to connect to a MySQL database; in that case, there's a lot
of mandatory parameters you might be missing in your call. Again,
based on the stripped-down interface you're showing, it's hard to
tell.

If you care to provide some more related info, we might be able to
help.

Cheers.

==============================================================================
TOPIC: ◈•_•◈ Hot sale cheap shoes, T-shirts, handbags, purses, caps,
underwears etc www.ecyaya.com FASHION !!!
http://groups.google.com/group/comp.lang.c++/t/3fce90d2262f1ce2?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 3 2010 12:27 am
From: hero

◈•_•◈ Hot sale cheap shoes, T-shirts, handbags, purses, caps,
underwears etc www.ecyaya.com FASHION !!!

"Nike Air Max sneaker www.ecyaya.com (paypal payment)
Air Max 91 sneaker www.ecyaya.com
Nike-ID sneaker www.ecyaya.com (wholesale cheap)
Air Max 87 sneaker www.ecyaya.com
Air-Max-2003 sneaker www.ecyaya.com (paypal payment)
Air max 5 sneaker www.ecyaya.com (wholesale cheap)
Air-Max-Tailwind-09 sneaker www.ecyaya.com (paypal payment)
Air-Max-new-180 sneaker www.ecyaya.com (wholesale cheap)
Air-Max-LTD sneaker www.ecyaya.com (paypal payment)
Air-Max-2006 sneaker www.ecyaya.com (wholesale cheap)
Air Max 97 sneaker www.ecyaya.com (paypal payment)
Air Max 92 sneaker www.ecyaya.com (wholesale cheap)
Air Max 90 sneaker www.ecyaya.com (paypal payment)
Air-Max-Yeezy sneaker www.ecyaya.com (wholesale cheap)
Air Max 09 sneaker www.ecyaya.com (paypal payment)
Air-Max-TN sneaker www.ecyaya.com (wholesale cheap)
Air Jordan LTD2 sneaker www.ecyaya.com (paypal payment)
Air-Max-Skyline sneaker www.ecyaya.com (wholesale cheap)
Air-Max-miniBMW sneaker www.ecyaya.com (paypal payment)
Air-Max-2009 sneaker www.ecyaya.com (wholesale cheap)
Air-Max180 sneaker www.ecyaya.com (paypal payment)
Air Max 95 sneaker www.ecyaya.com (wholesale cheap)
+Nike Shox sneaker www.ecyaya.com (paypal payment)
Nike-shox-TR sneaker www.ecyaya.com
Nike-shox-TL3 sneaker www.ecyaya.com (wholesale cheap)
Nike-shox-R3 sneaker www.ecyaya.com (paypal payment)
Nike-air-Plata sneaker www.ecyaya.com
Nike-shox-new sneaker www.ecyaya.com (paypal payment)
Nike-shox-87 sneaker www.ecyaya.com
Nike-shox-97 sneaker www.ecyaya.com (wholesale cheap)
Nike-shox-NZ sneaker www.ecyaya.com (paypal payment)
Nike-shox-R5 sneaker www.ecyaya.com (wholesale cheap)
Nike-shox-R4 sneaker www.ecyaya.com (paypal payment)
Nike-shox-TL1 sneaker www.ecyaya.com (wholesale cheap)
Nike-shox-OZ sneaker www.ecyaya.com (paypal payment)
Nike-shox-TZ sneaker www.ecyaya.com (wholesale cheap)
Nike-shox-torch sneaker www.ecyaya.com (paypal payment)
+Air Force 1 sneaker www.ecyaya.com
Air-Force-1 sneaker www.ecyaya.com (paypal payment)
AF1-low-shoes sneaker www.ecyaya.com (wholesale cheap)
AF1-Supreme-TZ-man sneaker www.ecyaya.com (paypal payment)
+Nike Rift sneaker www.ecyaya.com
Nike-Air-zenyth sneaker www.ecyaya.com (wholesale cheap)
Nike-Rift sneaker www.ecyaya.com (paypal payment)
"
"Adidas Shoes sneaker www.ecyaya.com (wholesale cheap)
Adidas-Good-Year sneaker www.ecyaya.com (paypal payment)
Adidas-Good-Year2 sneaker www.ecyaya.com
+Puma Shoes sneaker www.ecyaya.com (paypal payment)
Puma-woman-shoes sneaker www.ecyaya.com (wholesale cheap)
Puma-man-shoes sneaker www.ecyaya.com (paypal payment)
Puma-centennial sneaker www.ecyaya.com (wholesale cheap)
Puma sneaker www.ecyaya.com (paypal payment)
Puma-6 sneaker www.ecyaya.com (wholesale cheap)
Puma-new sneaker www.ecyaya.com (paypal payment)
Puma-Kimi-Rainkkonen sneaker www.ecyaya.com (wholesale cheap)
Puma-Anniversary sneaker www.ecyaya.com (paypal payment)
Puma-8813 sneaker www.ecyaya.com (wholesale cheap)
Puma-5 sneaker www.ecyaya.com (paypal payment)
+Nike Blazer sneaker www.ecyaya.com
Nike-Blazer sneaker www.ecyaya.com (paypal payment)
+Edhardy Shoes sneaker www.ecyaya.com (wholesale cheap)
man-shoes sneaker www.ecyaya.com
canvas-low-shoes sneaker www.ecyaya.com (paypal payment)
woman-shoes sneaker www.ecyaya.com (wholesale cheap)
Casual-shoes sneaker www.ecyaya.com (paypal payment)
canvas-high-shoes sneaker www.ecyaya.com (wholesale cheap)
+Gucci Shoes sneaker www.ecyaya.com
Gucci-size14 sneaker www.ecyaya.com (paypal payment)
Man-low-shoes sneaker www.ecyaya.com (wholesale cheap)
woman-high-shoes sneaker www.ecyaya.com (paypal payment)
Gucci-shoes-A sneaker www.ecyaya.com (wholesale cheap)
Man-high-shoes sneaker www.ecyaya.com
woman-low-shoes sneaker www.ecyaya.com (paypal payment)
+Lacoste Shoes sneaker www.ecyaya.com (wholesale cheap)
Lacoste-woman-shoes sneaker www.ecyaya.com
Lacoste-man-shoes sneaker www.ecyaya.com (paypal payment)
Lacoste-white-man sneaker www.ecyaya.com
+Prada Shoes sneaker www.ecyaya.com
Prada-shoes sneaker www.ecyaya.com (wholesale cheap)
+Chanel Shoes sneaker www.ecyaya.com (paypal payment)
Chanel woman shoes sneaker www.ecyaya.com
+Coach Shoes sneaker www.ecyaya.com (wholesale cheap)
Coach-woman-shoes sneaker www.ecyaya.com (paypal payment)
Coach-man-shoes sneaker www.ecyaya.com
+D&G Shoes sneaker www.ecyaya.com " (wholesale cheap)
"Jeans Series<www.ecyaya.com >
Evisu Jeans Series<www.ecyaya.com > (paypal payment)
Christina Audigier Jeans Series<www.ecyaya.com

ZEN Jeans Series<www.ecyaya.com > (wholesale cheap)
Levis Jeans Series<www.ecyaya.com> (paypal payment)
Iceberg Jeans Series<www.ecyaya.com>
Black-Lable Jeans Series<www.ecyaya.com > (wholesale cheap)
True Religion Jeans Series<www.ecyaya.com (paypal payment)

Laguna Jeans Series<www.ecyaya.com >
G-star Jeans Series<www.ecyaya.com > (wholesale cheap)
Diesel Jeans Series<www.ecyaya.com > (paypal payment)
Bape Jeans Series<www.ecyaya.com > (wholesale cheap)
LV Jeans Series<www.ecyaya.com
D&G Jeans Series<www.ecyaya.com > (paypal payment)
Coogi Jeans Series<www.ecyaya.com > (wholesale cheap)
Cavalli Jeans Series<www.ecyaya.com >
Artful-Dodger-Jeans Jeans Series<www.ecyaya.com (paypal payment)

RMC Jeans Series<www.ecyaya.com > (wholesale cheap)
Gucci Jeans Series<www.ecyaya.com> (paypal payment)
Ed hardy Jeans Series<www.ecyaya.com > (wholesale cheap)
Armani Jeans Series<www.ecyaya.com>
BBC Jeans Series<www.ecyaya.com> (paypal payment)
Prada Jeans Series<www.ecyaya.com > (wholesale cheap)
"
"T-shirt www.ecyaya.com
D&G T-shirt www.ecyaya.com (paypal payment)
Bape T-shirt www.ecyaya.com
Smet T-shirt www.ecyaya.com (paypal payment)
LV T-shirt www.ecyaya.com
Jungle T-shirt www.ecyaya.com (wholesale cheap)
Gucci T-shirt www.ecyaya.com(paypal payment)
Burberry T-shirt www.ecyaya.com
Ed hardy T-shirt www.ecyaya.com (wholesale cheap)
Christina Audigier T-shirt www.ecyaya.com (paypal payment)
Adidas T-shirt www.ecyaya.com (wholesale cheap)
Polo T-shirt www.ecyaya.com (paypal payment)
Lacoste T-shirt www.ecyaya.com
Juicy T-shirt www.ecyaya.com (wholesale cheap)
G-star T-shirt www.ecyaya.com (paypal payment)
BBC T-shirt www.ecyaya.com
Affliction T-shirt www.ecyaya.com (paypal payment)
Armani T-shirt www.ecyaya.com" (wholesale cheap)

== 2 of 2 ==
Date: Wed, Feb 3 2010 12:27 am
From: hero

◈•_•◈ Hot sale cheap shoes, T-shirts, handbags, purses, caps,
underwears etc www.ecyaya.com FASHION !!!

==============================================================================
TOPIC: Incomplete types and std::vector
http://groups.google.com/group/comp.lang.c++/t/b0741c38fc15b5f7?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 12:39 am
From: Vladimir Jovic

James Kanze wrote:
> That's not the issue, at least not formally. The standard
> clearly says that it is undefined behavior to instantiate any of
> the templates defined in the standard over an undefined type.
> Typically, auto_ptr will only need to know the complete type in
> the destructor, and you will get away with it if the destructor
> of the pimpl is not inlined. But that's just a case of
> undefined behavior happening to work, and you won't get away
> with it if the implementation uses concepts. (And the next
> version of the standard will, I think, require a diagnostic. At
> least if concepts make it in.)

I have no idea what are concepts, but does it mean that the compilation
of the code using pimpl is going to fail with the c++0x?

==============================================================================
TOPIC: ◆⊙◆ Cheap wholesale Chanel scarf, Burberry Scarf, LV scarf ect at www.
rijing-trade.com <Paypal Payment>
http://groups.google.com/group/comp.lang.c++/t/a7e4516ddd40dce0?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 12:40 am
From: "www.fjrjtrade.com"

◆⊙◆ Cheap wholesale Chanel scarf, Burberry Scarf, LV scarf ect at
www.rijing-trade.com <Paypal Payment>

Cheap wholesale scarf at www.fjrjtrade.com

Cheap wholesale scarf

www.rijing-trade.com

Cheap wholesale Armani Scarf

www.rijing-trade.com

Cheap wholesale Burberry Scarf

www.rijing-trade.com

Cheap wholesale Chanel Scarf

www.rijing-trade.com

Cheap wholesale CK Scarf

www.rijing-trade.com

Cheap wholesale D&G Scarf

www.rijing-trade.com

Cheap wholesale Dior Scarf

www.rijing-trade.com

Cheap wholesale Fendi Scarf

www.rijing-trade.com

Cheap wholesale Gucci Scarf

www.rijing-trade.com

Cheap wholesale LV Scarf

www.rijing-trade.com

Cheap wholesale Paul Smith Scarf

www.rijing-trade.com

Cheap wholesale Tous Scarf

www.rijing-trade.com

More models at website:
www.rijing-trade.com

==============================================================================
TOPIC: isspace
http://groups.google.com/group/comp.lang.c++/t/89ca303518428e34?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 3 2010 12:56 am
From: Jorgen Grahn

On Fri, 2010-01-29, Paavo Helde wrote:
...
> Or I could keep the text in UTF-8 and use my own custom function for
> checking for the whitespace, checking directly for all Unicode whitespace
> characters as listed in http://en.wikipedia.org/wiki/Whitespace_%
> 28computer_science%29, this seems to me much less error-prone than
> worrying if Russian locale and std::isspace are working correctly on all
> platforms.

Worrying? "I don't support doing analysis of Russian text on a
platform with broken Russian locales" sounds like something you can
happily say.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

== 2 of 2 ==
Date: Wed, Feb 3 2010 3:47 am
From: gervaz

On 3 Feb, 09:56, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> On Fri, 2010-01-29, Paavo Helde wrote:
>
> ...
>
> > Or I could keep the text in UTF-8 and use my own custom function for
> > checking for the whitespace, checking directly for all Unicode whitespace
> > characters as listed inhttp://en.wikipedia.org/wiki/Whitespace_%
> > 28computer_science%29, this seems to me much less error-prone than
> > worrying if Russian locale and std::isspace are working correctly on all
> > platforms.
>
> Worrying? "I don't support doing analysis of Russian text on a
> platform with broken Russian locales" sounds like something you can
> happily say.
>
> /Jorgen
>
> --
> // Jorgen Grahn <grahn@ Oo o. . .
> \X/ snipabacken.se> O o .

Ok, to summarize things learned so far:
UTF-8 can be handled by simply using std::string (henche char)
UTF-16 and UTF-32 handled by std::wstring and std::wchar_t but not
reliable because the type size is implementation-specific
Now, something like:

std::ifstream is;
const std::locale filelocale("Russian_Russia.1251");
is.imbue(filelocale);
is.open(argv[1]);

std::string s;
while(std::getline(is, s))
{
for (std::string::const_iterator it = s.begin(); it != s.end(); +
+it)
{
std::cout << *it;
if (std::isspace(*it, filelocale)) std::cout << "space found!"
<< std::endl;
}
std::cout << std::endl;
}

Works if we give as input a Russian text (althought the cout isn't
able to correctly display the russian characters).
If we are under Linux, something like

try
{
const std::locale filelocale("Russian_Russia.1251");
}
catch
{
try
{
const std::locale filelocale("ru_utf8");
}
catch
{
throw();
}
}

Can work? Any suggestion (I don't even know the specif exception that
have to be catch. Just experimenting...

Thanks, Mattia

==============================================================================
TOPIC: Static member vs global variable
http://groups.google.com/group/comp.lang.c++/t/39598a6a81930f50?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 1:50 am
From: Suneel VLN

On Feb 3, 11:43 am, tonydee <tony_in_da...@yahoo.co.uk> wrote:
> On Feb 3, 3:27 pm, Suneel VLN <suneelsuns...@gmail.com> wrote:
>
> > On Feb 3, 11:00 am, Rolf Magnus <ramag...@t-online.de> wrote:
> > > For objects with static storage duration, there are two types of
> > > initialization, static and dynamic. static initialization is done before
> > > dynamic initialization
>
> > in such case during static initialization will y be initialized to 0?
>
> I don't think the Standard guarantees that... my recollection is
> compilers are free to use uninitialised/reclaimed memory for static
> variables that are to be dynamically initialised. That would seem
> more efficient - why initialise something twice?
>
> Cheers,
> Tony

OK. If that is the case, then x will be initialized statically during
program loading and y will be initialized dynamically during program
execution.

Could anybody answer my other question...

> static x is a private member inside a class. How come it was in
> closest scope at that line?

Thanks,
--Suneel VLN.

==============================================================================
TOPIC: system("ls")
http://groups.google.com/group/comp.lang.c++/t/ea8887c99b1a8b02?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 3:49 am
From: Jorgen Grahn

On Sat, 2010-01-30, Klaus ter Fehn wrote:
> Matko <mklaic@foi.hr> wrote:
>> Is there a better way to get data returned by 'ls' command instead of
>> 'system("ls > file.txt");' and then reading the file. I'm thinking of
>> something that would return 'const char *' into my buffer.
>
> If you insist on using 'ls' then using a pipe would be best. Otherwise
> try get the informations you need by using system calls or other library
> functions into your program - that would be much faster.

Maybe not so much *faster*, but safer. 'ls' formats the listing for
printing, but file names with odd characters (like '\n') will break,
if he intends to parse and *use* the listing.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

==============================================================================
TOPIC: struct containing vector?
http://groups.google.com/group/comp.lang.c++/t/d0ba6cd9c3737991?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 3:57 am
From: Bart van Ingen Schenau

On Feb 1, 5:45 pm, cerr <ron.egg...@gmail.com> wrote:
> Hi There,
>
> I have a little issue going here:
> I have a xml configuration file that looks kinda like this:
<snip>
> string strPID = xmlPIDData.GetNodeData("PID"); //PID
> while (strPID.size() > 0) {
> RSXMLParser xmlPID(strPID); //PID details
> structPID tmpPID;
<snip>
> i_PIDlist->push_back(tmpPID);
> //delete tmpPID;
> //tmpPID=NULL;
>
> strPID = xmlPIDData.GetNext();
> }
>
> return true;}
>
> But there's two problems i'm seeing just right out of the bat:
> If the outer while loop goes twice, how would tmpPID be re-declared?

These is no need to do anything special.
If the outer loop iterates multiple times, the brace-enclosed body of
the loop is entered and exited multiple times. At each entry, the
local variables are created anew by the compiler, and at each exit of
the loop body, they are destroyed.

So, if your loop iterates twice, then you will have two distinct
objects named tmpPID, with one being created after the other.

> I thought about declaring it on the heap and then calling delete in
> the end of the funtion before it loops around but even then,
> I would do a i_PIDlist->push_back(tmpPID) and it woudl push on a
> pionter that gets ereased soon after...
>
> Thanks for a little help and guidance here.
>
> Ron

Bart v Ingen Schenau

==============================================================================
TOPIC: ordered unordered_map
http://groups.google.com/group/comp.lang.c++/t/3743266d80703cfb?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 4:27 am
From: Ralf Goertz

tonydee wrote:

> On Feb 2, 10:30 pm, Ralf Goertz <r_goe...@usenet.arcornews.de> wrote:
>> Pete Becker wrote:
>>
>> > If you're willing to reorganize the container, how about going a small
>> > step further and replacing it at that point with an ordered container?
>>
>> It seems I will have to do that then, thanks.
>
> It's a good, simple solution in most cases. If the objects are large
> and keys small and your RAM limited, and/or that final step is
> performance critical too, consider
> - keeping the data in an ordered map, but adding an unordered (hash)
> map indexing from key to ordered-map iterator
> - keep the data in a vector, and having unordered and ordered maps
> from key to index
> - looking at boost's multi-indexed container library, which can manage
> the synchronisation of data and indices for you

These are worth trying, especially since I still need to find() in the
map. The reason why I want an ordered iterator is that I'd like to
compare all elements with each other and erase duplicate (type Foo)
values keeping the one with the lower (type unsigned) key (it is more
complicated than that but you get the point). So I use two nested loops:

typedef unordered_map<unsigned, Foo> Map;
typedef unordered_set<unsigned> Set;
Map m;
Map::iterator i1,i2;
Set s;
Set::iterator i3;

void find_elements_in_m_that_need_to_be_compared(unsigned to_this_element,Set&);

bool foo_equal(const Foo &,const Foo&);

for (i1=m.begin();i1!=m.end();++i1) {
find_elements_in_m_that_need_to_be_compared(i1->first,s);
for (i3=s.begin();i3!=s.end();++i3) {
i2=m.find(*i3);
if (foo_equal(i1->second,i2->second)) {
m.erase(i2); // (*)
}
}
}

Since m is not ordered, I cannot be sure that i1->first is less than
i2->first. Therefore I might erase the object with the lower key at (*).
OTOH unordered_map has an erase(iterator, iterator) member function.
This function seems to be of little use since the key 42 might be in the
range [8,15).

==============================================================================
TOPIC: What are the key differences between operator new and operator new[]?
http://groups.google.com/group/comp.lang.c++/t/0711f4e6de411900?hl=en
==============================================================================

== 1 of 6 ==
Date: Wed, Feb 3 2010 4:34 am
From: xmllmx

Dear all,

As we know, the C++ standard defines at least four special global
functions as follows:

1) void* operator new(size_t);

2) void* operator new[](size_t);

3) void operator delete(void*);

4) void operator delete[](void*);

In Visual C++, 2) and 4) simply forward their respective call to 1)
and 3). Obviously, 1) and 3) are equivalents respectively to malloc
and free in C. However, when and why should we call 2) and 4)?

Though 2) and 4) are not harmful, but I think them rather ugly.
Because I can not find any necessity of them.

I hope someone can give me a convincing explanation? Thanks in
advance!

== 2 of 6 ==
Date: Wed, Feb 3 2010 4:57 am
From: "Fred Zwarts"

"xmllmx" <xmllmx@gmail.com> wrote in message
news:26104060-3bf4-4be0-b207-e39b4b0f1187@b36g2000pri.googlegroups.com
> Dear all,
>
> As we know, the C++ standard defines at least four special global
> functions as follows:
>
> 1) void* operator new(size_t);
>
> 2) void* operator new[](size_t);
>
> 3) void operator delete(void*);
>
> 4) void operator delete[](void*);
>
> In Visual C++, 2) and 4) simply forward their respective call to 1)
> and 3). Obviously, 1) and 3) are equivalents respectively to malloc
> and free in C.
>
> However, when and why should we call 2) and 4)?

Normally, you don't call these operators explicitly, but you use
new and new [] to create new objects and delete and delete [] to
destroy objects. In these cases there is much more than just malloc
and free. In addition to allocating memory, new and new [] call
constructors to create objects and in addtion to freeing memory,
delete and delete[] call destructors to destroy objects.
2) and 4) should be used for arrays. They call the constructors,
resp. destructors for all array elements, whereas new and delete
call only one constructor, resp. destructor.

> Though 2) and 4) are not harmful, but I think them rather ugly.
> Because I can not find any necessity of them.

That is probabbly, because you think they only allocate/free memory,
but they are used for many more functionality.

> I hope someone can give me a convincing explanation? Thanks in
> advance!

I hope this is convincing.

== 3 of 6 ==
Date: Wed, Feb 3 2010 5:24 am
From: xmllmx

On Feb 3, 8:57 pm, "Fred Zwarts" <F.Zwa...@KVI.nl> wrote:
> "xmllmx" <xml...@gmail.com> wrote in message
>
> news:26104060-3bf4-4be0-b207-e39b4b0f1187@b36g2000pri.googlegroups.com
>
>
>
>
>
> > Dear all,
>
> > As we know, the C++ standard defines at least four special global
> > functions as follows:
>
> > 1) void* operator new(size_t);
>
> > 2) void* operator new[](size_t);
>
> > 3) void operator delete(void*);
>
> > 4) void operator delete[](void*);
>
> > In Visual C++, 2) and 4) simply forward their respective call to 1)
> > and 3). Obviously, 1) and 3) are equivalents respectively to malloc
> > and free in C.
>
> > However, when and why should we call 2) and 4)?
>
> Normally, you don't call these operators explicitly, but you use
> new and new [] to create new objects and delete and delete [] to
> destroy objects. In these cases there is much more than just malloc
> and free. In addition to allocating memory, new and new [] call
> constructors to create objects and in addtion to freeing memory,
> delete and delete[] call destructors to destroy objects.
> 2) and 4) should be used for arrays. They call the constructors,
> resp. destructors for all array elements, whereas new and delete
> call only one constructor, resp. destructor.
>
> > Though 2) and 4) are not harmful, but I think them rather ugly.
> > Because I can not find any necessity of them.
>
> That is probabbly, because you think they only allocate/free memory,
> but they are used for many more functionality.
>
> > I hope someone can give me a convincing explanation? Thanks in
> > advance!
>
> I hope this is convincing.

Many thanks to your quick response.

I think you may misunderstand what I mean. I fully know the difference
between malloc/free and new/delete. I don't know if you know the fact:
1) operator new(size_t); totally differs from a new expression. Let me
illustrate that in source code:

struct CTest
{
CTest()
{
std::cout << "Call CTest::ctor();" << std::endl;
}

~CTest()
{
std::cout << "Call CTest::dtor(); " << std::endl;
}
};

int main()
{
CTest* p = new CTest; // 1)
delete p; // 2)

void* p2 = operator new(sizeof(CTest)); // 3)
operator delete(p2); // 4)

return 0;
}

The statements 1) and 2) will implicitly call the constructor and
destructor of CTest. However, statements 3) and 4) will never
implicitly call any other member functions of CTest. 3) is totally
equal to void* p2 = malloc(sizeof(CTest)); and 4) to free(p2);

== 4 of 6 ==
Date: Wed, Feb 3 2010 5:33 am
From: Hang Dog

xmllmx wrote:
> On Feb 3, 8:57 pm, "Fred Zwarts" <F.Zwa...@KVI.nl> wrote:
>> "xmllmx" <xml...@gmail.com> wrote in message
>>
>> news:26104060-3bf4-4be0-b207-e39b4b0f1187@b36g2000pri.googlegroups.com
>>
>>
>>
>>
>>
>>> Dear all,
>>> As we know, the C++ standard defines at least four special global
>>> functions as follows:
>>> 1) void* operator new(size_t);
>>> 2) void* operator new[](size_t);
>>> 3) void operator delete(void*);
>>> 4) void operator delete[](void*);
>>> In Visual C++, 2) and 4) simply forward their respective call to 1)
>>> and 3). Obviously, 1) and 3) are equivalents respectively to malloc
>>> and free in C.
>>> However, when and why should we call 2) and 4)?
>> Normally, you don't call these operators explicitly, but you use
>> new and new [] to create new objects and delete and delete [] to
>> destroy objects. In these cases there is much more than just malloc
>> and free. In addition to allocating memory, new and new [] call
>> constructors to create objects and in addtion to freeing memory,
>> delete and delete[] call destructors to destroy objects.
>> 2) and 4) should be used for arrays. They call the constructors,
>> resp. destructors for all array elements, whereas new and delete
>> call only one constructor, resp. destructor.
>>
>>> Though 2) and 4) are not harmful, but I think them rather ugly.
>>> Because I can not find any necessity of them.
>> That is probabbly, because you think they only allocate/free memory,
>> but they are used for many more functionality.
>>
>>> I hope someone can give me a convincing explanation? Thanks in
>>> advance!
>> I hope this is convincing.
>
> Many thanks to your quick response.
>
> I think you may misunderstand what I mean. I fully know the difference
> between malloc/free and new/delete. I don't know if you know the fact:
> 1) operator new(size_t); totally differs from a new expression. Let me
> illustrate that in source code:
>
> struct CTest
> {
> CTest()
> {
> std::cout << "Call CTest::ctor();" << std::endl;
> }
>
> ~CTest()
> {
> std::cout << "Call CTest::dtor(); " << std::endl;
> }
> };
>
> int main()
> {
> CTest* p = new CTest; // 1)
> delete p; // 2)
>
> void* p2 = operator new(sizeof(CTest)); // 3)
> operator delete(p2); // 4)
>
> return 0;
> }
>
> The statements 1) and 2) will implicitly call the constructor and
> destructor of CTest. However, statements 3) and 4) will never
> implicitly call any other member functions of CTest. 3) is totally
> equal to void* p2 = malloc(sizeof(CTest)); and 4) to free(p2);

????

As void doesn't have a ctor or dtor why would one expect the compiler to
generate any other function to be called when you pass them a void*.
That of course isn't the case when you are dealing with pointers to
objects. In that case the compiler knows to call the ctor and dtor.

== 5 of 6 ==
Date: Wed, Feb 3 2010 5:43 am
From: Stephen Howe

>Normally, you don't call these operators explicitly, but you use
>new and new [] to create new objects and delete and delete [] to
>destroy objects. In these cases there is much more than just malloc
>and free. In addition to allocating memory, new and new [] call
>constructors to create objects and in addtion to freeing memory,
>delete and delete[] call destructors to destroy objects.
>2) and 4) should be used for arrays. They call the constructors,
>resp. destructors for all array elements, whereas new and delete
>call only one constructor, resp. destructor.

No they do not.

You are not distinguishing between a new expression and operator new,
The new expression does exactly what you describe above and you cannot alter its behaviour.

But the OP is asking about operator new and all that does is aquire raw memory.
operator new is called by the new expression to obtain memory.

Cheers

Stephen Howe

== 6 of 6 ==
Date: Wed, Feb 3 2010 6:07 am
From: Victor Bazarov

xmllmx wrote:
> As we know, the C++ standard defines at least four special global
> functions as follows:
>
> 1) void* operator new(size_t);
>
> 2) void* operator new[](size_t);
>
> 3) void operator delete(void*);
>
> 4) void operator delete[](void*);
>
> In Visual C++, 2) and 4) simply forward their respective call to 1)
> and 3). Obviously, 1) and 3) are equivalents respectively to malloc
> and free in C. However, when and why should we call 2) and 4)?

*We* should *never* [have to] call them directly. They will be called
when you allocate an array of objects of some class type (if they are
overloaded for that class) or delete[] a pointer.

> Though 2) and 4) are not harmful, but I think them rather ugly.
> Because I can not find any necessity of them.

Have you ever tried overloading those? Read about custom allocators and
class-wide memory management, and you might find separating those useful.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

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

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

Wednesday, February 3, 2010

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

No comments:

Blog Archive

About Me