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

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

comp.lang.c++@googlegroups.com

Today's topics:

* Portability and marshalling integral data - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/d7831b8e84cbb8c3?hl=en
* ๑۩๑۩๑cheap wholesale brand shoes at www.ecyaya.com (paypal payment) - 2
messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/9fc2be3bcb46b206?hl=en
* Free shipping GHD MK4 MK5 cheap Wholesale, GHD hair straightener& Crimping
iron(www.vipchinatrade.com) - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/5fd2d60202d7a25c?hl=en
* ♡♪♡♪♡ 2009 New cheap wholesale Chanel scarf, D&G scarf, LV scarf ect at
website www.fjrjtrade.com <Paypal Payment> - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/3aae0a4076d693b0?hl=en
* Writing good articles that have much better chance to be seen by others - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/ddbe20a354342370?hl=en
* prefix increment operator and side-effects - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/a9ceda48b98581d8?hl=en
* Locale to Unicode Codepoint mapping? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/0f87b730b24e407a?hl=en
* Q: Free compiler for 64 bit Windows 7? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/5f665081d6a6b15e?hl=en
* workaround for auto_ptr<> in STL containers? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/ea539aaeae39cd19?hl=en
* compilation error with default argument - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/482543c071bd94fa?hl=en
* Different types of cast - 4 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/b5b881bc79379355?hl=en
* C++ jobs down another 40% - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/6718a9cd2f3ecdbf?hl=en
* Exception Misconceptions: Exceptions are for unrecoverable errors. - 8
messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/786cfdf0ab25866d?hl=en

==============================================================================
TOPIC: Portability and marshalling integral data
http://groups.google.com/group/comp.lang.c++/t/d7831b8e84cbb8c3?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Dec 24 2009 11:32 pm
From: Brian

On Nov 25, 4:10 am, James Kanze <james.ka...@gmail.com> wrote:
> On Nov 24, 10:41 pm, Brian <c...@mailvault.com> wrote:
>
>
>
>
>
> > On Nov 24, 4:30 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> > > Brian <c...@mailvault.com> wrote in news:2ff925d9-9d6f-4285-b0d2-
> > > 8175bb0a0...@u20g2000vbq.googlegroups.com:
> > > > I'm wondering if it is possible to set things up so that
> > > > the more portable functions are used in a more limited way
> > > > than what I've seen suggested here. For example if a
> > > > server has both big endian and little endian (Intel)
> > > > clients, would it work to have the server send a "big
> > > > endian" stream to the big endian clients and a "little
> > > > endian" stream to Intel clients -- then both of those
> > > > types of clients could use memcpy to read/demarshall
> > > > integral data types?
> > > Are you seriously claiming that a data stream can be pumped
> > > over the network faster than the client can do some
> > > bitshifting?
> > No, I'm saying it seems like there's a way to eliminate the
> > need for bit shifting when reading data. It isn't clear to me
> > what (portability) is lost by doing it that way.
>
> It's possible for the server to systematically send and receive
> data in the internal format of the client, yes. Provided it
> knows this format (the client tells it). Does it buy you
> anything? I'm not really sure.
>
> The issue is particularly important with regards to floating
> point; if the protocol specifies a format with a fixed maximum
> precision (e.g.IEEEdouble), and the machines at both ends
> both support higher precision, then information is lost
> unnecessarily.
>
> In this regard, you might be interested in theBERencoding of
> RealType. In the case ofBER, the goal is to not loose
> precision unless necessary, so the rule is always to use the
> sender's format, with the receiver interpreting it.

In retrospect, I wish I had done things this way. Instead I
made senders format for byte order. I'm in the process
now of changing it to "always use the sender's format."

A week or so ago I made my Buffer class a class template
parameterized on the byte order.
http://webEbenezer.net/misc/Buffer.hh
http://webEbenezer.net/misc/Formatting.hh

I've also added a tar file now that has these files
http://webEbenezer.net/misc/direct.tar.bz2

Anyway, I thought everything was going fine with that.
For example, http://webEbenezer.net/misc/File.hh, shows
how using function templates handle things nicely for a
stream constructor and a Send function. But then I
remembered that the Send functions can be virtual.
Since C++ doesn't currently support mixing function
templates and virtual functions, I was forced to
change my approach.

Thankfully, there seems to be a way to avoid resorting
to class templates (for all of the classes involved in
marshalling) which permit the use of virtual functions.
I'm thinking about splitting up the Buffer class into
two classes: SendBuffer and ReceiveBuffer. (The names
may change.) SendBuffer would be a plain class and
ReceiveBuffer would be a class template parameterized on
the byte order. The stream constructors would be
function templates still, but the Send functions wouldn't
be and they could still be virtual. I've liked having one
Buffer class that was used for both sending and receiving,
but I really dislike the idea of requiring all user
classes (that are marshalled) to be class templates.
This seems like a reasonable way to deal with the
various factors. I'm curious whether others have one or
two classes involved in buffering. So now I'm hoping to
not do any formatting when sending data and leave that
up to the receiving code.

I spent quite a bit of time working things out the
other way, so it is taking me a while to rework
things. I don't think of it as totally wasted time,
since the two implementations are similar. Perhaps
though I should have caught this earlier and avoided
the need to rework things. So often I'm reminded of
the saying, "Better late than never."

Brian Wood
http://webEbenezer.net

