+

+

[Bячеслaв]

Здравствуйте!

Меня зовут Bячеслaв.

Наш сервис занимается распространением коммерческих предложений в сети.

Предлагаем сформировать базу данных предприятий  по нужным критериям и сделать рассылку по данной базе.

Цена данной услуги - совсем невысокая.В случае заинтересованности - я предоставлю прайс-лист по всем базам

Если это возможно - сообщите пожалуйста Ваш Ваш телефон или skype - я объясню  о данном виде рекламы более подробно.

С уважением Bячеслaв.

????????????????

[???]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 84 bytes --]

??œBÓñ

gcc6 Attachment:
????????????.xls
Description: application/msexcel

?????????????;

[???]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 90 bytes --]

»ô¶ùÒÀ

gcc7 Attachment:
?????????.xls
Description: application/msexcel

??????????????

[???]

Attachment:
????????.xls
Description: application/msexcel

???????????

[XHUNQ]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="l8", Size: 10 bytes --]

XHUNQ
gcc

[-- Attachment #2: ?c[3]m.xls --]
[-- Type: application/x-msexcel, Size: 26112 bytes --]

÷ÚÒÏÓÌÁÑ ÏÂÎÁÖÅÎÎÁÑ ÂÒÀÎÅÔËÁ

[gannon nobuko]

îÅÖÎÙÊ ÑÚÙÞÏË ÌÁÓËÁÅÔ ËÉÓËÕ

http://www.calculi15093.chat.ru

ÊÓËÃѺ¼Ùé·Õèµéͧ¡ÒÃ

[sale]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]

 =?ISO-8859-1?Q?=C1=D5=B8=D8=C3=A1=D4=A8=CA=E8=C7=B9=B5=D1=C7(=E4=C1=E8=B5?=

 =?ISO-8859-1?Q?=E9=CD=A7=C5=A7=B7=D8=B9)?=
To: gcc@gcc.gnu.org
Content-Type: text/plain;
	charset="US-ASCII"
Reply-To: sale@thailand001.com
Date: Wed, 30 Jun 2004 23:32:42 +0700
X-Priority: 3
X-Library: Indy 9.0.3-B
X-Mailer: Foxmail

ÊÓËÃѺ¼Ùé·Õèµéͧ¡ÒÃÁÕ¸ØáԨÊèǹµÑÇ(äÁèµéͧŧ·Ø¹)
¤Ø³ÊÁºÑµÔ
1.ªÒÂ/Ë­Ô§ ÍÒÂØ 25 »Õ¢Öé¹ä»
2.ÁÕà¤Ã×èͧ¤ÍÁ¾ÔÇàµÍÃì·ÕèÊÒÁÒöµèÍ Internet ä´é
3.ÁÕ¤ÇÒÁªÍº·Ò§´éÒ¹Ê×èÍÊÒüèÒ¹·Ò§ Internet
4.ÊÒÁÒöàÃÕ¹ÃÙéÍØ»¡Ã³ìÊ×èÍÊÒÃÃÐËÇèÒ§»ÃÐà·È

*** ¾ÔàÈÉ 20 ·èÒ¹áá ·Ò§àÃÒÂÔ¹´Õ¨Ñ´·Ó Web site à¾×èÍà»ç¹¡ÒúÃÔËÒøØáԨ¢Í§·èÒ¹àͧ ***
µéͧ¡ÒÃÃÒÂÅÐàÍÕ´à¾ÔèÁàµÔÁä´é·Õè 09-182-0363     ËÃ×Í    Email Add : sale@thailand001.com
www.thailand001.com

ÊÓËÃѺ¼Ùé·Õèµéͧ¡ÒÃ

[sale]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

 =?ISO-8859-1?Q?=C1=D5=B8=D8=C3=A1=D4=A8=CA=E8=C7=B9=B5=D1=C7(=E4=C1=E8=B5?=

 =?ISO-8859-1?Q?=E9=CD=A7=C5=A7=B7=D8=B9)?=
