comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=encomp.lang.c++@googlegroups.com
Today's topics:
* disadvantages of using STL - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/fb1f5fcc56ce965e?hl=en
* usage of uin16_t - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/866a22d1cc8e35a4?hl=en
* why should the SGI set provide the following function - 3 messages, 3
authors
http://groups.google.com/group/comp.lang.c++/t/8cb0207b32d38e2a?hl=en
* A question about a section in "Inside the C++ Object Model" - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/f0c8344a7742e492?hl=en
* Thread and C++ - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/8fd26c749a69d7ad?hl=en
* Corrected: Proposal: Increasing type safety with a keyword - 5 messages, 3
authors
http://groups.google.com/group/comp.lang.c++/t/9cce4bef7f79a39b?hl=en
* Inheritance: Implementing pure virtual functions by inheriting from an
object providing an implementation - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/93aaba3f11367deb?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
* Corrected: Using type suffixes with floating point constants - 3 messages, 2
authors
http://groups.google.com/group/comp.lang.c++/t/e4b6beec5748ef9f?hl=en
* STL set lower_bound - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/aa077da047c4f4a1?hl=en
* what are literal values and symbolic and manifest constants? - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/ef44f833eaeb1f48?hl=en
* geld locker machen,poker 2 online spielen,internet um geld,poker 2 online
spielen,gled verdienen im internet,geld verdienen durch internet, - 1 messages,
1 author
http://groups.google.com/group/comp.lang.c++/t/6b2912fecd2ddc9b?hl=en
* Discount Nike Jordan 1~24 Shoes Manufacture (www.guoshitrade.com) Paypal
Payment - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/d87fa89e87b595b3?hl=en
* (www.salewto.com) cheap nike shoes cheap nike wholesale CA t-shirts - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/07e2393b1740b120?hl=en
==============================================================================
TOPIC: disadvantages of using STL
http://groups.google.com/group/comp.lang.c++/t/fb1f5fcc56ce965e?hl=en
==============================================================================
== 1 of 2 ==
Date: Tues, Mar 31 2009 3:38 am
From: James Kanze
On Mar 30, 6:13 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
> Tony wrote:
> > "Jeff Schwab" <j...@schwabcenter.com> wrote in message
> >news:0YednVRjhOfeq1DUnZ2dnUVZ_g6WnZ2d@giganews.com...
> >> Tony wrote:
> >>> "SG" <s.gesem...@gmail.com> wrote in message
> >>>news:21656158-919d-4044-ad8e-bf5db6c44788@q9g2000yqc.googlegroups.com...
> >>> "One of the main STL advantages is that it's part of the C++ standard"
> >>> I see that as a detriment, not an advantage.
> >> Why?
> > Do you know what a camel is? (And no, that's not the only reason).
> The STL was designed originally by Alex Stepanov, not by
> committee. Anyway, that's not a meaningful answer, just a
> cliche that reiterates your opinion that standardization is
> inherently detrimental. Are you saying that your dislike of
> STL is more philosophical than technical?
If I understand him correctly, he's saying that the STL is too
complicated for him to understand, that he's capable of
designing and implementing something far better, and that he's
not going to tell anyone how or what.
You figure out if that makes any sense. From his postings, I
gather that he doesn't understand beans about software
engineering. (To whit: it doesn't really matter how well
designed you find the STL---it's standard, it's what people know
and understand, and it is sufficient in most cases, so it's what
you use. Whatever it's intrinsic qualities or defaults.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
== 2 of 2 ==
Date: Tues, Mar 31 2009 3:50 am
From: James Kanze
On Mar 30, 6:17 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
> zr wrote:
> > On Mar 17, 10:31 pm, Pallav singh <singh.pal...@gmail.com> wrote:
> >> Q What are the disadvantages of using STL ?
> > Since no one mentioned it, what about code bloat? Is this still an
> > issue in recent implementations?
> It's never been a problem for me.
It probably depends on what you're doing. The STL, in general,
has been designed to favor speed when it comes to speed/space
trade offs, and so is probably inappropriate in contexts where
space is extremely restricted. Which doesn't motivate
implementors to reduce the size of the executable.
More generally, however... If you look at the source code for
the STL, you'll find that underneith it all, it's very simple.
There just isn't that much of it. So if you get two copies of
the code when you instantiate two different types (even though
most of it is identical), the code you write using the instances
(which isn't identical) is usually so much bigger that it
doesn't matter.
> If you do find that your performance is suffering because of
> unnecessary icache misses, there are straight-forward
> techniques to address the problem. (I've heard the old
> technique of partially specializing for all raw pointer types,
> then wrapping a non-template implementation that only uses
> void*, referred to as "hoisting.")
So you gain 40 or 50 bytes of code if you instantiate the class
over two different pointer types, but you still have maybe 100KB
of user code using each instantiation.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
==============================================================================
TOPIC: usage of uin16_t
http://groups.google.com/group/comp.lang.c++/t/866a22d1cc8e35a4?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Mar 31 2009 3:42 am
From: "Alf P. Steinbach"
* James Kanze:
> On Mar 30, 12:30 pm, "Alf P. Steinbach" <al...@start.no> wrote:
>> * Pavan:
>
>>> Hi Can you clarify following questions regarding uint16_t
>
>>> 1> Does uint16_t is supported by Windows compilers also?
>
>> Presumably the "also" means that you're currently using some
>> non-Windows compiler where there is support for uint16_t.
>
>> Type "wikipedia uint16_t" in the Firefox address bar served up
>> a list of Google hits; the first was
>> <url:http://en.wikipedia.org/wiki/Stdint.h>.
>
> Which isn't exactly the best of what Wikipedia has to offer. To
> quote:
>
> Coding Standards for C and C++
>
> This 1999 update to the International Organization for
> Standardization's (ISO) was signed off fully in 2004.
> [...]
>
> Now, I'm not sure what the author means by "signed off
> fully", but <stdint.h> is not part of the C++ standard, even
> today (although it will be, and one can expect most C++
> compilers to support it). (It would also be interesting to
> know where the year 2004 comes from. In C, it has been
> official since 1999, in Posix even earlier, and in C++,
> probably 2010.) It then goes on to say that "Both C and
> C++[citation needed] developers can add #include <stdint.h>
> to their source code [...]", which is also highly dubious as
> a general statement. (The article also quotes the Posix
> standard as the primary source. I believe that the header
> did originate in Posix, but the primary source today is the
> C standard, and in fact, Posix isn't 100% aligned with the C
> standard here---it requires int8_t, etc., indirectly making
> Posix impossible to implement on a machine which doesn't
> have 8 bit bytes, 2's complement, etc.)
Well it's good enough for the OP's question.
>> And that article says "The exact-width types and their
>> corresponding ranges are only included in that header if
>> they exist for that specific compiler/processor.".
>
>> By the way, if a particular compiler doesn't offer [stdint.h]
>> then check out the Boost equivalent.
>
> Which has the same problem: if there is no type of the
> corresponding size, the type won't be defined.
That's not a problem.
It's a feature.
If a compiler doesn't offer [stdint.h] then check out the Boost equivalent.
>>> 2> When I use uint16_t am I always guaranteed that it cannot hold more
>>> than 16 bits
>>> Eg: uint16_t x = 0xffffffff; // Is it always guaranteed that the value
>>> written is only 0xffff
>> See above. That is, as we said in the old days, RTFM. :)
>> Of course, you'd have to find the/a manual first, but it's
>> not really that hard (see above).
>
> Except that in this case, the "manual" (IOS/IEC 9899:1999)
> isn't available on line. (Or did you mean the manual for
> his compiler. That should tell him about the specific
> compiler.)
I meant any documentation. The Wikipedia article is good enough for his purposes.
Cheers,
- Alf
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!
==============================================================================
TOPIC: why should the SGI set provide the following function
http://groups.google.com/group/comp.lang.c++/t/8cb0207b32d38e2a?hl=en
==============================================================================
== 1 of 3 ==
Date: Tues, Mar 31 2009 3:48 am
From: "Alf P. Steinbach"
* James Kanze:
> On Mar 31, 7:40 am, "Alf P. Steinbach" <al...@start.no> wrote:
>> * hpsoar:
>
>>> I'm reading a book on STL, It provides many source codes of
>>> STL's SGI implementation. I found the following function in
>>> class set: iterator
>>> insert(iterator position, const value_type& x);
>>> As I know, the position of a value inserted to is determined
>>> by the red-black tree, which is used when implementing class
>>> set. So why should it provide this function here?
>
>> This looks like an internal implementation detail.
>
>> At some level of implementation an item has to be inserted at
>> some specific position in the internal data structure
>> (whatever that structure is), and naturally there must be some
>> code for that -- used internally.
>
>> It's not something that you should be concerned with as a user.
>
> It's specified in the standard as part of the interface.
> Basically, it guarantees amortised constant time if the new
> element is inserted immediately after the element designated by
> the first parameter, rather than the logrithmic time for other
> inserts. I suspect that it's major use is when initializing a
> set with already sorted data; using this version of insert, the
> initialization is O(n), rather than O(n lg n). (And I suppose
> that somewhere, there are even applications where this makes a
> difference. Even if I've never seen one.)
Thanks.
Learned smth new! :)
Cheers,
- Alf
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!
== 2 of 3 ==
Date: Tues, Mar 31 2009 4:45 am
From: Pete Becker
On 2009-03-31 01:21:21 -0400, hpsoar <hpsoar@gmail.com> said:
> I'm reading a book on STL, It provides many source codes of STL's SGI
> implementation. I found the following function in class set: iterator
> insert(iterator position, const value_type& x);
> As I know, the position of a value inserted to is determined by the
> red-black tree, which is used when implementing class set. So why
> should it provide this function here?
The iterator provides a hint to the implementation as to where the item
might go. If the hint is right, the implementation doesn't have to do
as large a search to find where to insert the item.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)
== 3 of 3 ==
Date: Tues, Mar 31 2009 6:15 am
From: Michael DOUBEZ
James Kanze wrote:
> On Mar 31, 7:40 am, "Alf P. Steinbach" <al...@start.no> wrote:
>> * hpsoar:
>
>>> I'm reading a book on STL, It provides many source codes of
>>> STL's SGI implementation. I found the following function in
>>> class set: iterator
>>> insert(iterator position, const value_type& x);
>>> As I know, the position of a value inserted to is determined
>>> by the red-black tree, which is used when implementing class
>>> set. So why should it provide this function here?
>
>> This looks like an internal implementation detail.
>
>> At some level of implementation an item has to be inserted at
>> some specific position in the internal data structure
>> (whatever that structure is), and naturally there must be some
>> code for that -- used internally.
>
>> It's not something that you should be concerned with as a user.
>
> It's specified in the standard as part of the interface.
> Basically, it guarantees amortised constant time if the new
> element is inserted immediately after the element designated by
> the first parameter, rather than the logrithmic time for other
> inserts. I suspect that it's major use is when initializing a
> set with already sorted data; using this version of insert, the
> initialization is O(n), rather than O(n lg n). (And I suppose
> that somewhere, there are even applications where this makes a
> difference. Even if I've never seen one.)
From an algorithmic point of view it also allows reusing previous
results. Having read Alexander Stepanov's papers, it wouldn't be surprising.
--
Michael
==============================================================================
TOPIC: A question about a section in "Inside the C++ Object Model"
http://groups.google.com/group/comp.lang.c++/t/f0c8344a7742e492?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Mar 31 2009 4:04 am
From: "Fraser Ross"
The previous example in the book has a few mistakes with one
instruction. It should be:
strcpy(&pmumb1->pc[0], string);
Fraser.
==============================================================================
TOPIC: Thread and C++
http://groups.google.com/group/comp.lang.c++/t/8fd26c749a69d7ad?hl=en
==============================================================================
== 1 of 2 ==
Date: Tues, Mar 31 2009 4:06 am
From: James Kanze
On Mar 30, 10:48 pm, s0s...@gmail.com wrote:
> On Mar 30, 1:47 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> > s0s...@gmail.com wrote:
> > > On Mar 30, 6:35 am, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> > >> baibaichen wrote:
> > >>> in C++, is the assignment to a primitive variable atomic? for exmpale:
> > >>> int i;
> > >>> i++; //atomic?
> > >> You're changing an uninitialised value, which has undefined behavior.
> > >>> i +2; //atomic?
> > >> That expression has no side effects, so why care if it's
> > >> atomic or not?
> > >> And, no, in the language as it's defined *now* nothing is
> > >> atomic unless you're using some kind of language
> > >> extensions, like OpenMP and its pragmas. In the upcoming
> > >> Standard simple operations are not defined as atomic
> > >> implicitly, there is a special *library* section on
> > >> atomic operations.
> > > How about <signal.h>'s sig_atomic_t (which is likely to be
> > > defined as int anyway)?
> > I am not sure I understand the question. How about it what?
> Well, as I understand it, sig_atomic_t is an integer type that
> can be accessed "as an atomic entity",
Only in certain contexts, for a restricted set of operations.
In fact, I'm not sure that you could call the guarantees
involving it "atomic".
> which means that an operation on it takes a single machine
> instruction.
That's not the definition of atomic. Lot's of operations which
only take a single machine instruction aren't atomic. (A lot of
processors can implement ++ i in a single instruction, provided
the results are not used; I don't know of any where it is
atomic.) And it's quite possible to design atomic operations
involving more than one instruction.
> (I'm not sure which operations exactly, but the reference I'm
> reading mentions "fetching" its value and assigning a value to
> it.)
> Isn't this what the OP asked about?
He mentionned i++, amongst other things. That isn't atomic,
even on a sig_atomic_t.
> > The *current* Standard does not say it's "likely to be defined as int".
> > And the operations on that type are *not* defined [as atomic or even
> > at all].
> Why does it have "atomic" in its name then?
You'd have to ask the people who designed it (or named it).
It's "atomicity" is very restrained.
When you speak about "atomicity", you have to specify the
context somewhat. A lot of operations, for example, will be
"atomic" on a single processor machine, but not if multiple
CPU's are involved. Concerning sig_atomic_t, the C standard
(and the C++ standard, by reference) says that it is the
"integer type of an object that can be accessed as an atomic
entity, even in the presence of asynchronous interrupts." The
only "context" refered to is "the presence of asynchronous
interrupts". Furthermore, it states that "the behavior is
undefined if the signal handler refers to any object with static
storage duration other than by assigning a value to an object
declared as volatile sig_atomic_t, or the signal handler calls
any function in the standard library other than the abort
function, the _Exit function, or the signal function with the
first argument equal to the signal number corresponding to the
signal that caused the invocation of the handler." That's
awfully restrictive.
> > AIUI, the explicit guarantee WRT the values of type
> > 'volatile sig_atomic_t' has nothing to do with adding or
> > incrementing integral values, and with respect to threads.
> > The guarantees have everything to do with signals and
> > handlers of those signals. There is but one word "thread"
> > in the entire current Standard.
> It doesn't necessarily relate to threads. The purpose of
> sig_atomic_t is to allow a signal handler to manipulate an
> integer variable with static storage duration without the risk
> that the handler is invoked during an operation on the
> variable (leaving the variable with a garbage value).
The problem is that the standard doesn't really guarantee this.
The standard doesn't say much of anything about what happens
when you modify sig_atomic_t outside of a signal handler.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
== 2 of 2 ==
Date: Tues, Mar 31 2009 4:10 am
From: James Kanze
On Mar 30, 11:29 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> s0s...@gmail.com wrote:
[...]
> > It doesn't necessarily relate to threads. The purpose of
> > sig_atomic_t is to allow a signal handler to manipulate an
> > integer variable
> OK, so the C Standard defines 'sig_atomic_t' as integer, and
> yes, the C Standard says that those values ("possibly
> volatile-qualified") "can be accessed as an atomic entity".
> This is from C99, which is not supported by the C++ Standard
> yet, and I don't have a copy of C90. Are those defined the
> same way in C90 (and by inclusion, in C++03)?
Yes.
> I've never seen *a single use* of 'sig_atomic_t' in a program,
> hopefully it explains my lack of familiarity with
> 'sig_atomic_t'.
In a modern, threaded environment, there's really very little
use for it. At least under Unix (but I'm sure the same holds
for Windows), you can set things up so that the signal triggers
a thread, and then do anything you want in that thread (subject
to the usual restrictions). Without threading, it's useful for
things like signaling a request for a clean shutdown: before
activating signals, you set a global sig_atomic_t to 0, then at
various places in the code, you test it, and start a clean
shutdown if it isn't 0. In the signal handler, you set it to 1.
That's really about all that it guaranteed to work.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
==============================================================================
TOPIC: Corrected: Proposal: Increasing type safety with a keyword
http://groups.google.com/group/comp.lang.c++/t/9cce4bef7f79a39b?hl=en
==============================================================================
== 1 of 5 ==
Date: Tues, Mar 31 2009 4:19 am
From: Ioannis Vranos
Ioannis Vranos wrote:
> Proposal:
>
> We can increase type safety in C++ by adding a single keyword. The
> current proposal uses the keyword "only".
>
>
> Example 1:
>
> only int x= 4;
>
> x= 5; // Ok
>
> x= 5.0; // Error
>
> x= 5U // Error
>
>
>
> Example 2:
>
> int i= 5;
>
> only unsigned x= 4U;
>
> x= 5; // Error
>
> x= 5LU; // Error
>
> x= i; // Error
>
>
>
> Example 3:
>
> only float f= 4.0F;
>
> f= 4; // Error
>
> f= 5.0; // Error
>
> f= 4.0F; // OK
>
>
>
>
> // It accepts any built in type
> void somefunc(const int &x);
>
>
> // It accepts only an int and a const int object
> void somefunc(only const int &x);
>
>
>
>
> It is simple like that, and the concept is backwards compatible.
>
>
>
>
> What do you think?
More cases:
only double d1 = 1F; // That would be an error. Type mismatch (float assigned to double).
only double d2 = 1; // That would be an error. Type mismatch (int assigned to double).
d1 = 1F; // That would be an error. Type mismatch (float assigned to double).
d2 = 1; // That would be an error. Type mismatch (int assigned to double).
short s = 1; // That would be correct, since the keyword "only" is missing.
In the case of
only short s= 1;
it could be an error (type mismatch), if a postfix for short constants was provided, for example H/h.
short s= 1H; could work. And (UH/uh for unsigned short constants).
only int i = s; // That would be an error. Type mismatch (short assigned to int).
i = s; // That would be an error. Type mismatch (short assigned to int).
Another use of "only":
#include <iostream>
void somefunc(only int)
{
std::cout<< "somefunc(int) was called\n";
}
void somefunc(only double)
{
std::cout<< "somefunc(double) was called\n";
}
int main(void)
{
// OK, int is passed
somefunc(4);
// Error
somefunc(4U);
// OK, double is passed
somefunc(4.0);
// Error
somefunc(4.0F);
}
== 2 of 5 ==
Date: Tues, Mar 31 2009 5:26 am
From: Ioannis Vranos
Because of the unavoidable mistakes, typos and other, and also to keep track how the proposal evolves, I have
created a web page for it:
http://www.cpp-software.net/documents/cpp_only_proposal.html
So please base your answers to that document.
== 3 of 5 ==
Date: Tues, Mar 31 2009 5:29 am
From: Victor Bazarov
Ioannis Vranos wrote:
> Ioannis Vranos wrote:
>> Proposal:
>>
>> We can increase type safety in C++ by adding a single keyword. The
>> current proposal uses the keyword "only".
>>
>>
>> Example 1:
>>
>> only int x= 4;
>>
>> x= 5; // Ok
>>
>> x= 5.0; // Error
>>
>> x= 5U // Error
>>
>>
>>
>> Example 2:
>>
>> int i= 5;
>>
>> only unsigned x= 4U;
>>
>> x= 5; // Error
>>
>> x= 5LU; // Error
>>
>> x= i; // Error
>>
>>
>>
>> Example 3:
>>
>> only float f= 4.0F;
>>
>> f= 4; // Error
>>
>> f= 5.0; // Error
>>
>> f= 4.0F; // OK
>>
>>
>>
>>
>> // It accepts any built in type
>> void somefunc(const int &x);
>>
>>
>> // It accepts only an int and a const int object
>> void somefunc(only const int &x);
>>
>>
>>
>>
>> It is simple like that, and the concept is backwards compatible.
>>
>>
>>
>>
>> What do you think?
>
>
>
> More cases:
>
> [... effects of implementing the 'only' keyword ...]
I am yet to see the actual *problem* with any of those cases. Is your
suggestion just for the sake of changing the language, making an impact,
so to speak?
If you have encountered a *real-world* problem that cannot be solved
without adding your new mechanism for preventing implicit conversions
and promotions, could you please state it?
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 5 ==
Date: Tues, Mar 31 2009 5:54 am
From: Vladyslav Lazarenko
On Mar 31, 7:19 am, Ioannis Vranos <ivra...@freemail.gr> wrote:
> Ioannis Vranos wrote:
> > Proposal:
>
> > We can increase type safety in C++ by adding a single keyword. The
> > current proposal uses the keyword "only".
>
> > Example 1:
>
> > only int x= 4;
>
> > x= 5; // Ok
>
> > x= 5.0; // Error
>
> > x= 5U // Error
>
> > Example 2:
>
> > int i= 5;
>
> > only unsigned x= 4U;
>
> > x= 5; // Error
>
> > x= 5LU; // Error
>
> > x= i; // Error
>
> > Example 3:
>
> > only float f= 4.0F;
>
> > f= 4; // Error
>
> > f= 5.0; // Error
>
> > f= 4.0F; // OK
>
> > // It accepts any built in type
> > void somefunc(const int &x);
>
> > // It accepts only an int and a const int object
> > void somefunc(only const int &x);
>
> > It is simple like that, and the concept is backwards compatible.
>
> > What do you think?
>
> More cases:
>
> only double d1 = 1F; // That would be an error. Type mismatch (float assigned to double).
>
> only double d2 = 1; // That would be an error. Type mismatch (int assigned to double).
>
> d1 = 1F; // That would be an error. Type mismatch (float assigned to double).
>
> d2 = 1; // That would be an error. Type mismatch (int assigned to double).
>
> short s = 1; // That would be correct, since the keyword "only" is missing.
>
> In the case of
>
> only short s= 1;
>
> it could be an error (type mismatch), if a postfix for short constants was provided, for example H/h.
>
> short s= 1H; could work. And (UH/uh for unsigned short constants).
>
> only int i = s; // That would be an error. Type mismatch (short assigned to int).
>
> i = s; // That would be an error. Type mismatch (short assigned to int).
>
> Another use of "only":
>
> #include <iostream>
>
> void somefunc(only int)
> {
> std::cout<< "somefunc(int) was called\n";
>
> }
>
> void somefunc(only double)
> {
> std::cout<< "somefunc(double) was called\n";
>
> }
>
> int main(void)
> {
> // OK, int is passed
> somefunc(4);
>
> // Error
> somefunc(4U);
>
> // OK, double is passed
> somefunc(4.0);
>
> // Error
> somefunc(4.0F);
>
>
>
> }
I agree with Viktor. There are a lot of real-world problems where
implicit conversions of type hierarchies are extremely helpful. I
don't have a clue why you should deny them. It would be nice to see a
real-world problem where you need it.
Also, what do you think about denying explicit casting?
http://en.wikibooks.org/wiki/C%2B%2B_Programming/Type_Casting
== 5 of 5 ==
Date: Tues, Mar 31 2009 6:04 am
From: Ioannis Vranos
Victor Bazarov wrote:
>
> I am yet to see the actual *problem* with any of those cases. Is your
> suggestion just for the sake of changing the language, making an impact,
> so to speak?
>
> If you have encountered a *real-world* problem that cannot be solved
> without adding your new mechanism for preventing implicit conversions
> and promotions, could you please state it?
What you say is a correct approach. I have to note here, that the proposal is a work in progress, and it
doesn't explain what happens with classes, class hierarchies, etc, yet.
The next thing to be added, is how the keyword would work in constructors.
Well, given the proposal as it currently is, an example of real world type safety problem, is having a
function returning a double:
only double somefunc()
{
double value= 1.0;
// Perform some operations
return value;
}
int main()
{
int x= somefunc(); // The compiler catches the error
}
==============================================================================
TOPIC: Inheritance: Implementing pure virtual functions by inheriting from an
object providing an implementation
http://groups.google.com/group/comp.lang.c++/t/93aaba3f11367deb?hl=en
==============================================================================
== 1 of 2 ==
Date: Tues, Mar 31 2009 4:26 am
From: Jaco Naude
On Mar 31, 11:27 am, Jaco Naude <naude.j...@gmail.com> wrote:
> On Mar 31, 10:57 am, "Alf P. Steinbach" <al...@start.no> wrote:
>
>
>
> > * Jaco Naude:
>
> > > Hi
>
> > > I'm wondering if an idea that I have should work. Well the compiler
> > > (mingw) does not seem to allow it, but I'm not sure why it does not
> > > work.
>
> > > I have an interface class:
>
> > > class IManagable {
> > > public:
> > > virtual void setID(int new_id) = 0;
> > > virtual int getID() = 0;
> > > }
>
> > > And an object implementing this interface:
>
> > > class ManagableObject {
> > > public:
> > > ManagableObject () { id = -1; }
> > > ~ManagableObject ();
>
> > > // Implement functions
> > > inline void setID(int new_id) { id = new_id; }
> > > inline int getID() { return id; }
>
> > > private:
> > > int id;
> > > }
>
> > > I've read in the FAQ that inheritance should not be used for code
> > > reuse in general. But in my case I think it is a good idea. I want to
> > > be able to assign unique IDs to objects implementing the interface. If
> > > all of these objects can use the interface as well as the
> > > ManagableObject implementation of the interface, it will reduce my
> > > workload quite a lot I believe.
>
> > > Now the problem. I have an object that I want to be able to manage
> > > that looks like this:
>
> > > class ManageMe : virtual public IManagable, public ManagableObject {
> > > ManageMe () {}
> > > ~ManageMe () {}
> > > }
>
> > > This complains that the IManagable pure virtual public functions
> > > aren't implemented by ManageMe. So my approach to accomplish this is
> > > not working. Is there a different way that I can do this without
> > > having to implement the IManagable interface in ManageMe (where the
> > > implementation calls the ManagableObject functions).
>
> > > Thanks in advance for any advice
>
> > class ManagableObject: public virtual IManagable
>
> > Cheers & hth.,
>
> > - Alf
>
> > --
> > Due to hosting requirements I need visits to <url:http://alfps.izfree.com/>.
> > No ads, and there is some C++ stuff! :-) Just going there is good. Linking
> > to it is even better! Thanks in advance!
>
> Hi Alf
>
> Thanks for the suggestion, I have not thought of that.
>
> I'll give it a go.
> Thanks
> Jaco
Hi again,
I've tried the new implementation but casting becomes really confusing
in this implementation. Let me give some details on my implementation.
The ManageMe class from my first post looks like this:
class ManageMe: public GCF::AbstractComponent, public ManagableObject,
virtual public IToolbox, virtual public IData
where each of the parent classes are defined as follows (Using Qt,
hence the reason for the QObject class below):
class AbstractComponent : public QObject -- This is a singleton
class ManagableObject : virtual public IManagable
class IData : virtual public IContainer
class IToolbox : virtual public IContainer
class IManagable : virtual public IContainer
The IContainer class is a container class defined as follows:
class IContainer
{
public:
virtual QObject* containerObject() = 0;
};
In the ManageMe class the IContainer interface is implemented as
follows:
QObject* ManageMe ::containerObject()
{
return this;
}
Ok, that's my class hierarchy explained. Now I'm trying to cast to
IManagable* when I have a QObject pointer. The way I try to do it is
shown below and causes a program crash:
if (qobject_ptr) {
ManagableObject* tmp_ref = dynamic_cast<ManagableObject*>
(qobject_ptr);
if (tmp_ref) {
IManagable* managable_ptr = dynamic_cast<IManagable*>
(tmp_ref);
if (managable_ptr) {
// Access managable_ptr's contents here causes crash.
}
}
}
I've tried various variations of the above without anything working.
How is it possible to do this? Is it possible at all?
Thank you
Jaco
== 2 of 2 ==
Date: Tues, Mar 31 2009 5:30 am
From: "Alf P. Steinbach"
* Jaco Naude:
>
> Hi again,
>
> I've tried the new implementation but casting becomes really confusing
> in this implementation.
Casting is generally to be avoided. :)
> Let me give some details on my implementation.
> The ManageMe class from my first post looks like this:
>
> class ManageMe: public GCF::AbstractComponent, public ManagableObject,
> virtual public IToolbox, virtual public IData
>
> where each of the parent classes are defined as follows (Using Qt,
> hence the reason for the QObject class below):
Hm. I only tried installing Qt once, for Windows. Had to try to install three
times to get it working, and the backspace key didn't work in the installation
dialog; one wonders how on Earth they managed to make that not work. I was very
tempted to walk up the street to Trolltech and tell them how uncute their
product was, and even more tempted when I tried to uninstall...
> class AbstractComponent : public QObject -- This is a singleton
Double hm. Singletons are generally problematic. When you inherit from a
singleton class, if that's what you're doing, how do you ensure the singleton
will be of your class?
> class ManagableObject : virtual public IManagable
> class IData : virtual public IContainer
> class IToolbox : virtual public IContainer
> class IManagable : virtual public IContainer
No AbstractComponent here, AFAICS.
> The IContainer class is a container class defined as follows:
>
> class IContainer
> {
> public:
> virtual QObject* containerObject() = 0;
> };
From the name it sames that an IContainer /contains/ a QObject.
> In the ManageMe class the IContainer interface is implemented as
> follows:
>
> QObject* ManageMe ::containerObject()
> {
> return this;
> }
If this compiles then it seems ManageMe inherits from QObject.
> Ok, that's my class hierarchy explained. Now I'm trying to cast to
> IManagable* when I have a QObject pointer.
Well, above I see no inheritance relationship between IManagable and QObject. On
the contrary, IManagable implements the IContainer interface. Which indicates
that an IManagable is an interface on an object that /contains/ a QObject.
> The way I try to do it is shown below and causes a program crash:
>
> if (qobject_ptr) {
> ManagableObject* tmp_ref = dynamic_cast<ManagableObject*>
> (qobject_ptr);
> if (tmp_ref) {
> IManagable* managable_ptr = dynamic_cast<IManagable*>
> (tmp_ref);
> if (managable_ptr) {
> // Access managable_ptr's contents here causes crash.
> }
> }
> }
>
> I've tried various variations of the above without anything working.
> How is it possible to do this? Is it possible at all?
Try to reproduce the problem in a *minimal* program.
That often helps.
But also think about inheritance versus containment, and think about that
singleton thing -- could be a problem.
Also, it seems you have a needless proliferation of interface classes.
Interface abstraction is good when it helps you avoid doing wrong things or
helps avoid too close coupling, but it's bad when any realistic concrete class
has to implement and expose umpteen interfaces. Then the abstraction tool that
should simplify things instead complicates things. That happened a lot with COM;
if you look up the standard joke "progression of a programmer" starting with
hello, world in basic, and so on, the final horrifying mess is COM-based code.
Cheers & hth.,
- Alf
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!
==============================================================================
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: Tues, Mar 31 2009 5:14 am
From: James Kanze
On Mar 30, 1:46 pm, Christof Donat <c...@okunah.de> wrote:
> > On Mar 29, 2:07 pm, Christof Donat <c...@okunah.de> wrote:
> >> > As I said, I've yet to find anything important that I could
> >> > do in Java that I couldn't do in C++, and I've extensive
> >> > experience in both languages.
> >> I'd say, e.g. writing web applications in C++ is a bit more
> >> difficult than just hacking a servlet.
> > And I'd agree. But it's not a language problem, and probably
> > not even a library problem. The existing infrastructure in web
> > servers is designed to support Java;
> No. Most installed web servers use apache as server software.
> Apache doesn't support java without any additional modules and
> an external server process, but apache supports C modules
> without any changes. It is a problem of the API. The apache
> module API is - well - a bit more complicated thant the
> servlet API.
Do you know of any Apache servers running without the Java
module. (Come to think of it, our intranet server does. But it
just serves up web pages; it doesn't do anything interactive or
that would require any "programming".)
> I agree with you, that it is not a language problem, but I
> think it is a library problem.
> > it's not designed to support any compiled language.
> Well, C is a compiled language, isn't it? Apart from the
> apache module interface the CGI interface as well as the
> FastCGI Interfacce is completely language agnostic. You could
> even write CGI scripts in Java - just that it will start the
> whole VM for every request. The difference is that scripting
> languages like Perl, Python or Ruby come with an API that
> supports easy writing of portable CGI applications.
Yes. And the Perl interpreter is "compiled" as well. The
lowest level interface has to be at the lowest level, which
means machine code, which is what comes out of the compiler.
But in practice, I can't imagine anyone using this level
directly. As you say, it's a bit more complicated than the
alternatives. But it's true that my distinction concerning
compiled languages is probably not valid. Although it does seem
that all of the higher level API's available are for interpreted
or byte coded languages: Java, Perl, Python, Ruby...
When I spoke of support, I was thinking more in terms of
embedded development tools. I don't think that Apache has any
of these, but other products, like WebLogic or WebSphere do.
But your point is well taken; even before worrying about
embedded debugging, the available API is an issue. And for
whatever reasons, I'm not aware of such an API for C++; I'm not
even sure who should be responsible for it. It obviously
doesn't belong in ISO's hands, since it's only relevant for a
small subset of environments. Maybe Apache should define and
implement one.
> > If there were a demand for it, it probably wouldn't be that
> > hard to implement a server which supported C++,
> Web developers care much about not binding themselves to a
> speciffic implementation. Java servlets work with any servlet
> container, not just tomcat. CGI scripts written in Perl work
> anywehere where a Perl interpreter is available and the
> Webserver supports the CGI interface (virtually any). PHP
> scripts just need one of three ways to get the PHP interpreter
> run: apache module, CGI or FastCGI.
A C++ program can handle CGI too. As you say, the problem is in
the API for accessing it. CGI is standardized, but it's a bit
low level. (One can argue, however, that C++ already has the
interface, standardized, in the form of getenv() and std::cout.
Except that you can't output binary on std::cout.)
> As an example why this might be important: beginning with
> version 2 apache supports multithreaded operation in contrast
> to just multiple processes. The PHP apache module does not.
> whenever you whant to use the PHP apache module you must go
> back to processes. For a customer we switched to the FastCGI
> Version of PHP without any code changes. Then we could use a
> multithreaded MPM module which increased the throughput of the
> server more than one order of magnitude on the same hardware.
And how would this have been any different if you'd have used
C++? Except that you would have had to access at a lower level.
> > but typically, the code the server addresses
> > directly consists of a lot of small, constantly changing modules
> > (Java beans)---something where the weaknesses of Java aren't
> > really significant.
> That is not true as well. Typically a web application itsself
> doesn't change too much if it is well thought out.
Typically, web applications aren't well thought out:-). I don't
know, but the pages I access do seem to change a lot.
[...]
> > Whatever happened to JSP?
> There still seem to be some people out there using it, but it
> has proven to be the worst of two worlds. Well designed web
> applications that should stay so usually don't use JSP.
> Whenever you use JSP as view abstraction in a application that
> will be maintained by multiple developers, someone will come
> along and put code into the JSP that doesn't belong in the
> view, but in the application layer.
> As you see, JSP is considered harmfull. Use explicit template
> systems like e.g. XSLT instead.
Well, I wasn't too impressed with the idea when I used it (a
little bit in early 2002). It seemed like a case of mixing
concerns which should have been separate. Putting all the HTML
in the Java (or C++) code was obviously a pain, but hiding the
Java code buried in the middle of a lot of HTML seemed like just
exchanging one problem for another. (I've been doing a lot of
code generation lately, and I ended up designing and
implementing a template approach as well. All those lines
outputting boilerplate ended up obscuring the actual logic.)
> Of course the same thing happens with PHP, but that is just a
> basic language problem of PHP that Java itsself doesn't have.
> Why add it?
> > And if I were doing a lightweight GUI client, I'd probably
> > choose Java, simply because Swing seems better than either
> > wxWidgets or Qt.
> Actually I'd prefer either XUL/XBL/JavaScript or Python/PyQt.
Since I don't know them, I can't say.
> > there's nothing that the standards
> > committee could do, for example, to force web servers to give
> > C++ the same level of support they give Java.
> As I said, I don't think it should be in the standard.
I don't think it can be. It's a little too specialized. On the
other hand, an organization like W3C could define such.
> A well defined API, like WSGI for Python as a start, and a
> fiew implementations that are as portable as possible and can
> use various server APIs (e.g. apache module, FastCGI and CGI)
> or run as a minimal stand allone HTTP server would be a good
> beginning. Not in the standard, but very closely related to
> it.
> How could this happen? The committe I guess has a lot of more
> important things to do. So maybe we could find some interested
> people and first describe such a API and then implement it. If
> the committe spreads the word of that API as the state of the
> art way of implementing web applications with C++, that would
> be great support for their part.
The problem is that ISO doesn't really have any procedure for
issuing "recommended practices". And it's lead times are
probably too long for this domain as well. The advantage of
Java or C# here is that they belong to a single company, and
don't have to spend the time building consensus. (Of course, in
many ways, that's really a disadvantage. But it sure can
shorten your lead times.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
==============================================================================
TOPIC: Corrected: Using type suffixes with floating point constants
http://groups.google.com/group/comp.lang.c++/t/e4b6beec5748ef9f?hl=en
==============================================================================
== 1 of 3 ==
Date: Tues, Mar 31 2009 5:18 am
From: Ioannis Vranos
Because of the unavoidable mistakes, typos and other, and also to keep track how the proposal evolves, I have
created a web page for it:
http://www.cpp-software.net/documents/cpp_only_proposal.html
So please base your answers to that document.
== 2 of 3 ==
Date: Tues, Mar 31 2009 5:26 am
From: Ioannis Vranos
Ioannis Vranos wrote:
> Because of the unavoidable mistakes, typos and other, and also to keep
> track how the proposal evolves, I have created a web page for it:
>
> http://www.cpp-software.net/documents/cpp_only_proposal.html
>
>
> So please base your answers to that document.
Wrong thread, sorry.
== 3 of 3 ==
Date: Tues, Mar 31 2009 5:35 am
From: Victor Bazarov
Ioannis Vranos wrote:
> Because of the unavoidable mistakes, typos and other, and also to keep
> track how the proposal evolves, I have created a web page for it:
>
> http://www.cpp-software.net/documents/cpp_only_proposal.html
>
>
> So please base your answers to that document.
Please amend your proposal with the description of the problems you're
trying to solve. "Increase type safety" reads like hand waving, it's
too generic. Please don't repeat by stating what the mechanism would
do, I think by now we all get it. Explain *why* you want conversions to
be ignored in certain cases, and what prevents you from solving those
problems using the existing mechanisms in the language. Thanks!
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
==============================================================================
TOPIC: STL set lower_bound
http://groups.google.com/group/comp.lang.c++/t/aa077da047c4f4a1?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Mar 31 2009 6:09 am
From: Michael DOUBEZ
Juha Nieminen wrote:
> Michael DOUBEZ wrote:
>> Because lower_bound returns an iterator pointing to the first element in
>> s1 which *does not* compare less than 5.
>>
>> 8 is the first value where (!(8<5)).
>
> Another way of thinking about it: If you insert the searched value at
> the position returned by lower_bound, the data container will still be
> ordered after the insertion.
It is true but IMHO it is more a property than a definition.
--
Michael
==============================================================================
TOPIC: what are literal values and symbolic and manifest constants?
http://groups.google.com/group/comp.lang.c++/t/ef44f833eaeb1f48?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Mar 31 2009 6:33 am
From: red floyd
Roedy Green wrote:
> On Mon, 30 Mar 2009 22:57:01 -0700 (PDT), S Claus
> <santa@temporaryinbox.com> wrote, quoted or indirectly quoted someone
> who said :
>
>> sorry about this but could anyone give me a simple explanation of what
>> is a "literal" and what is a "symbolic constant" and what is a
>> "manifest constant"?
>
> See http://mindprod.com/jgloss/literal.html for literal
>
> http://mindprod.com/jgloss/constant.html for symbolic constant.
>
> I have never heard of a manifest constant.
>
I believe manifest constants are symbolic constants that are defined by
the implementation.
e.g.:
__unix__, etc...
==============================================================================
TOPIC: geld locker machen,poker 2 online spielen,internet um geld,poker 2
online spielen,gled verdienen im internet,geld verdienen durch internet,
http://groups.google.com/group/comp.lang.c++/t/6b2912fecd2ddc9b?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Mar 31 2009 6:37 am
From: guyute305@googlemail.com
geld locker machen,poker 2 online spielen,internet um geld,poker 2
online spielen,gled verdienen im internet,geld verdienen durch
internet,
+
+
+
+++ GELD ONLINE VERDIENEN +++ GELD IM INTERNET VERDIENEN +++
+
http://www.online-geld-verdienen-24.eu
http://WWW.online-geld-verdienen-24.eu
http://WWW.online-geld-verdienen-24.eu
http://WWW.online-geld-verdienen-24.eu
http://WWW.online-geld-verdienen-24.eu
http://WWW.online-geld-verdienen-24.eu
http://WWW.online-geld-verdienen-24.eu
http://WWW.online-geld-verdienen-24.eu
http://WWW.online-geld-verdienen-24.eu
+
+
+
+
+
http://WWW.GELD-ONLINE-VERIENEN.NET
amerikan poker online spielen im internet verdienen ohne in Singapur
internet um geld möglichkeiten im internet geld in Mosbach
geld verdienen am schnellsten geld machen in Landau
kann man online geld verdienen 2 schnell geld in Heiligenstadt
online geld verdienen forum wie kann ich leicht geld in Nordrhein-
Westfalen
geld verdienen in online online echtes geld in Großbritannien
gutes geld machen partnerprogramm geld verdienen in Bayern
mit internet geld gw geld machen in Kaiserslautern
geld in online musik geld machen in Saudi-Arabien
http://suche.aol.de/aol/search?query=www+geld+verdienen+de+inurl%3Afor-um&invocationType=no.omittWeb&filter=false
==============================================================================
TOPIC: Discount Nike Jordan 1~24 Shoes Manufacture (www.guoshitrade.com)
Paypal Payment
http://groups.google.com/group/comp.lang.c++/t/d87fa89e87b595b3?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Mar 31 2009 7:00 am
From: Tim Slattery
imuaplease@gmail.com wrote:
>Ok, can you stop posting trash around google's bin ? This bin does not
>prefer your trash
Can you stop reposting all the trash and giving the spammer more
exposure?
--
Tim Slattery
Slattery_T@bls.gov
http://members.cox.net/slatteryt
==============================================================================
TOPIC: (www.salewto.com) cheap nike shoes cheap nike wholesale CA t-shirts
http://groups.google.com/group/comp.lang.c++/t/07e2393b1740b120?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Mar 31 2009 7:28 am
From: fjrj001@163.com
we have set up long-term and closed cooperation with many
manufacturers and factories. TOP & BEST quality of products, high
reputation, excellent services and professionalism are those that we
used compete with others. We sincerely wish to cooperate with you and
to make mutual benefit! We will be your first choice of suppliers for
TOP quality products!
Best Service, Highest Quality, Competitive price, Timely delivery
as
its philosophy,
we are to fully cooperate on the basis of equality and mutual benefit
with business partners from all over the world.
We could supply mixed colors and sizes shoes for you. Your
satisfaction is our final target.
(paypal payment)( www.salewto.com )
Jeans
diesel jeans
designer jeans
stretch jeans
low rise jeans
men's jeans (paypal payment)( www.salewto.com )
skinny jeans
fashion jeans
jeans seven
jeans boot cut (paypal payment)( www.salewto.com )
womens diesel jeans
man diesel jeans
womens jeans (paypal payment)( www.salewto.com )
buy diesel jeans
evisu jeans
7 jeans
mens jeans (paypal payment)( www.salewto.com )
Jean
Artful Dodger Jean
A&F Jean (paypal payment)( www.salewto.com )
Affliction Jean
Armani Jean
Bape Jeans (paypal payment)( www.salewto.com )
BBC Jeans
Christian Audigier jeans
Coogi Jeans
D&G Jeans
Diesel Jeans
Ed hardy Jeans (paypal payment)( www.salewto.com )
Evisu Jeans
G-star Jean
Gino Green Global
LRG Jeans
Pants (paypal payment)( www.salewto.com )
Red Monkey Jeans
Rcover Jeans
Rock Republic Jean
Rock Women Jeans
Seven Jean (paypal payment)( www.salewto.com )
True Religion
True Religion Women
(paypal payment)( www.salewto.com )
air jordan
T-Shirt
lacoste t shirt
Lacoste Men's shirts
ralph lauren polo
Polo long sleeve shirt (paypal payment)( www.salewto.com )
a&f t shirt
Artful Dodger t shirts
Abercrombie Fitch
Affliction Shirt
Armani shirt
Bape/Ape Shirt (paypal payment)( www.salewto.com )
BBC Shirt
Burberry
Christan Audigier
Coogi Shirt
D&G shirts (paypal payment)( www.salewto.com )
Ed hardy Shirt
Ed hardy Women
Evisu t-shirt
Gino Green Global (paypal payment)( www.salewto.com )
Juicy t-shirt
Lacoste Shirt (paypal payment)( www.salewto.com )
Polo Shirt
Smet Shirt
(paypal payment)( www.salewto.com )
air jordan
Jersey
NFL Jersey (paypal payment)( www.salewto.com )
NBA Jersey
NHL Jersey (paypal payment)( www.salewto.com )
MLB Jersey
Football Jersey
(paypal payment)( www.salewto.com )
air jordan
Hoodies
Artful Dodger
AK Hoody
Affliction Hoody (paypal payment)( www.salewto.com )
Bape/Ape Hoody
BBC Hoody (paypal payment)( www.salewto.com )
Christan Audigier
CLH Hoody
ED-Hardy Hoody (paypal payment)( www.salewto.com )
Coogi Hoody
Evisu Hoody
G-Star Hoody (paypal payment)( www.salewto.com )
Gino Green Global
Kidrobot Hoody (paypal payment)( www.salewto.com )
LRG Hoody
Parish Hoody
Polo Hoody
10 Deep Hoody
(paypal payment)( www.salewto.com )
air jordan
Jacket
Adidas Jacket (paypal payment)( www.salewto.com )
A&F men Jacket
A&F women Jacket (paypal payment)( www.salewto.com )
Bape Jacket
BBC Jacket
ED Jacket (paypal payment)( www.salewto.com )
(paypal payment)( www.salewto.com )
air jordan
Sweater
A&F Sweater (paypal payment)( www.salewto.com )
Armani sweater
Boss sweater (paypal payment)( www.salewto.com )
D&G sweater
Lacoste Sweater
Polo sweater (paypal payment)( www.salewto.com )
Prada sweater
(paypal payment)( www.salewto.com )
air jordan
Suit
Baby Phat
Burberry suit
Dior suit
Juicy Couture suit
(paypal payment)( www.salewto.com )
air jordan
Consumer electrics
GHD
MK4 (paypal payment)( www.salewto.com )
MK5
Hair straightener
Hair products (paypal payment)( www.salewto.com )
Hair accessories
Ipod 3rd generation
Ipod 4th generation (paypal payment)( www.salewto.com )
Ipod nano
Ipod touch
(paypal payment)( www.salewto.com )
air jordan
Sun Glasses
New Sunglasses
Armani Glasses (paypal payment)( www.salewto.com )
Burberry Glasses
D&G Glasses
Chanel Glasses (paypal payment)( www.salewto.com )
Dior Glasses (paypal payment)( www.salewto.com )
Fendi Glasses
Gucci Glasses
Okely Glasses (paypal payment)( www.salewto.com )
LV Glasses
Prada Glasses (paypal payment)( www.salewto.com )
Versace Glasses
Belt
Armani Belt (paypal payment)( www.salewto.com )
D&G Belt
ED hardy Belt
Gucci Belt (paypal payment)( www.salewto.com )
LV Belt
Other brands belt (paypal payment)( www.salewto.com )
Hat (paypal payment)( www.salewto.com )
New Hat
Christan Audigier
Ed hardy Hat (paypal payment)( www.salewto.com )
ERA Hat
Gucci Hat
==============================================================================
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
