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

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

comp.lang.c++@googlegroups.com

Today's topics:

* disadvantages of using STL - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/fb1f5fcc56ce965e?hl=en
* Does anyone else wish the C++ standards committee would give us parity with
other programming languages? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/65479c8a9a474e0b?hl=en
* Standard C++ way to generate a Jump Table ??? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/7686e7082cfac191?hl=en
* how to send an e-Mail with attachment? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/aba76f403a10120c?hl=en
* Discussing boost? (was:Re: multithreaded timer?) - 4 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/f793be567a9ef8c1?hl=en
* Corrected: Using type suffixes with floating point constants - 4 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/e4b6beec5748ef9f?hl=en
* Using type prefixes with floating point constants - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/bb3e3831ff763cf0?hl=en
* float and double precision - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/b4c58ab5204ef5a3?hl=en
* China Cheap Brand Purses JIMMY THOO D&G VERSACE True leather AAA Wholesale,
Free shipping - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/90b75b8464d5d6cc?hl=en
* declaring a friend template function whose arguments are of type = private
member type - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/2ab310759a6787c6?hl=en
* GRAB THE GOLDEN OPPURTUNITY TO EARN MORE MONEY IN THE WORLD - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/3d6c28752501d72d?hl=en
* Reference Type - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/b4d1692e11afafc7?hl=en
* C++ is complicated - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/ec94a39f632a6c05?hl=en
* NEW Ed Hardy T shirts - Fashion - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/0316c9d2e2145173?hl=en

==============================================================================
TOPIC: disadvantages of using STL
http://groups.google.com/group/comp.lang.c++/t/fb1f5fcc56ce965e?hl=en
==============================================================================

== 1 of 3 ==
Date: Fri, Mar 27 2009 4:55 am
From: SG

On 27 Mrz., 07:41, "Tony" <t...@my.net> wrote:
> "Noah Roberts" <n...@nowhere.com> wrote in message
> > Anyone can obfuscate a design in their implementation.
> Cliches are like assholes.

Hello Tony,

it seems you don't have a lot to contribute to this (or any?)
discussion. I went through the trouble of reading all your posts in
this thread and the thread "C++ is complicated" again and the only
things that have stuck are:

* STL is supposedly complicated. It's more complicated
than your container library.
* You don't accept the STL being part of the C++ standard
library as an advantage even though obvious arguments
for this position have been mentioned.
* You prefer some "void*-based" container design (whatever
that means)
* You said that the STL's performance advantage "probably
doesn't matter".

This goes along with a lack of arguments and accusations à la
"Propaganda!", "You're a marketeer", "Bitch.", etc.

Nicely done, Tony.

-SG

== 2 of 3 ==
Date: Fri, Mar 27 2009 5:15 am
From: ytrembla@nyx.nyx.net (Yannick Tremblay)