To: gcc@gnu.org
Content-Type: text/plain;
	charset="US-ASCII"
Reply-To: sale@thailand001.com
Date: Wed, 30 Jun 2004 23:32:23 +0700
X-Priority: 3
X-Library: Indy 9.0.3-B
X-Mailer: Foxmail

ÊÓËÃѺ¼Ùé·Õèµéͧ¡ÒÃÁÕ¸ØáԨÊèǹµÑÇ(äÁèµéͧŧ·Ø¹)
¤Ø³ÊÁºÑµÔ
1.ªÒÂ/Ë­Ô§ ÍÒÂØ 25 »Õ¢Öé¹ä»
2.ÁÕà¤Ã×èͧ¤ÍÁ¾ÔÇàµÍÃì·ÕèÊÒÁÒöµèÍ Internet ä´é
3.ÁÕ¤ÇÒÁªÍº·Ò§´éÒ¹Ê×èÍÊÒüèÒ¹·Ò§ Internet
4.ÊÒÁÒöàÃÕ¹ÃÙéÍØ»¡Ã³ìÊ×èÍÊÒÃÃÐËÇèÒ§»ÃÐà·È

*** ¾ÔàÈÉ 20 ·èÒ¹áá ·Ò§àÃÒÂÔ¹´Õ¨Ñ´·Ó Web site à¾×èÍà»ç¹¡ÒúÃÔËÒøØáԨ¢Í§·èÒ¹àͧ ***
µéͧ¡ÒÃÃÒÂÅÐàÍÕ´à¾ÔèÁàµÔÁä´é·Õè 09-182-0363     ËÃ×Í    Email Add : sale@thailand001.com
www.thailand001.com

:? ??

[Allan Sandfeld Jensen]

Hi
I have just been fixing several files in KDE 3.0 so they compile using Sun's 
native compiler. The most frequent fix I had to make was the following case:

for some QString a:
QString b = (exp) ? "xyz" : a;

Now the sun compiler insisted the two types in ?: needs to be identical. Now 
I am wondering what on earth gcc is doing?
Is it doing: 
  (exp) ? QString("xyz") : a
or
  QString(exp ? "xyz" : (const char*)a);

in the case of QString it doesnt matter because it is reversable, but this is 
not always be the case! Shouldnt gcc atleast give a warning before doing an 
ambigous type-cast?

greetings
`Allan

Re: :? ??

[Joe Buck]

> Hi
> I have just been fixing several files in KDE 3.0 so they compile using Sun's 
> native compiler. The most frequent fix I had to make was the following case:
> 
> for some QString a:
> QString b = (exp) ? "xyz" : a;
> 
> Now the sun compiler insisted the two types in ?: needs to be identical. Now 
> I am wondering what on earth gcc is doing?

If Sun issues a message claiming that the types of the second and third
arguments need to be identical, this is wrong.

The ISO C++ standard specifies the behavior of this operation.  Without
seeing the set of operations that the QString class declares, I can't tell
if there is a bug or not, or which compiler has the bug.

> Is it doing: 
>   (exp) ? QString("xyz") : a
> or
>   QString(exp ? "xyz" : (const char*)a);

Does QString define an operator const char*() ?  The std::string class
avoids this problem by making the user invoke a specific function to
convert to const char*.

Re: :? ??

[Michael Matz]

Hi,

On Tue, 19 Mar 2002, Joe Buck wrote:

> > Is it doing:
> >   (exp) ? QString("xyz") : a
> > or
> >   QString(exp ? "xyz" : (const char*)a);
>
> Does QString define an operator const char*() ?

Under certain circumstances.  In "strict" mode it doesn't.


Ciao,
Michael.

Re: :? ??

[Joe Buck]

> On Tue, 19 Mar 2002, Joe Buck wrote:
> 
> > > Is it doing:
> > >   (exp) ? QString("xyz") : a
> > > or
> > >   QString(exp ? "xyz" : (const char*)a);
> >
> > Does QString define an operator const char*() ?
> 
> Under certain circumstances.  In "strict" mode it doesn't.

If there is both an operator const char*() and a constructor that takes
a const char* argument that is not marked explicit, then

	QString qstring_var;
	...
	QString fred = cond ? "foo" : qstring_var;

is ambiguous, otherwise not.

Re: :? ??

[Allan Sandfeld Jensen]

On Tuesday 19 March 2002 19:17, Joe Buck wrote:
> > On Tue, 19 Mar 2002, Joe Buck wrote:
> > > > Is it doing:
> > > >   (exp) ? QString("xyz") : a
> > > > or
> > > >   QString(exp ? "xyz" : (const char*)a);
> > >
> > > Does QString define an operator const char*() ?
> >
> > Under certain circumstances.  In "strict" mode it doesn't.
It does unless QT_NO_ASCII_CAST flag is set, in fact no part of kde would 
compile with this flag since at least the implicit constructor from const 
char* is too widely used.

> If there is both an operator const char*() and a constructor that takes
> a const char* argument that is not marked explicit, then
>
> 	QString qstring_var;
> 	...
> 	QString fred = cond ? "foo" : qstring_var;
>
> is ambiguous, otherwise not.

Well in that case it is ambiguous, they are both defined. Plus operator=, 
the full monty :)
( I didnt know about the explicit mark, but they dont use it anyway )

Sun's compiler might be a little too touchy about type-casting, but in this 
case it is right.  

I have never seen any warnings from gcc, so it should be a problem in 2.95, 
3.0 and 3.1.

`Allan