==============================================================================
TOPIC: ๑۩๑۩๑cheap wholesale brand shoes at www.ecyaya.com (paypal payment)
http://groups.google.com/group/comp.lang.c++/t/9fc2be3bcb46b206?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Dec 25 2009 12:32 am
From: hero

๑۩๑۩๑cheap wholesale brand shoes at www.ecyaya.com (paypal payment)

Cheap Wholesale Gucci Shoes (paypal payment)
(www.ecyaya.com.cn )
Cheap Wholesale GUCCI Boots
Cheap Wholesale Lacoste Shoes
Cheap Wholesale LV Shoes (paypal payment)
(www.ecyaya.com.cn )
Cheap Wholesale LV Boots
Cheap Wholesale Prada Shoes (paypal payment)
(www.ecyaya.com.cn )
Cheap Wholesale Timberland Shoes
Cheap Wholesale D&G Shoes (paypal payment)
(www.ecyaya.com.cn )
Cheap Wholesale D&G Boots
Cheap Wholesale Puma Shoes
Cheap Wholesale Puma AAA (paypal payment)
(www.ecyaya.com.cn )
Cheap Wholesale UGG Boots Shoes
Cheap Wholesale Bikkem Bergs Shoes (free shipping)
Cheap Wholesale Mauri Shoes Man
Cheap Wholesale Versace Shoes (paypal payment)
(www.ecyaya.com.cn )
Cheap Wholesale Versace Boots
Cheap Wholesale Paul Smith Shoes (free shipping)
Cheap Wholesale BOSS Shoes
Cheap Wholesale Burberry Shoes (paypal payment)
(www.ecyaya.com.cn )
Cheap Wholesale Dsquared shoes
Cheap Wholesale Dior Shoes (free shipping)
Cheap Wholesale Dior Boots
Cheap Wholesale ED Hardy Shoes (paypal payment)
(www.ecyaya.com.cn )
Cheap Wholesale ED Hardy Boots
Cheap Wholesale ED Hardy Shoes Man (paypal payment)
(www.ecyaya.com.cn )
Cheap Wholesale Fendi Shoes (paypal payment)
(www.ecyaya.com.cn )
Cheap Wholesale Fendi Boots
Cheap Wholesale AFF Shoes (paypal payment)
(www.ecyaya.com.cn )
Cheap Wholesale Evisu Shoes (free shipping)
Cheap Wholesale 4US Shoes
Cheap Wholesale Sebago Shoes (paypal payment)
(www.ecyaya.com.cn )
Cheap Wholesale Supra Shoes
Cheap Wholesale Hight Converse Shoes (paypal payment)
(www.ecyaya.com.cn )
Cheap Wholesale Coach Boots
Cheap Wholesale Coach Shoes
Women Christian Louboutin (paypal payment)
(www.ecyaya.com.cn )
Cheap Wholesale Chanel Shoes
Cheap Wholesale Chanel Boots (free shipping)
Cheap Wholesale Bape Shoes
Cheap Wholesale Adidas Shoes (paypal payment)
(www.ecyaya.com.cn )
Cheap Wholesale Adicolor (free shipping)
Cheap Wholesale Adidas 35TH (paypal payment)
(www.ecyaya.com.cn )
Cheap Wholesale Adidas NBA
Cheap Wholesale Adidas Running (paypal payment)
(www.ecyaya.com.cn )
Cheap Wholesale Adidas Y3
Cheap Wholesale Soccer Shoes (paypal payment)
(www.ecyaya.com.cn )

== 2 of 2 ==
Date: Fri, Dec 25 2009 12:32 am
From: hero

๑۩๑۩๑cheap wholesale brand shoes at www.ecyaya.com (paypal payment)

==============================================================================
TOPIC: Free shipping GHD MK4 MK5 cheap Wholesale, GHD hair straightener&
Crimping iron(www.vipchinatrade.com)
http://groups.google.com/group/comp.lang.c++/t/5fd2d60202d7a25c?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Dec 25 2009 12:41 am
From: cava

Free shipping GHD MK4 MK5 cheap Wholesale, GHD hair straightener
Wholesale(www.vipchinatrade.com)

Cheap Benefit GHD (www.vipchinatrade.com)

Cheap Black GHD (www.vipchinatrade.com)

Cheap Dark GHD (www.vipchinatrade.com)

Cheap pink GHD (www.vipchinatrade.com)

Cheap new style Leopard GHD (www.vipchinatrade.com)

Cheap IV mini styler GHD (www.vipchinatrade.com)

Cheap rare Leopard GHD (www.vipchinatrade.com)

Cheap rare newest Leopard style (www.vipchinatrade.com)

Cheap Gold GHD (www.vipchinatrade.com)

Cheap Kiss GHD (www.vipchinatrade.com)

Cheap pink MK5 (www.vipchinatrade.com)

Cheap black GHD (www.vipchinatrade.com)

Cheap limited edition MK5 (www.vipchinatrade.com)

Cheap pure black GHD MK5 (www.vipchinatrade.com)

Cheap pure white GHD (www.vipchinatrade.com)

Cheap Pink style GHD (www.vipchinatrade.com)

Cheap Purple style GHD with dryer (www.vipchinatrade.com)

Cheap Salon GHD (www.vipchinatrade.com)

CHI

Cheap Ammy green CHI (www.vipchinatrade.com)

Cheap Black style CHI (www.vipchinatrade.com)

Cheap Blue style CHI (www.vipchinatrade.com)