In article <p9_yl.16853$as4.3552@nlpi069.nbdc.sbc.com>,
Tony <tony@my.net> wrote:
>
><coal@mailvault.com> wrote in message
>news:d492e829-ee29-479d-93df-2c976cab4e01@g19g2000yql.googlegroups.com...
>On Mar 24, 4:01 am, James Kanze <james.ka...@gmail.com> wrote:
>> On Mar 23, 4:52 pm, Noah Roberts <n...@nowhere.com> wrote:
>>
>> > Tony wrote:
>> > > "Noah Roberts" <n...@nowhere.com> wrote in message
>> > >news:49c11c54$0$29989$cc2e38e6@news.uslec.net...
>> > >> Pallav singh wrote:
>> > >>> Q What are the disadvantages of using STL ?
>> > >> Efficiency.
>> > > He said DISadvantages.
>> > Oh.
>>
>> One man's advantage is another man's disadvantage. If you're
>> trying to hang on to a job, the fact that not using the STL
>> reduces efficiency, so that it takes you a year to finish the
>> job, rather than six months, could be considered an advantage
>> (provided you're sure that the employer doesn't realize that
>> you're artificially creating extra work, and fire you for it).
>
>"I take it by efficiency you mean programmer efficiency."
>
>Noooooo. I meant the space vs. time tradeoff.

Hi Tony,

I have doubt about replying to you because the way you have been
handling yourself in here leave doubts in one mind about what is your
purpose in this group. but still, I'll try.

James is correct when he say that programmer efficiency is the most
important one. Why does it trump execution memory space or execution
time? Because if you are using techniques that allow efficient
programming, then the required functionality will be completed
earlier. This will leave you time for profiling and then going back
to do properly targetted optimisation (execution time or memory usage)
where they are needed. This also leave your mind freeer to
concentrate on algorithmic efficiency rather than on low level
mechanics of of micro-optimisation (most likely premature).

Yannick

== 3 of 3 ==
Date: Fri, Mar 27 2009 10:03 am
From: Noah Roberts

SG wrote:
> On 27 Mrz., 07:41, "Tony" <t...@my.net> wrote:
>> "Noah Roberts" <n...@nowhere.com> wrote in message
>>> Anyone can obfuscate a design in their implementation.
>> Cliches are like assholes.
>
> Hello Tony,
>
> it seems you don't have a lot to contribute to this (or any?)
> discussion. I went through the trouble of reading all your posts in
> this thread and the thread "C++ is complicated" again and the only
> things that have stuck are:
>
> * STL is supposedly complicated. It's more complicated
> than your container library.
> * You don't accept the STL being part of the C++ standard
> library as an advantage even though obvious arguments
> for this position have been mentioned.
> * You prefer some "void*-based" container design (whatever
> that means)
> * You said that the STL's performance advantage "probably
> doesn't matter".
>
> This goes along with a lack of arguments and accusations à la
> "Propaganda!", "You're a marketeer", "Bitch.", etc.
>
> Nicely done, Tony.

hehehehe, and here I was just going to say "*plonk*"

==============================================================================
TOPIC: Does anyone else wish the C++ standards committee would give us parity
with other programming languages?
http://groups.google.com/group/comp.lang.c++/t/65479c8a9a474e0b?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 27 2009 5:17 am
From: ytrembla@nyx.nyx.net (Yannick Tremblay)

In article <9cf8d7d4-3684-4e06-94a2-72228966460e@d25g2000prn.googlegroups.com>,
Anonymous Infidel - Aborted Islam with a hanger <messiah2999@yahoo.com> wrote:
>Or better yet, force them(C#, Java, etc) to do the catch up game....

Might be useful if you would clarify what in your mind is making the
C++ language trail behind these other languages.

Yan

==============================================================================
TOPIC: Standard C++ way to generate a Jump Table ???
http://groups.google.com/group/comp.lang.c++/t/7686e7082cfac191?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 27 2009 5:23 am
From: PeteOlcott

On Mar 27, 2:11 am, Paavo Helde <pa...@nospam.please.ee> wrote:
> "Peter Olcott" <NoS...@SeeScreen.com> kirjutas:
>
>
>
>
>
> > This is as close as I could get to generating the equivalent
> > of an assembly language jump table:
>
> > switch(N)
> > {
> > case 0:
> > case 1:
> > case 2:
> > case 3:
> > case 4:
> > case 5:
> > case 6:
> > case 7:
> > }
>
> > mov eax, DWORD PTR _N$[esp-4]
> > cmp eax, 7
> > ja SHORT $LN1_TestSpeed
> > jmp DWORD PTR $LN14_TestSpeed[eax*4]
>
> > I am looking for a way to be able to specify C++ code such
> > that the second and third line of the assembly language
> > would not be generated. The only way that I can think to do
> > this is to delete the two lines and compile it as assembly
> > language.
>
> Out of curiosity - have you measured how much effect deleting these two
> lines would give you? (Presuming of course there are some non-empty cases,
> otherwise the compiler should optimize the whole construction away.)
>

When I attempt to optimize my code, I do not take the term "optimize"
figuratively like compiler optimizers do. When I optimize my code I
make every attempt to make the code as fast as possible within the
binding constraint of the semantic requirements. Also I carefully
select the set of semantic requirements from a categorically
exhaustive set of every combination that provides the desired end-
result. This process works exceptionally well for all development
where the desired end-result can be specified in a mathematically
rigorous way.

> > Are there any possible standard C++ ways to do this?
>
> Standard C++ requires the code to work also if N is outside of [0,7], so it
> cannot strip away the code for that. You could try to declare N as unsigned
> char and provide all 256 cases.
>
> FWIW, MSVC++ provides the __assume keyword as an extension, letting one to
> tell the optimizer things like that. The example in the MSDN documentation
> is exactly about optimizing out the default branch of a switch.
>
> Paavo- Hide quoted text -
>
> - Show quoted text -

==============================================================================
TOPIC: how to send an e-Mail with attachment?
http://groups.google.com/group/comp.lang.c++/t/aba76f403a10120c?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Mar 27 2009 5:26 am
From: ytrembla@nyx.nyx.net (Yannick Tremblay)

In article <b3015d2f-3ef8-4873-bb03-ee2cdafbf43d@j38g2000yqa.googlegroups.com>,
Cristiano <crixtiano@gmail.com> wrote:
>Please,
>
>I'm writing a program in C++ who needs to send a file using e-Mail
>(SMTP). In another words, I need a code, in C++ to send a email with
>attachment.
>
>I'm programming for Win32 with DevC++. I had search in web but I can't
>find something realy good.
>
>Please, where can I find an OpenSource solution to help me?

As other have informed you, there is no "built-in" support for Sending
email" in C++. However, many mail user agent or mail server are
written in C++ so you could implement it yourself or use a third party
library that would do the groundwork for you.

The send email, you will need SMTP capability.
To send an attachment, you probably should use MIME.
Both of these are stadards that are defined in RFCs available on the
net. There are several libraries that implement support for these in
C++.

The other alternative, if performance is not essential and you are
only going to send emails occasionally would be to do a system() call
and simply call a third party command line driven mail application.
That could save you an awful lot of work.

Yannikc

== 2 of 2 ==
Date: Fri, Mar 27 2009 8:03 am
From: Juice

Cristiano wrote:
> Please,
>
> I'm writing a program in C++ who needs to send a file using e-Mail
> (SMTP). In another words, I need a code, in C++ to send a email with
> attachment.
>
> I'm programming for Win32 with DevC++. I had search in web but I can't
> find something realy good.
>
> Please, where can I find an OpenSource solution to help me?

A little bit of googling revealed this:
http://sourceforge.net/projects/vmime

Regards,
Ivan

==============================================================================
TOPIC: Discussing boost? (was:Re: multithreaded timer?)
http://groups.google.com/group/comp.lang.c++/t/f793be567a9ef8c1?hl=en
==============================================================================

== 1 of 4 ==
Date: Fri, Mar 27 2009 5:33 am
From: ytrembla@nyx.nyx.net (Yannick Tremblay)

In article <gqdfk5$bec$1@news.datemas.de>,
Victor Bazarov <v.Abazarov@comAcast.net> wrote:
>boost_newbie wrote:
>> I'm implementing a serial RS232 communication centered application
>> using boost in Windows.
>> [..]
>> All the queue things are OK (so it seems for now), I just need the
>> timer.
>>
>> The ASIO timer is quite strange to me, I didn't manage to make it
>> work.
>>
>> Any ideas?
>
>Well, yes. Post to the relevant online forum available on the Boost web
>site. Here we talk standard C++ language, and it happens not to have
>threaded timers (or anything named ASIO) at this time.

Sorry Victor but I thought from previous discussions here in the past
(or at least my senile memory seems to have a vague recollection of
that), that boost discussions were tolerated here even if not
necessarily encouraged, especially since significant amount of boost
is making it into C++0x.

I understand (and agree with) the need to keep the discussions focused
here but I though boost was allowed.

Yan

== 2 of 4 ==
Date: Fri, Mar 27 2009 5:47 am
From: Arne Mertz

On 27 Mrz., 13:33, ytrem...@nyx.nyx.net (Yannick Tremblay) wrote:
> Sorry Victor but I thought from previous discussions here in the past
> (or at least my senile memory seems to have a vague recollection of
> that), that boost discussions were tolerated here even if not
> necessarily encouraged, especially since significant amount of boost
> is making it into C++0x.
>
> I understand (and agree with) the need to keep the discussions focused
> here but I though boost was allowed.
>
> Yan

My memory might be as senile as yours, it recollects sth. like
"... standard C++ and freely available platform independent
libraries (such as boost and loki)..."

Arne

== 3 of 4 ==
Date: Fri, Mar 27 2009 6:28 am
From: Victor Bazarov

Arne Mertz wrote:
> On 27 Mrz., 13:33, ytrem...@nyx.nyx.net (Yannick Tremblay) wrote:
>> Sorry Victor but I thought from previous discussions here in the past
>> (or at least my senile memory seems to have a vague recollection of
>> that), that boost discussions were tolerated here even if not
>> necessarily encouraged, especially since significant amount of boost
>> is making it into C++0x.
>>
>> I understand (and agree with) the need to keep the discussions focused
>> here but I though boost was allowed.
>>
>> Yan
>
> My memory might be as senile as yours, it recollects sth. like
> "... standard C++ and freely available platform independent
> libraries (such as boost and loki)..."

Discussing compiler errors and what to do about them, certainly.
Discussing algorithms and problems related to those algorithms, and
*what to use* from that "platform independent library"? That's not a
*language* area, is it, now?

Anyway, you are free to ignore my opinion, of course. This is, after
all, an unmoderated newsgroup and everybody can post anything. We even
see posts from religious nuts and headhunters every now and then, and
those are much less related to C++ than Boost's ASIO...

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

== 4 of 4 ==
Date: Fri, Mar 27 2009 9:31 am
From: coal@mailvault.com

On Mar 27, 7:47 am, Arne Mertz <goo...@arne-mertz.de> wrote:
> On 27 Mrz., 13:33, ytrem...@nyx.nyx.net (Yannick Tremblay) wrote:
>
> > Sorry Victor but I thought from previous discussions here in the past
> > (or at least my senile memory seems to have a vague recollection of
> > that), that boost discussions were tolerated here even if not
> > necessarily encouraged, especially since significant amount of boost
> > is making it into C++0x.
>
> > I understand (and agree with) the need to keep the discussions focused
> > here but I though boost was allowed.
>
> > Yan
>
> My memory might be as senile as yours, it recollects sth. like
> "... standard C++ and freely available platform independent
> libraries (such as boost and loki)..."
>

I've shared my views on Boost on this newsgroup quite a bit.
Basically I think you should "chew the meat and spit the
bones." In other words, the utility/quality of the libs
varies.

Recently I've expanded the page that compares the freely
available and platform independent C++ Middleware Writer
with the Boost Serialization library --
http://webEbenezer.net/comparison.html.
I have some ideas for topics to add to the page, but would
like to get feedback on what's already there.

Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

==============================================================================
TOPIC: Corrected: Using type suffixes with floating point constants
http://groups.google.com/group/comp.lang.c++/t/e4b6beec5748ef9f?hl=en
==============================================================================

== 1 of 4 ==
Date: Fri, Mar 27 2009 5:48 am
From: Ioannis Vranos

Victor Bazarov wrote:
> Ioannis Vranos wrote:
>> ISO/IEC 9899:1990/1995 says (from K&R2):
>>
>> "A6.4
>>
>> When a less precise floating value is converted to an equally or more
>> precise floating type, the value is unchanged.
>>
>> ==> When a more precise floating value is converted to a less precise
>> floating type, and the value is within representable range, the result
>> may be either the next higher or the next lower representable value.
>>
>> If the result is out of range, the behavior is undefined".
>>
>>
>> Question: Does the above mean that it is a good practice or *always*
>> needed to use the appropriate type suffixes with floating point
>> constants?
>
> No, the above does not mean that. You need to look at the definition of
> the FP literals. The suffix only says what type the literal has. The
> suffix does not control potential precision. IOW
>
> float Pi = 3.1415926;
> float Pi_ = 3.1415926f;
>
> will *likely* have the same value since the number of digits (8) in the
> literals is greater than 'float' can represent (7), and both numbers
> will be "fixed", only at different times, so to speak. The former will
> be squeezed into a 'float' at the time of initialising of 'Pi' (formally
> by your program), the other will be squeezed into a 'float' by the
> compiler upon creating the literal. It is conceivable that the numbers
> will be different *if* your compiler uses a different way of "fixing" of
> the value to fit into a 'float' than your program (which can actually be
> controlled in some cases by a flag in the CPU/FPU, IIRC).

The sizes differ:

#include <stdio.h>

int main(void)
{
printf("sizeof(0.33439F)= %lu, sizeof(0.33439)= %lu\n\n",
(unsigned long)sizeof(0.33439F), (unsigned long)sizeof(0.33439));

return 0;
}

john@ubuntu:~/Projects/anjuta/c/src$ ./foobar
sizeof(0.33439F)= 4, sizeof(0.33439)= 8

john@ubuntu:~/Projects/anjuta/c/src$

== 2 of 4 ==
Date: Fri, Mar 27 2009 5:52 am
From: Ioannis Vranos

The sizes differ in my system:

#include <iostream>

int main(void)
{
using namespace std;

cout<<"sizeof(0.33439F)= "<< sizeof(0.33439F)<< ", sizeof(0.33439)= "
<<sizeof(0.33439)<<endl<< endl;

return 0;
}

john@ubuntu:~/Projects/anjuta/cpp/src$ ./foobar
sizeof(0.33439F)= 4, sizeof(0.33439)= 8

john@ubuntu:~/Projects/anjuta/cpp/src$

== 3 of 4 ==
Date: Fri, Mar 27 2009 5:55 am
From: Ioannis Vranos

Forwarded:

Bart.van.Ingen.Schenau@ict.nl said:

On Mar 26, 2:54 pm, Ioannis Vranos <ivra...@freemail.spam.not.gr>
wrote:
> > ISO/IEC 9899:1990/1995 says (from K&R2):
> >
> > "A6.4
> >
> > When a less precise floating value is converted to an equally or more
> > precise floating type, the value is unchanged. When a more precise
> > floating value is converted to a less precise floating type, and the
> > value is within representable range, the result may be either the next
> > higher or the next lower representable value. If the result is out of
> > range, the behavior is undefined".
> >
> > Question: Does the above mean that it is a good practice or *always*
> > needed to use the appropriate type suffixes with floating point constants?
> >
I don't know about best practice---I don't use floating point often
enough for that---, but it certainly is not needed to always specify
the suffixes.

First of all, the majority of floating point constants are not exactly
representable in any of the floating point types, so you get the
conversion to the next higher or next lower representable value
anyway.
If float and double don't have the same range and precision, then a
compiler must be really perverse to get different results for the
expressions '(float)0.33439' and '0.33439F'.

The only suffix with more than documentary value is L (or l), if you
need the extra precision or range that long double might give you.

Bart v Ingen Schenau

== 4 of 4 ==
Date: Fri, Mar 27 2009 6:07 am
From: Ioannis Vranos

Ioannis Vranos wrote:
> Forwarded:
>
>
> Bart.van.Ingen.Schenau@ict.nl said:
>
> On Mar 26, 2:54 pm, Ioannis Vranos <ivra...@freemail.spam.not.gr>
> wrote:
> > > ISO/IEC 9899:1990/1995 says (from K&R2):
> > >
> > > "A6.4
> > >
> > > When a less precise floating value is converted to an equally or more
> > > precise floating type, the value is unchanged. When a more precise
> > > floating value is converted to a less precise floating type, and the
> > > value is within representable range, the result may be either the next
> > > higher or the next lower representable value. If the result is out of
> > > range, the behavior is undefined".
> > >
> > > Question: Does the above mean that it is a good practice or *always*
> > > needed to use the appropriate type suffixes with floating point
> constants?
> > >
> I don't know about best practice---I don't use floating point often
> enough for that---, but it certainly is not needed to always specify
> the suffixes.
>
> First of all, the majority of floating point constants are not exactly
> representable in any of the floating point types, so you get the
> conversion to the next higher or next lower representable value
> anyway.
> If float and double don't have the same range and precision, then a
> compiler must be really perverse to get different results for the
> expressions '(float)0.33439' and '0.33439F'.
>
> The only suffix with more than documentary value is L (or l), if you
> need the extra precision or range that long double might give you.
>
> Bart v Ingen Schenau

Yes I think there is a case for long doubles constants. If we use the default double constants we may loose
both in precision and value ranges, on assignment to a long double variable and at calculations.

However I think we also have a case for floats, for truncation and perhaps compiler range checks.

==============================================================================
TOPIC: Using type prefixes with floating point constants
http://groups.google.com/group/comp.lang.c++/t/bb3e3831ff763cf0?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 27 2009 5:53 am
From: Ioannis Vranos

Bart van Ingen Schenau wrote:
> On Mar 26, 2:54 pm, Ioannis Vranos <ivra...@freemail.spam.not.gr>
> wrote:
>> ISO/IEC 9899:1990/1995 says (from K&R2):
>>
>> "A6.4
>>
>> When a less precise floating value is converted to an equally or more
>> precise floating type, the value is unchanged. When a more precise
>> floating value is converted to a less precise floating type, and the
>> value is within representable range, the result may be either the next
>> higher or the next lower representable value. If the result is out of
>> range, the behavior is undefined".
>>
>> Question: Does the above mean that it is a good practice or *always*
>> needed to use the appropriate type suffixes with floating point constants?
>>
> I don't know about best practice---I don't use floating point often
> enough for that---, but it certainly is not needed to always specify
> the suffixes.
>
> First of all, the majority of floating point constants are not exactly
> representable in any of the floating point types, so you get the
> conversion to the next higher or next lower representable value
> anyway.
> If float and double don't have the same range and precision, then a
> compiler must be really perverse to get different results for the
> expressions '(float)0.33439' and '0.33439F'.
>
> The only suffix with more than documentary value is L (or l), if you
> need the extra precision or range that long double might give you.
>
> Bart v Ingen Schenau

Thank you for your answer, the discussion is continued in thread:

"Corrected: Using type suffixes with floating point constants"

where I will forward your answer.

==============================================================================
TOPIC: float and double precision
http://groups.google.com/group/comp.lang.c++/t/b4c58ab5204ef5a3?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 27 2009 6:17 am
From: Victor Bazarov

Carson Myers wrote:
> would it be practical to use two int values, do you think?

That's what the algorithms based on rational numbers do. No way to
precisely represent Pi or e or the square root of 2 on those, however.

> Like in a class--one for the fractional part, and one for the whole-
> number part-
> that way I suppose it would be possible to avoid rounding errors since
> the fractional part wouldn't really be treated as a fractional part,
> but rather as a regular integer--you'd just have to worry about
> handling the math and the behavior of the <1 portion of it yourself,
> which would (I can imagine) be slow.
>
> However I don't really understand how 0.1 could not be represented...

Try calculating the binary representation of it. It's a good exercise.

> [..]

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

==============================================================================
TOPIC: China Cheap Brand Purses JIMMY THOO D&G VERSACE True leather AAA
Wholesale,Free shipping
http://groups.google.com/group/comp.lang.c++/t/90b75b8464d5d6cc?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Mar 27 2009 6:37 am
From: fujnde1234@126.com

Replica Balenciaga Giant Part Time Bag with leather studs, Gucci
babouska Studded Boston Bag G-207299, Replica Chloe Milton Hobo Bag
Handbags Copys, Chloe Boudior chain Bag Purses Gucci Pelham Shoulder
Bag G-203624 knockoff bag (www.guoshitrade.com )
Chanel Bags ( www.guoshitrade.com)
Chanel New Bags (www.guoshitrade.com )
Chanel Handbags (www.guoshitrade.com )
Chanel Wallets (www.guoshitrade.com )
Hermes
Hermes Birkin Bags (www.guoshitrade.com )
Hermes Kelly Bags (www.guoshitrade.com )
Hermes Replica Bag (www.guoshitrade.com )
Louis Vuitton www.guoshitrade.com
LV New Arrivals (www.guoshitrade.com )
Monogram Shimmer (www.guoshitrade.com )
Monogram Suede
LV Paris Souple 08 (www.guoshitrade.com )
LV Damier Lune 08
08 Winter New Bag (www.guoshitrade.com )
LV Handbags
LV Mahina Bag www.guoshitrade.com
LV Damier Graphite
Monogram Canvas
Monogram Watercolor (www.guoshitrade.com )
Monogram Pulp
LV Monogram Jokes
LV Monogram Tisse (www.guoshitrade.com )
Damier Canvas
Monogram Mini Lin (www.guoshitrade.com )
Epi leather
Suhali Leather
Monogram Multicolore
Monogram Vernis
Monogram Denim (www.guoshitrade.com )
Monogramouflage
LV Tahitiennes (www.guoshitrade.com )
Nomade Leather
Monogram Dentelle (www.guoshitrade.com )
LV Motard Bag
Monogram Perfor (www.guoshitrade.com )
LV Men's Bags
LV Other Series
Clutches & Pouches (www.guoshitrade.com )
Gucci www.guoshitrade.com
2009 New Bags
Gucci Handbags (www.guoshitrade.com )
Gucci Irina Bag
Gucci Sukey Bag
Gucci Babouska Bags (www.guoshitrade.com )
Gucci Hysteria Bag
Gucci Indy Bags
Gucci Positano Bags (www.guoshitrade.com )
Gucci Pelham Bags
Gucci Aviatrix Bag
Gucci Joy Bags www.guoshitrade.com
Gucci Canvas Bags
Gucci Replica Bags
Gucci Clutch Bags (www.guoshitrade.com )
Prada
2009 New Bags
Prada Fairy Bag (www.guoshitrade.com )
Prada Replica Bags (www.guoshitrade.com )
Mulberry
Mulberry Bags (www.guoshitrade.com )
Chloe
2009 New Bags (www.guoshitrade.com )
Chloe Replica Bags
Balenciaga
2009 New Bags
Balenciaga Bags
MiuMiu www.guoshitrade.com
Versace
Versace Bags (www.guoshitrade.com )
Fendi
Fendi SPY Bags (www.guoshitrade.com )
Fendi Replica Bags
Other Bags
Christian Dior Bags (www.guoshitrade.com )
Jimmy Choo Bags
Marc Jacobs Bags
Burberry Bags
Dolce & Gabbana (www.guoshitrade.com )
Coach Bags
Yves Saint Laurent
Bottega Veneta (www.guoshitrade.com )
Bally Bags
Juicy Couture Bags
Isabella Fiore Bags
Tod's Bags www.guoshitrade.com
Loewe Bags
Goyard Bags
Anya Hindmarch
Thomaswylde Bags (www.guoshitrade.com )
Valentino Bags
Cartier Bags (www.guoshitrade.com )
Chanal Bags
Kooba Handbags
Other Designers (www.guoshitrade.com )
Crystal Bags
Wallet www.guoshitrade.com
Hermes Wallets
Replica Gucci Wallet
Replica LV Wallets
Mulberry Wallets (www.guoshitrade.com )
Prada Wallets
Fendi Wallets (www.guoshitrade.com )
Chloe Wallets
Replica BV Wallets
Balenciaga Wallets www.guoshitrade.com
Burberry Wallets www.guoshitrade.com
Other Brand Wallet
Replica Dior Wallet (www.guoshitrade.com )
Marc Jacobs Wallets (www.guoshitrade.com )
Replica Bally Wallet
Jimmy Choo Wallet www.guoshitrade.com

== 2 of 2 ==
Date: Fri, Mar 27 2009 6:38 am
From: fujnde1234@126.com

==============================================================================
TOPIC: declaring a friend template function whose arguments are of type =
private member type
http://groups.google.com/group/comp.lang.c++/t/2ab310759a6787c6?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Mar 27 2009 8:12 am
From: "Hicham Mouline"

hello,
I have

template<typename CurveTraits>
class TimeCurve1D
{
public:
typedef typename CurveTraits::tType tType;
typedef typename CurveTraits::fType fType;

fType GetSomething() const;
private:
typedef std::pair<tType,fType>
EntryType;
typedef boost::array< EntryType, mContainerMaxSize > ContainerType;
ContainerType
m;
size_t
mContainerSize;
};

In GetSomething(), I use std::lower_bound( &m[0], &m[mContainerMaxSize],
std::pair<t, NaN> )
lower_bound uses operator< by default

Where can I defined this operator< for EntryType?
and how can I declare it a friend inside TimeCurve1D?

I tried

template<typename CurveTraits>
class TimeCurve1D
{
....
friend bool operator< <CurveTraits>( const EntryType&, const EntryType&);
....
};

template<typename CurveTraits>
inline bool operator<( const typename TimeCurve1D<CurveTraits>::EntryType&
lhs,
const typename TimeCurve1D<CurveTraits>::EntryType&
rhs )
{
return lhs.first < rhs.first;
}

On instantiation, it said
typedef struct std::pair<double, double> TimeCurve1D<...>::EntryType' is
private

but I am trying to make operator< friend...

rds,

== 2 of 2 ==
Date: Fri, Mar 27 2009 8:58 am
From: Vladyslav Lazarenko

Basically, in your case EntryType type is always a specialization of
std::pair<> template. That template defines "less than" comparator by
default, it looks like this (defined trough including 'utility' header
from STL):

template<class _T1, class _T2>
inline bool
operator<(const pair<_T1, _T2>& __x, const pair<_T1, _T2>& __y)
{ return __x.first < __y.first
|| (!(__y.first < __x.first) && __x.second < __y.second); }

So you are good as long as both types "CurveTraits::tType" and
"CurveTraits::fType" has "less than" operators defined. Note that you
don't have to define "bool operator < (const EntryType & lhs, const
EntryType & rhs)" yourself.

For example, let's assume you have the following code that uses your
"TimeCurve1D" template:

struct A { int v; };
struct B { double v; };

struct my_curve_traits {
typedef A tType;
typedef B fType;
};

In order to get it working you have to write the following operators:

bool operator < (const A & lhs, const A & rhs) { return lhs.v <
rhs.v; }
bool operator < (const B & lhs, const B & rhs) { return lhs.v <
rhs.v; }

Note that you don't have to define those operators for POD types (line
int, double etc.). This is an example:

#include <utility>
#include <stdexcept>
#include <iostream>

#include <boost/array.hpp>

template<typename CurveTraits>
class TimeCurve1D
{
public:
typedef typename CurveTraits::tType tType;
typedef typename CurveTraits::fType fType;

fType GetSomething() const { throw std::runtime_error("Not
implemented"); }

private:
enum { mContainerMaxSize = 128 }; // You probably forgot to define
mContainerMaxSize...

typedef std::pair<tType,fType> EntryType;
typedef boost::array< EntryType, mContainerMaxSize > ContainerType;

ContainerType m;
size_t mContainerSize;
};

struct A { int v; };
struct B { double v; };

struct my_curve_traits {
typedef A tType;
typedef B fType;
};

typedef TimeCurve1D<my_curve_traits> my_curve_1d;

int main(int , char *[]) {
try {
my_curve_1d curve;
curve.GetSomething();
} catch(const std::exception & e) {
std::cout << "Here you go: " << e.what() << std::endl;
}
return 0;
}

Hope it helps!

---
Vladyslav Lazarenko

==============================================================================
TOPIC: GRAB THE GOLDEN OPPURTUNITY TO EARN MORE MONEY IN THE WORLD
http://groups.google.com/group/comp.lang.c++/t/3d6c28752501d72d?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 27 2009 9:04 am
From: gayu

GRAB THE GOLDEN OPPURTUNITY:

earn more money in the home:

free register more income:

and also post your adv free on your computer:

click here below:

************************************
http://www.impactglobalisation.webs.com

************************************

==============================================================================
TOPIC: Reference Type
http://groups.google.com/group/comp.lang.c++/t/b4d1692e11afafc7?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 27 2009 9:55 am
From: red floyd

On Mar 25, 5:17 pm, "Alf P. Steinbach" <al...@start.no> wrote:

> From a philosophical point of view one might say that C++ references are like
> quantum wavefunctions.
>
> Logic dictates that they're there, and it's no big deal to create one, or copy one.
>
> However, try to get hold of one in the "raw" state and it's a slippery beast indeed.
>

So... we know that code often exhibits "Heisenbugs", which go away
when you look at them.
Does your analogy mean that Schroedinger's Code exhibits undefined
behavior until we look
at it?

==============================================================================
TOPIC: C++ is complicated
http://groups.google.com/group/comp.lang.c++/t/ec94a39f632a6c05?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 27 2009 10:05 am
From: Noah Roberts

Juha Nieminen wrote:
> Tony wrote:
>>>> The solution is to not use the std library.
>>> So you implement your own containers, streams, algorithms, ...
>>> (easy-peasy)
>>> debug them to a high standard of reliability (shouldn't take much work)
>>> and you're fine (except that nobody else understands your code).
>>>
>> "My code" huh? What do you know about "my code"? Hmm? Do tell. Well then
>> STFU!
>
> What does he know? You told him: "The solution is to not use the std
> library".
>
> If you are indeed not using the std library, I wouldn't really like to
> maintain your code.

Had to work under a guy like this once; no std library, no stl, no
exceptions. Eventually he sort of gave up ever getting anything done
and quit. Best thing that ever happened to the team.

==============================================================================
TOPIC: NEW Ed Hardy T shirts - Fashion
http://groups.google.com/group/comp.lang.c++/t/0316c9d2e2145173?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 27 2009 10:11 am
From: amamark858@gmail.com

Want to buy cheap and fashionable NEW Ed Hardy T shirts,please view
our store
(www.luxury-fashion.org)
Our goods are the fine quality.

You can check them here:
http://www.luxury-fashion.org/static/Apparels/ED-Hardy-women-shirt-188.html
http://www.luxury-fashion.org/static/Apparels/ED-Hardy-women-shirt-187.html
http://www.luxury-fashion.org/static/Apparels/ED-Hardy-Men-shirts-76.html
http://www.luxury-fashion.org/static/Apparels/ED-Hardy-Men-shirts-75.html

Welcome check our site and feel free contact us.
Believe You can find what do you want here!

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

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, March 27, 2009

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

No comments:

Blog Archive

About Me