Re: :? ??

[Michael Matz]

Hi,

On Tue, 19 Mar 2002, Allan Sandfeld Jensen wrote:

> > > > Does QString define an operator const char*() ?
> > >
> > > Under certain circumstances.  In "strict" mode it doesn't.
> It does unless QT_NO_ASCII_CAST flag is set, in fact no part of kde would
> compile with this flag since at least the implicit constructor from const
> char* is too widely used.

Sorry this is wrong. Although we are getting OT here, I want to stop
misinformation.  We compile nearly everything of KDE with
-DQT_NO_ASCII_CAST exactly because we do not want implicit conversion
from/to const char*, because those are i18n killers.  Check your
configures.

> Sun's compiler might be a little too touchy about type-casting, but in this
> case it is right.

No it isn't.


Ciao,
Michael.

$$$$$$$$$$$$$

[DAD]

2 SEE THE BEST CUM SLURPING,BLOW SHOTS ON THE NET CHECK OUT
 THESE YOUNG LITTLE HONEY'S SMEARING THEMSELVES IN JISM 
                 http://www.geocities.com/xxxcumshooters
  CUM,CUM AND MORE CUM. THESE LITTLE WHORES ARE HERE TO EAT EVERY    DROP OF YOUR LOAD AND MORE!!!!!!!!!!                                              http://www.geocities.com/xxxcumshooters
******************************************************************
ALL MEMBERSHIPS RECIEVE ACCESS TO ALL OF OUR 32 SITES/LIMITED OFFER
-------------------------------------------------------------------
FOR THE BEST ANAL FUCK SITE EVER TO BE RELEASED ON THE WEB!!!
          http://www.geocities.com/analxxxaction           
FUCK MY ASS UNTIL IT BLEEDS,PLEASE? THEN I'LL LICK THE SHIT OFF YOUR DICK. HOW I LOVE IT IN THE ASS, AGAIN AND AGAIN!!!!!! 
COME AND ENJOY A FREE TOUR NOW!!!THIS IS HOT XXX RATED SHIT   
                 MY PERSONAL FAVOURITE!!!!!!!                                http://www.geocities.com/analxxxaction 