Cheap Camouflage Blue CHI (www.vipchinatrade.com)

Cheap Camouflage pink CHI (www.vipchinatrade.com)

Cheap Peachblow CHI (www.vipchinatrade.com)

Cheap Pink style CHI (www.vipchinatrade.com)

Cheap Red-black CHI (www.vipchinatrade.com)

Cheap Wide red-black CHI(www.vipchinatrade.com)

Cheap crimping iron (www.vipchinatrade.com)

==============================================================================
TOPIC: ♡♪♡♪♡ 2009 New cheap wholesale Chanel scarf, D&G scarf, LV scarf ect at
website www.fjrjtrade.com <Paypal Payment>
http://groups.google.com/group/comp.lang.c++/t/3aae0a4076d693b0?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Dec 25 2009 12:59 am
From: "www.fjrjtrade.com"

♡♪♡♪♡ 2009 New cheap wholesale Chanel scarf, D&G scarf, LV scarf ect
at website www.fjrjtrade.com <Paypal Payment>

Cheap wholesale scarf at www.fjrjtrade.com

Cheap wholesale scarf

http://www.fjrjtrade.com/2102-Scarf.html

Cheap wholesale Armani Scarf

http://www.fjrjtrade.com/2103-Armani-Scarf.html

Cheap wholesale Burberry Scarf

http://www.fjrjtrade.com/2104-Burberry-Scarf.html

Cheap wholesale Chanel Scarf

http://www.fjrjtrade.com/2105-Chanel-Scarf.html

Cheap wholesale CK Scarf

http://www.fjrjtrade.com/2106-CK-Scarf.html

Cheap wholesale D&G Scarf

http://www.fjrjtrade.com/2107-DG-Scarf.html

Cheap wholesale Dior Scarf

http://www.fjrjtrade.com/2108-Dior-Scarf.html

Cheap wholesale Fendi Scarf

http://www.fjrjtrade.com/2109-Fendi-Scarf.html

Cheap wholesale Gucci Scarf

http://www.fjrjtrade.com/2110-Gucci-Scarf.html

Cheap wholesale LV Scarf

http://www.fjrjtrade.com/2111-LV-Scarf.html

Cheap wholesale Paul Smith Scarf

http://www.fjrjtrade.com/2112-Paul-Smith-Scarf.html

Cheap wholesale Tous Scarf

http://www.fjrjtrade.com/2113-Tous-Scarf.html

More models at website:
http://www.fjrjtrade.com

==============================================================================
TOPIC: Writing good articles that have much better chance to be seen by others
http://groups.google.com/group/comp.lang.c++/t/ddbe20a354342370?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Dec 25 2009 3:13 am
From: Krice

On 25 joulu, 04:31, ta...@mongo.net (tanix) wrote:
> >> If you think YOUR ego is the most important thing in the
> >> world, think again.
> >Yes please, think it again.
> Yep, that is exactly what I mean.

Are you slow? YOU think it, you moron.

==============================================================================
TOPIC: prefix increment operator and side-effects
http://groups.google.com/group/comp.lang.c++/t/a9ceda48b98581d8?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Dec 25 2009 4:10 am
From: James Kanze

On Dec 23, 3:12 pm, "subramanian10...@yahoo.com, India"
<subramanian10...@yahoo.com> wrote:
> Stroustrup in his book "The C++ Programming Language - Third
> Edition (NOT the special third edition)", mentions the
> following in page 125 in section "6.2.5 Increment and
> Decrement". "By definition, ++lvalue means lvalue += 1, which
> again means lvalue = lvalue + 1 provided lvalue has no
> side-effects".

> Here I am unable to understand why Stroustrup has mentioned
> "provided lvalue has no side-effects". Isn't the expression
> ++lvalue the same as lvalue = lvalue + 1 always ? Kindly
> clarify with an example.

int* p;
++(*p ++); // which is NOT the same as:
*p ++ = *p ++ + 1; // undefined behavior...

--
James Kanze

==============================================================================
TOPIC: Locale to Unicode Codepoint mapping?
http://groups.google.com/group/comp.lang.c++/t/0f87b730b24e407a?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Dec 25 2009 4:17 am
From: James Kanze

On Dec 23, 6:27 pm, "Peter Olcott" <NoS...@SeeScreen.com> wrote:
> I need to know the set of Unicode codepoints associated with
> every regional dialect of a human language. How can I go
> about finding this information?

www.unicode.org. Go to the code charts under the standard.

In general, for such things, look for the reference site. This
one is actually very well done, but even in the case of those
that are less well done, the reference is the reference.

--
James Kanze

== 2 of 2 ==
Date: Fri, Dec 25 2009 6:06 am
From: "Peter Olcott"

"James Kanze" <james.kanze@gmail.com> wrote in message
news:991f32d8-319c-45ad-9b9c-12a7f2a3daef@s31g2000yqs.googlegroups.com...
> On Dec 23, 6:27 pm, "Peter Olcott" <NoS...@SeeScreen.com>
> wrote:
>> I need to know the set of Unicode codepoints associated
>> with
>> every regional dialect of a human language. How can I go
>> about finding this information?
>
> www.unicode.org. Go to the code charts under the
> standard.
>
> In general, for such things, look for the reference site.
> This
> one is actually very well done, but even in the case of
> those
> that are less well done, the reference is the reference.
>
> --
> James Kanze