------------------------------------------------------------------ 
SEE ALL YOUR FAVOURITE CELEBRITIES GETTING FUCKED IN ALL POSITIONS IMAGINABLE. ANNA KOURNICOVA  CATHERINE ZETA JONES CINDY CRAWFORD
ARE JUST A FEW OF THE BIG NAME STARS THAT WE HAVE ON OUR SITE
EVER WONDERED WHAT YOUR FAVOURITE STAR LOOKED LIKE WITH A BIG COCK IN HER ASS           HERE IS YOUR CHANCE
        http://www.geocities.com/superstarxxxpussy
******************************************************************
TO HAVE YOUR EMAIL ADDRESS REMOVED FROM OUR MAILING LISTS GO TO
 http://www.geocities.com/cancelxxcancel

Re: %[

[Mike Stump]

> From: Ulrich Drepper <drepper@cygnus.com>
> Date: 20 Jul 1998 07:26:00 -0700

> If you use a new gcc driver and an old backend (including old specs
> file) you cannot avoid this situation.

Another fine reason why -V (or whatever it is called) should never
have been an option in the first place, it can never work, this is
just another reason in the long list of reasons for using
--prefix==/usr/local/egcs-1.1, or something unique if you want to have
multiple compilers.

%[

[Ulrich Drepper]

I just found that the the latest egcs is buggy on Intel (no details in
the moment) but since I need a compiler a stepped back to the latest
2.91.x version I've lying around.  But this does not work anymore
since the %[ operator is now declared an error.  This is certainly not
desirable.

I suggest to remove the test for the next releases/years.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: %[

[Jeffrey A Law]

  In message < r2k95awrf7.fsf@happy.cygnus.com >you write:
  > I just found that the the latest egcs is buggy on Intel (no details in
  > the moment) but since I need a compiler a stepped back to the latest
  > 2.91.x version I've lying around.  But this does not work anymore
  > since the %[ operator is now declared an error.  This is certainly not
  > desirable.
  > 
  > I suggest to remove the test for the next releases/years.
Where and how are you using %[]

We deliberately remove %[].  Nothing should be using it.

jeff

Re: %[

[Ulrich Drepper]

Jeffrey A Law <law@cygnus.com> writes:

> Where and how are you using %[]
> 
> We deliberately remove %[].  Nothing should be using it.

If you use a new gcc driver and an old backend (including old specs
file) you cannot avoid this situation.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: %[

[Jeffrey A Law]

  In message < r2oguk7g5j.fsf@happy.cygnus.com >you write:
  > Jeffrey A Law <law@cygnus.com> writes:
  > 
  > > Where and how are you using %[]
  > > 
  > > We deliberately remove %[].  Nothing should be using it.
  > 
  > If you use a new gcc driver and an old backend (including old specs
  > file) you cannot avoid this situation.
True, but this kind of thing has never worked reliably.

However, it may be worth bringing %[] back for this case.  I'll think
about it.


jeff

Re: %[

[Marc Lehmann]

On Sun, Jul 19, 1998 at 11:03:49PM -0600, Jeffrey A Law wrote:
> 
>   In message < r2k95awrf7.fsf@happy.cygnus.com >you write:
>   > I just found that the the latest egcs is buggy on Intel (no details in
>   > the moment) but since I need a compiler a stepped back to the latest
>   > 2.91.x version I've lying around.  But this does not work anymore
>   > since the %[ operator is now declared an error.  This is certainly not
>   > desirable.
>   > 
>   > I suggest to remove the test for the next releases/years.
> Where and how are you using %[]
> 
> We deliberately remove %[].

Did we remove it from every gcc version? Don't think so ;)

>  Nothing should be using it.

Almost all version do - what he meant was that he can't call older releases,
which is contro-productive (I fell into the same trap). While "officially",
using "-V" to call older versions of gcc is not supported, it is highly
useful for testing bugs or going back to a non-broken version of gcc.

(otherwise, why don't we just remove -V?)


      -----==-                                              |
      ----==-- _                                            |
      ---==---(_)__  __ ____  __       Marc Lehmann       +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com       |e|
      -=====/_/_//_/\_,_/ /_/\_\                          --+
    The choice of a GNU generation                        |
                                                          |