I already studied these for many hours. They do not have
what I need. I need to know the exact subset of Unicode code
points that apply to a specific dialect of a specific
language. A superset of these will not do, I must have the
minimum set of code points. This has to be known because the
keyboard must know which glyphs to produce.

I am working on internationalizing this system:
www.OCR4Screen.com

==============================================================================
TOPIC: Q: Free compiler for 64 bit Windows 7?
http://groups.google.com/group/comp.lang.c++/t/5f665081d6a6b15e?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Dec 25 2009 4:30 am
From: James Kanze

On Dec 23, 5:43 pm, "Bo Persson" <b...@gmb.dk> wrote:
> tanix wrote:

[...]
> The moderated list was started by people who couldn't stand reading
> the unmoderated list at the time. It's your choice which groups you
> want to follow.

> Nowadays many of us (including most of the moderators :-) actually
> read both groups, just not to miss any interesting topics.

Some historical context might be interesting. The moderated
group was founded because this group became pretty much
unusable, because of too many off topic postings. I was one of
the founders: I hate censorship, but at the time, it was that or
not having any usable group at all.

Since then, things have changed: all of the newbies have moved
on to other mechanisms, and with some exceptions, leave
newsgroups alone. The result is that this group has become
usable again. That, coupled with the fact that moderation in
the moderated group has become more heavy handed than I
originally envisaged it, means that I pretty much only
participate here, and not in the moderated group. But... I
would like for this group to remain usable, and that means some
degree of self moderation. An occasional off topic posting, or
even a thread which derives completely off topic, doesn't hurt
that much, but it can't become a regular thing, or the group
becomes unusable. (Similarly, overuse of personal insults and
ad hominum attacks renders the group less usable.) It's a fine
line, and I'd prefer that the non-moderated group remain usable.

And FWIW: I agree with Alf on this one, although it's a
borderline case. The question wasn't "what compilers are
available", but "what compilers are available for Windows".
Which is definitely Windows specific. But since it does concern
more than one implementation (potentially, at least, and in fact
in practice), I'd be in favor of stretching the rules.

--
James Kanze

==============================================================================
TOPIC: workaround for auto_ptr<> in STL containers?
http://groups.google.com/group/comp.lang.c++/t/ea539aaeae39cd19?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Dec 25 2009 4:40 am
From: James Kanze

On Dec 24, 8:34 am, Michael Doubez <michael.dou...@free.fr> wrote:
> On 23 déc, 20:07, Christof Warlich <cwarl...@gmx.de> wrote:
> > I'm stuck in a rather standard situation that may therefore
> > be best illustrated with a standard example, i.e. a graphics
> > library offering a bunch of shapes.

> > I want to allow the user to create shapes at _runtime_ as
> > desired, so all my shapes are derived from an abstract Shape
> > class, allowing me to both keep track of all the created
> > shape objects in a list and to clone new shape objects from
> > the available shapes depending on user input, e.g.:

> [snip]
> > struct Shape {
> > virtual ~Shape() {}
> > virtual Shape *Clone() = 0;
> > void Register() {Templates.push_back(this);}
> > static std::vector<Shape *> Templates;};

> > std::vector<Shape *> Shape::Templates;
> > struct Circle: Shape {
> > Circle() {Register();}
> > Circle(int radius) {std::cout << "Creating circle.\n";}
> > Circle *Clone() {
> > std::cout << "radius? " << std::flush;
> > int radius;
> > std::cin >> radius;
> > return new Circle(radius);
> > }
> > static Circle Template;};

> > Circle Circle::Template;
> > struct Rectangle: Shape {
> > Rectangle() {Register();}
> > Rectangle(int height, int width) {std::cout << "Creating
> > rectangle.\n";}
> > Rectangle *Clone() {
> > std::cout << "height, width? " << std::flush;
> > int height, width;
> > std::cin >> height >> width;
> > return new Rectangle(height, width);
> > }
> > static Rectangle Template;
> > };
> [snip]
> > In the example, I used pointer semantic to exploit
> > polymorphism, which is fine for this simple case, but
> > tracking deletion of objects quickly becomes difficult in
> > more complex scenarios.

> In which scenario. Your code doesn't expose how you
> un-register them. Registration is not even performed in all
> constructor.

That, of course, is the question. In the case of a lot of GUI
objects, lifetime is in some way related to the display.
Destruction should occur when the containing display object is
disposed of, and ceases to become displayable. It's a design
issue (since destruction could in some cases result in concrete
actions occuring; the object deregistering itself for mouse
events, for example).

Whether this is "difficult" is a matter open to discussion, but
it's an aspect that has to be addressed, at the design level.
(I see a containment hierarchy -- containment being used here in
its everyday sense, and not the OO sense. And I can't see where
the difficulty would come from.)

> > Thus, I considered using std::auto_ptr<> to overcome this,
> > but auto_ptr<> does not seem to be compatible with STL
> > containers, where I want to keep my shapes in some sort of
> > list.

auto_ptr also doesn't have the required semantics.

> > Any ideas how this (i.e. auto-deletion of unreferenced
> > objects) could be handled in a generic way while using STL
> > containers?

> How do you known you should auto-delete them ? They could be
> on the stack.

That's a question of the class' semantics. I think it
reasonable to forbid GUI types from being on the stack.

> IMO there is a design issue here rather than a technical one.

For starters, at least. Beyond that, I think that once the
design issues have been solved, the technical problems won't be
that difficult.

--
James Kanze

==============================================================================
TOPIC: compilation error with default argument
http://groups.google.com/group/comp.lang.c++/t/482543c071bd94fa?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Dec 25 2009 4:48 am
From: James Kanze

On Dec 24, 3:36 pm, "Balog Pal" <p...@lib.hu> wrote:
> <subramanian10...@yahoo.com>
> > void fn(int x = 7);
> > void fn(int = 7);
> > When I compiled this program with g++3.4.3 as
> > g++ -std=c++98 -pedantic -Wall -Wextra x.cpp,
> > I get the following compilation error:

> > x.cpp:6: error: default argument given for parameter 1 of `void fn
> > (int)'
> > x.cpp:5: error: after previous specification in `void fn(int)'

> > But Stroustrup in his book "The C++ Programming Language - Third
> > Edition(NOT the Special Third Edition)" has mentioned the following in
> > page 153 in section "7.5 Default Arguments":
> > A default argument can be repeated in a susequent declaration in the
> > same scope but not changed. Having this being stated, I do not
> > understand why the compiler is giving error. Have I misunderstood what
> > Sttroustrup has stated ? Kindly clarify.

> Dunno what BS meant, the standard doesn't allow redefining the
> same default param even to the same value (see example in
> 3.8.6p4 last words).

But IIRC, some earlier drafts did allow it. And the text of
"The C++ Programming Language" predates the final standard, and
may be based on one of those earlier drafts.

--
James Kanze

==============================================================================
TOPIC: Different types of cast
http://groups.google.com/group/comp.lang.c++/t/b5b881bc79379355?hl=en
==============================================================================

== 1 of 4 ==
Date: Fri, Dec 25 2009 4:54 am
From: James Kanze

On Dec 24, 5:53 am, Ravi <ra.ravi....@gmail.com> wrote:
> What is the difference between static cast and reinterpret cast?

The semantics. They do completely different things.

A static_cast requests a true conversion, int to double, for
example. When pointers are involved, it navigates up and down
the hierarchy. A reinterpret_cast requests the compiler to
interpret a value "as if" it had in fact some other type, to the
best of its ability. In a very real sense, it doesn't do any
conversion at all. It's use is pretty much limited to very low
level software, involving the underlying memory, and not the
objects themselves.

--
James Kanze

== 2 of 4 ==
Date: Fri, Dec 25 2009 5:00 am
From: James Kanze

On Dec 24, 9:16 am, Ian Collins <ian-n...@hotmail.com> wrote:
> Tomislav Novak wrote:
> > On 2009-12-24, Christof Warlich <cwarl...@gmx.de> wrote:
> >> Ravi wrote:
> >>> What is the difference between static cast and reinterpret cast?
> >> With static_cast you may only cast within the same inheritance
> >> hierarchy, i.e. it is more restrictive and thus somewhat safer.

> > static_cast also enables one to convert between types with
> > implicit or explicit conversion operators.

> >> dynamic_cast is similar, adding run-time checking and
> >> making the cast really safe.

> >> reinterpret_cast allows any cast.

> > Of course, it works for pointer types only (just to clarify further).

> No, it works for any type with the same size.

Size has nothing to do with it. For a reinterpret_cast to be
legal, one of its operands must be a pointer or a reference.
A pointer can also be cast to and from an integral type (with
some restrictions concerning whether it fits in such cases).

But as I said in my reponse to the OP, the important difference
is semantics: a reinterpret_cast has distinctly different
semantics from a static_cast, even in the cases where both are
legal.

> But it can't be used to cast away const or volatile.

That's true for all of the casts mentionned. (Note, however,
that since the result of a conversion is only an lvalue if the
conversion is to a reference, top level const or volatile is
irrelevant and ignored.)

--
James Kanze

== 3 of 4 ==
Date: Fri, Dec 25 2009 5:08 am
From: James Kanze

On Dec 24, 4:39 pm, "Johannes Schaub (litb)" <schaub-johan...@web.de>
wrote:
> Ian Collins wrote:
> > Tomislav Novak wrote:
> >> On 2009-12-24, Christof Warlich <cwarl...@gmx.de> wrote:
[...]
> >>> reinterpret_cast allows any cast.

> >> Of course, it works for pointer types only (just to clarify further).

> > No, it works for any type with the same size. But it can't
> > be used to cast away const or volatile.

> No, you are wrong. reinterpret_cast only allows very limited
> casts, like every other c++ cast does. It does, in particular
> allow not to do

> reinterpret_cast<unsigned char>('a'); // same size, eh?

That's true.

> And it does not allow casting to void* from another pointer,
> or from void* to another pointer.

Yes it does. It allows converting any object pointer type to
any other object pointer type (and in this context, void* is
considered an object type). Even if the two pointers have
different sizes, e.g. void* and int* on some machines. It also
allows converting any pointer to function type to any other
pointer to function type; it does not, however, allow converting
pointer to object (including void*) to or from pointer to
function, even if the two have the same size, as if often the
case (and is required by Posix, and I think at least indirectly
by Windows). Note that quite a few Unix compilers err here, and
accept the cast.

> It's just what its name is: It *reinterprets* pointer
> representations to integers, and object/member pointers among
> themselves.

> It also allows reinrerpreting arbitrary objects (disregarding
> their size) by using references: "reinterpret_cast<unsigned
> char&>(some_int)" is perfectly valid.

Yes, although in most cases, it's probably preferable to pass
through a pointer, e.g. reinterpret_cast< unsigned char* >(
&some_int ).

Here, size can affect the usability of the results:
reinterpret_cast< int& >( some_unsigned_char ) might be legal,
but using the results of the reinterpret_cast is undefined
behavior.

--
James Kanze

== 4 of 4 ==
Date: Fri, Dec 25 2009 6:04 am
From: "Johannes Schaub (litb)"

James Kanze wrote:

> On Dec 24, 4:39 pm, "Johannes Schaub (litb)" <schaub-johan...@web.de>
> wrote:
>> Ian Collins wrote:
>> > Tomislav Novak wrote:
>> >> On 2009-12-24, Christof Warlich <cwarl...@gmx.de> wrote:
> [...]
>> >>> reinterpret_cast allows any cast.
>
>> >> Of course, it works for pointer types only (just to clarify further).
>
>> > No, it works for any type with the same size. But it can't
>> > be used to cast away const or volatile.
>
>> No, you are wrong. reinterpret_cast only allows very limited
>> And it does not allow casting to void* from another pointer,
>> or from void* to another pointer.
>
> Yes it does. It allows converting any object pointer type to
> any other object pointer type (and in this context, void* is
> considered an object type). Even if the two pointers have
> different sizes, e.g. void* and int* on some machines. It also
> allows converting any pointer to function type to any other
> pointer to function type; it does not, however, allow converting
> pointer to object (including void*) to or from pointer to
> function, even if the two have the same size, as if often the
> case (and is required by Posix, and I think at least indirectly
> by Windows). Note that quite a few Unix compilers err here, and
> accept the cast.
>

void* is not a "pointer to an object" - it's a "pointer to void". The
reinterpret_cast paragraph precisely only allows casting for two pointers if
both are pointers to object types. There is no mentioning of void types.

The pointer type category is defined at 3.9.2/1 as "pointers to void or
objects or functions (including static members of classes) of a given type",
they are three different categories.

There was some work under way to define the word "object pointer" and use it
in reinterpret_cast to include "pointer to void" - but this work has not yet
been included into any draft. See http://www.open-
std.org/jtc1/sc22/wg21/docs/cwg_active.html#573

>> It's just what its name is: It *reinterprets* hointer
>> representations to integers, and object/member pointers among
>> themselves.
>
>> It also allows reinrerpreting arbitrary objects (disregarding
>> their size) by using references: "reinterpret_cast<unsigned
>> char&>(some_int)" is perfectly valid.
>
> Yes, although in most cases, it's probably preferable to pass
> through a pointer, e.g. reinterpret_cast< unsigned char* >(
> &some_int ).
>
> Here, size can affect the usability of the results:
> reinterpret_cast< int& >( some_unsigned_char ) might be legal,
> but using the results of the reinterpret_cast is undefined
> behavior.
>
Agreed - as in the spirit of 3.10/15

==============================================================================
TOPIC: C++ jobs down another 40%
http://groups.google.com/group/comp.lang.c++/t/6718a9cd2f3ecdbf?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Dec 25 2009 5:15 am
From: James Kanze

On Dec 23, 11:02 pm, red floyd <redfl...@gmail.com> wrote:
> On Dec 23, 12:50 pm, Jon Harrop <j...@ffconsultancy.com> wrote:

> > The number of job adverts in the UK citing C++ has fallen
> > 40% for the second year in a row:

> Hey, Jon! Wha'ts the market for F# jobs like?

There is one, albeit not as big as that for C++.

In practice, if you look at long term trends (and not short
swings), C++ is pretty safe for the future. With regards to F#,
it's too early to tell---the language hasn't been around long
enough to establish any long term trends,

--
James Kanze

==============================================================================
TOPIC: Exception Misconceptions: Exceptions are for unrecoverable errors.
http://groups.google.com/group/comp.lang.c++/t/786cfdf0ab25866d?hl=en
==============================================================================

== 1 of 8 ==
Date: Fri, Dec 25 2009 5:24 am
From: James Kanze

On Dec 23, 11:21 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
> tanix wrote:
> > In article <hgskgk$kc...@news.albasani.net>, Vladimir Jovic <vladasp...@gmail.com> wrote:
> > C++ would probably be benefited tremendously if it adopted some
> > of the central Java concept, such as GC, threads and GUI.

> GC is heavy performance killer especially on multiprocessor systems
> in combination with threads....it is slow, complex and inefficient...

Obviously, you've never actually measured. A lot depends on the
application, but typically, C++ with garbage collection runs
slightly faster than C++ without garbage collection. Especially
in a multi-threaded envirionment,

[...]
> > Except that would require an equivalent of a virtual machine
> > underneath.

> virtual machine is also heavy performance killer...

Which explains why some of the leading experts in optimization
claim that it is necessary for the best optimization. (I don't
fully buy that claim, but a virtual machine does have a couple
of advantages when it come to optimizing: it sees the actual
data being processed, for example, and the actual machine being
run on, and can optimize to both.)

> > And that is one of central issues with Java.

> Yes.
> I think java is designed in such way that it will still be slow in
> comparison to other compiled languages...if it is compiled
> language.

First, Java is a compiled language, and second, it's not slower
than any of the other compiled languages, globally. (Specific
programs may vary, of course.)

--
James Kanze

== 2 of 8 ==
Date: Fri, Dec 25 2009 5:36 am
From: James Kanze

On Dec 24, 1:03 am, Branimir Maksimovic <bm...@hotmail.com> wrote:
> Kaz Kylheku wrote:
> > On 2009-12-23, Branimir Maksimovic <bm...@hotmail.com> wrote:
> >> tanix wrote:
> >>> In article <hgskgk$kc...@news.albasani.net>, Vladimir
> >>> Jovic <vladasp...@gmail.com> wrote:
> >>> C++ would probably be benefited tremendously if it adopted some
> >>> of the central Java concept, such as GC, threads and GUI.
> >> GC is heavy performance killer especially on multiprocessor systems

> > Is not.

> Hm, explain to me how can any thread, access or change any
> pointer in memory without lock while gc is collecting....
> There is no way for gc to collect without stopping all threads
> without locking.... because gc is just another thread(s) in
> itself...

Maybe. I've not actually studied the implementations in
detail. I've just measured actual time. And the result is that
over a wide variety of applications, garbage collection is, on
the average, slightly faster. (With some applications where it
is radically faster, and others where it is noticeably slower.)

> >> in combination with threads....it is slow, complex and
> >> inefficient...

> > Religious belief.

> Of course. GC is complex program that has only one purpose.
> To let programmer not write free(p), but programmer
> still has to write close(fd).
> What's the purpose of that?

Less lines of code to write.

If you're paid by the line, garbage collection is a bad thing.
Otherwise, it's a useful tool, to be used when appropriate.

> > GC is very efficient from an SMP point of view, because it
> > allows for immutable objects to be truly immutable, over
> > most of their lifetime. No book-keeping operations have to
> > be performed on objects that are just passed around
> > throughout the program (such as bumping refcounts up and
> > down).

> Refcounts are negligible in comparison to what gc is doing.

Reference counting is very expensive in a multithreaded
environment.

And in the end, measurements trump abstract claims.

[...]
> > No storage reclamation strategy is free of overhead. Even if
> > your program correctly manages memory by itself with
> > explicit new and delete, there is a cost.

> Manual memory deallocation is simple, fast and efficient.
> Nothing so complex like GC. Cost of new and delete is nothing
> in comparison to GC.

That's definitely not true in practice.

[...]
> GC cannot be implemented efficiently since it has to mess with
> memory...

What you mean is that you don't know how to implement it
efficiently. Nor do I, for that matter, but I'm willing to
accept that there are people who know more about the issues than
I do. And I've measured the results of their work.

[...]
> I don't want to discuss this, but it is obvious that nothing
> in java is designed with performance in mind. Quite
> opposite....

You don't want to discuss it, so you state some blatent lie, and
expect everyone to just accept it at face value. Some parts of
Java were definitely designed with performance in mind (e.g.
using int, instead of a class type). Others less so. But the
fact remains that with a good JVM, Java runs just as fast as C++
in most applications. Speed is not an argument against Java
(except for some specific programs), at least on machines which
have a good JVM.

--
James Kanze

== 3 of 8 ==
Date: Fri, Dec 25 2009 5:40 am
From: James Kanze

On Dec 24, 10:11 am, Branimir Maksimovic <bm...@hotmail.com> wrote:
> tanix wrote:
> > In article <hguelj$k4...@news.albasani.net>, Branimir Maksimovic <bm...@hotmail.com> wrote:

[...]
> Memory managment is not a problem. You can implement GC, for
> any apllication even in assembler. Reference counting is
> simple form of gc and works well in c++ because of RAII.

Reference counting doesn't work in C++, because of cycles. And
reference counting is very, very slow compared to the better
garbage collector algorithms.

[...]
> And somebodey tried to convince me that conservative GC is
> faster that shared_ptr/auto_ptr (what a ....;)

And you refused to even look at actual measurements. I'm aware
of a couple of programs where the Boehm collector significantly
out performs boost::shared_ptr. (Of course, I'm also aware of
cases where it doesn't. There is no global perfect solution.)

--
James Kanze

== 4 of 8 ==
Date: Fri, Dec 25 2009 5:49 am
From: James Kanze

On Dec 24, 1:23 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Branimir Maksimovic <bm...@hotmail.com> writes:
> >Refcounts are negligible in comparison to what gc is doing.
> >GC cannot be efficient since it cannot access program

> »[A]llocation in modern JVMs is far faster than the best
> performing malloc implementations. The common code path
> for new Object() in HotSpot 1.4.2 and later is
> approximately 10 machine instructions (data provided by
> Sun; see Resources), whereas the best performing malloc
> implementations in C require on average between 60 and 100
> instructions per call (Detlefs, et. al.; see Resources).

Although I agree with the final results (having made some actual
measurements), the wording above is very definitely
"advertising". It's a well known fact that *allocation* is very
fast in a copying garbage collector---even 10 instructions seems
like a lot. But this is partially offset by the cost of
collecting, and in early implementations (*not*, presumably
HotSpot) by the fact that each dereference involved an
additional layer of indirection.

> And allocation performance is not a trivial component of
> overall performance -- benchmarks show that many
> real-world C and C++ programs, such as Perl and
> Ghostscript, spend 20 to 30 percent of their total
> execution time in malloc and free -- far more than the
> allocation and garbage collection overhead of a healthy
> Java application (Zorn; see Resources).«

That's also a bit of advertising. I really wouldn't call an
interpreter a "typical" program. For that matter, I don't even
know if there are typical programs, C++ is used for so many
different things. (In numeric processing, for example, it's
quite possible for a program to run hours without a single
allocation.)

There's an old saying: don't trust any benchmark you didn't
falsify yourself. Garbage collection is a tool, like any other.
Sometimes (a lot of the time) it helps. Other times it doesn't.
If my experience is in any way typical (but it probably isn't),
it's impact on performance is generally negligeable, one way or
the other. It's essential for robustness (no dangling
pointers), but a lot of programs don't need that much
robustness. For the rest, it depends on the application, the
programmer, and who knows what other aspects. It's a shame that
it's not officially available, as part of the language, but I'd
also oppose any move to make it required.

--
James Kanze

== 5 of 8 ==
Date: Fri, Dec 25 2009 5:52 am
From: James Kanze

On Dec 24, 2:03 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
> Stefan Ram wrote:

[...]
> Allocation is not where GC fails, rather deallocation....

It doesn't fail there, either. But any comparison should take
deallocation into consideration. (Well, formally... there's no
deallocation with garbage collection. But the system must take
some steps to determine when memory can be reused.)

> Because there is no fastest and simpler way to perform
> collection, than to stop program, perform collection in
> multiple threads, then let program work....

Try Googleing for "incremental garbage collection".

--
James Kanze

== 6 of 8 ==
Date: Fri, Dec 25 2009 5:59 am
From: James Kanze

On Dec 24, 2:15 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Branimir Maksimovic <bm...@hotmail.com> writes:
> >Allocation is not where GC fails, rather deallocation....

> Deallocation matters for long-running programs.
> A programm that is running only a short time might
> never need to actually reclaim memory. Otherwise,
> I agree that this takes some time indeed.

It has to be considered when making comparisons, however...

In general, with most manual memory management schemes, total
time is proportional to the number of blocks allocated and
freed. With the most classical garbage collection algorithm
(mark and sweep), total time is proportional to the total amount
of memory in use when the garbage collector is run. If you're
allocating a lot of small, short lived blocks, then garbage
collection is faster. (It's not accident that the benchmarks
prepared by people favoring garbage collection tend to
manipulate very dynamic graph structures, where nodes are
constantly being allocated and freed.) When threading is
involved, significantly faster, since the typical malloc/free
will use a lock for each call. (There are, of course, faster
implementations of malloc/free available. The fastest I know of
for a multiple threaded environment in fact uses some of the
techniques of garbage collection, at least for memory which is
freed in a thread different from the one it was allocated in.)

--
James Kanze

== 7 of 8 ==
Date: Fri, Dec 25 2009 6:06 am
From: James Kanze

On Dec 24, 2:46 pm, Pete Becker <p...@versatilecoding.com> wrote:
> Balog Pal wrote:
> > "Stefan Ram" <r...@zedat.fu-berlin.de>
> > Branimir Maksimovic <bm...@hotmail.com> writes:
> >>> Allocation is not where GC fails, rather deallocation....

> >> Deallocation matters for long-running programs.
> >> A programm that is running only a short time might
> >> never need to actually reclaim memory. Otherwise,
> >> I agree that this takes some time indeed.

> > Hm, you actually suggest that if a program does just a
> > couple allocations up front and keep all the objects,
> > comparing the speed of the allocation make sense?

> > Can you provide an application example where that java's
> > allegedly superfast allocation can be noticed?

> You're missing the point. Comparisons of Java and C++ are
> supposed to make Java look good. It doesn't matter whether
> they make sense so long as they meet that goal.

As I said before, never trust a benchmark you haven't falsified
yourself:-). On the other hand, why should a Java proponent
design a benchmark which makes his language look bad. And
since C++ doesn't have any vested interests ready to pay to make
it look good, and the others look bad, there aren't many C++
advocates designing benchmarks. (If someone's ready to pay me,
I'll design you a benchmark. Just tell me which language you
want to win, and it will. I know both languages well enough for
that.)

On the other hand, the fact that there are a large number of
Java applications which run and are sufficiently fast is more or
less a proof that performance isn't (always) a problem with the
language. (The fact that they almost all run on Intel
architectures may indicate that the JVM's available on other
systems aren't all that good.)

> Hmm, could it be that Java proponents are all Republicans?

They're not that bad. (At least, not all of them.) There's a
difference about not presenting the whole picture, and just
lying (see "if Stephan Hawkings had lived in Britain").

--
James Kanze

== 8 of 8 ==
Date: Fri, Dec 25 2009 6:30 am
From: ram@zedat.fu-berlin.de (Stefan Ram)

James Kanze <james.kanze@gmail.com> writes:
>As I said before, never trust a benchmark you haven't falsified

Yes, of course, it all starts with the fact, that one cannot
compare the �speed of languages� but only the speed of
specific programs running under a specific /implementation/
of a language running under a specific operating system
running on a specific hardware.

What is language-specific is only the fact that some
language features make some kinds of optimization possible
(like �restrict� in C) or impossible (e.g., when aliasing by
pointers is possible).

So, if I had to implement some algorithm, I would not refuse
Java from the first, because it is �slow�, but do some
benchmarking with code in the direction of that algorithm.

After all, /if/ Java is sufficiently fast for my purpose,
it gives me some conveniences, such as run-time array index
checking, automatic memory management and freedom from
the need for (sometimes risky) pointer arithmetics.

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

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, December 25, 2009

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

No comments:

Blog Archive

About Me