comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=encomp.lang.c++@googlegroups.com
Today's topics:
* negative powers of two - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/50db9695edc9e79f?hl=en
* New release of the Dynace OO extension to C - 9 messages, 5 authors
http://groups.google.com/group/comp.lang.c++/t/ee8689156295093c?hl=en
* static inline functions - possible? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/0386357e12bd0064?hl=en
* How to return a reference, when I really need it - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/2062f1cc85db88f2?hl=en
* ★⊙★Brand Shoes Online Store, wholesale Air Force one,Nike Jordan,Nike Air
Max,Nike Shox,Burberry,Bape,Adidas,etc.★-→www.fjrjtrade.com (Paypal Payment&
Free Shipping) - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/94e2d65f9049bf3d?hl=en
* Printing the last item of a structure twice - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/9fd75392aae26667?hl=en
* dealing with lower level programmers - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/f708a2c0cfa8ce2d?hl=en
* ♡♪♡Wholesale Nokia ,Iphone, Samsung, Blackberry, Sony, Motorola,etc brand
mobiles "www.toptradea.com" ◆ Our policy: order 1-3pce brand mobile with a
free polo Tshirt, order more than 5 pcs brand mobiles with a free nike sneaker
(time limited) - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/fe3606d4b2851580?hl=en
* ◎♥◎Wholesale Tshirt and Jeans BBC,Evis,POLO,Lacoste,Affliction ,Gucci,
Edhardy,Armani,LV,Christina Audigier ◎www.toptradea.com◎ - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/ae9996302e270d55?hl=en
* ☆*-*☆Handbags supplier ¤www.toptradea.com¤ Lady Handbags Juicy,Gucci,LV,
Prada,D&G,Edhardy,Chanel,Coach, Jimmy-Hoo,Burberry,DB ┈━♥◎♥→ - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/94fa848366c7d863?hl=en
* ☆◆☆Wholesale Nokia N series N97,N96,N86,N81,N85,N78,N79,N72,5800,8800,8600,
6500,6300,5800 ♪ ♪ ♪ Our policy: order 1-3pce brand mobile with a free polo
Tshirt, order more than 5 pcs brand mobiles with a free nike sneaker (time
limited)♪♪♪ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/8912ce8c161014b7?hl=en
==============================================================================
TOPIC: negative powers of two
http://groups.google.com/group/comp.lang.c++/t/50db9695edc9e79f?hl=en
==============================================================================
== 1 of 2 ==
Date: Fri, Jul 31 2009 11:05 am
From: Pete Becker
Jerry Coffin wrote:
>
> Whether this will be faster than pow() will depend -- for a lot of
> cases where the floating point is stored as a significand and a power
> of two, frexp will be something like a mask, shift and an integer
> subtraction to remove a bias in the exponent. As you'd expect, ldexp
> will pretty much reverse that: add the bias, shift to the right
> position, OR with the significand. Generally pretty fast. OTOH, if
> the native floating point representation is drastically different
> from that, they could end up pretty slow -- but machines with such
> strange floating point representations are pretty unusual.
>
Strange floating-point representations like decimal? <g> Decimal
floating-point is specified (along with binary) in IEEE 754-2008, and
provided as extensions to C by TR 24732 and to C++ by DTR 24733
(approved for balloting at the Frankfurt meeting).
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)
== 2 of 2 ==
Date: Fri, Jul 31 2009 11:40 am
From: Jerry Coffin
In article <8radnVF2p5Yar-7XnZ2dnUVZ_i2dnZ2d@giganews.com>,
pete@versatilecoding.com says...
[ ... ]
> Strange floating-point representations like decimal? <g> Decimal
> floating-point is specified (along with binary) in IEEE 754-2008, and
> provided as extensions to C by TR 24732 and to C++ by DTR 24733
> (approved for balloting at the Frankfurt meeting).
Yes, that's probably the most obvious anyway. At least AFAIK, about
the only machines that use it are IBM z-series. I believe somewhere
along the line IBM also added decimal FP hardware to the POWER
processors (around POWER 5 or 6) but I believe they use binary
floating point by default, only switching to decimal if its
explicitly enabled. I'd guess most C and C++ compilers leave it set
for binary FP, though it wouldn't surprise me if COBOL compilers (for
one example) normally switched it to use decimal FP instead.
--
Later,
Jerry.
==============================================================================
TOPIC: New release of the Dynace OO extension to C
http://groups.google.com/group/comp.lang.c++/t/ee8689156295093c?hl=en
==============================================================================
== 1 of 9 ==
Date: Fri, Jul 31 2009 11:49 am
From: Juha Nieminen
BGB / cr88192 wrote:
> you seem to be opposing "coding conventions".
> coding conventions can be more or less equated with code being well
> written...
I'm not opposing coding conventions. I use lots of coding conventions
when I develop programs.
What I oppose are coding conventions which exist solely to get around
limitations of the language. These tend to make programs more complex
than they need to be.
Yes, I readily admit that programming in C++ is in no way free of
necessary coding conventions which exist because of the limitations of
C++ (compared to many higher-level languages). My point is, however,
that in well-written C++ *less* coding conventions of this type are
needed compared to C, making development simpler. Also, many of these
coding conventions are more familiar to most experienced C++ programmers
and can be seen much more easily (eg. because they are used by the C++
standard libraries and such). In C most of these coding conventions are
quite programmer-specific.
> why should one worry about more vs less conventions?...
Because more coding conventions makes the program more difficult to
read and understand.
A coding convention is kind of "metalanguage" in the sense that you
are writing in your own "subset" of the programming language. You use a
kind of "meta-C" on top of the bare C programming language, for the
purpose of avoiding pitfalls and errors (such as memory leaks, etc).
The problem is that your "metalanguage" might not be immediately
obvious to someone reading your code and who doesn't know about your
coding conventions.
When these extra coding conventions are *not needed* (rather than
intentionally avoided), the code tends to be more straightforward and
simpler, without any hidden "metalanguage" being used.
== 2 of 9 ==
Date: Fri, Jul 31 2009 12:13 pm
From: "Bo Persson"
BGB / cr88192 wrote:
> "Juha Nieminen" <nospam@thanks.invalid> wrote in message
> news:NlEcm.129$sW4.42@read4.inet.fi...
>> Nick Keighley wrote:
>>> what coding conventions does C typically use that C++ typically
>>> doesn't?
>>> Isn't the use of RAII a massive coding convention?
>>
>> No. RAII is certainly not a coding convention. It's a compiler
>> technique and has little to do with coding conventions. A coding
>> convention is something the *programmer* does, while RAII is
>> something the *compiler* does automatically.
>>
>> If, for example, I instantiate and manipulate a std::string in a
>> function, I don't need *any* coding conventions to make sure that
>> the string gets freed: The compiler is going to free it for me. I
>> don't have to do anything to achieve that.
>>
>> In C, however, if I use a dynamic string in a function, I have to
>> free it myself, and to avoid leaks in complicated functions I have
>> to use some coding principles to make sure that the string gets
>> freed no matter how the function is exited.
>>
>> That's precisely what I'm talking about: RAII aids me in avoiding
>> a useless coding convention which I would have to use in C to make
>> the my code safer.
>
> as a side note:
> WRT strings, this is why I typically very rarely use strdup...
> strdup is a memory leak just waiting to happen (likewise for
> malloc...).
> so, as part of my little "convention", I tend to use functions
> which intern all the strings (typically, these are localized to
> particular libraries).
> char *basm_strdup(char *str);
> char *sxil_strdup(char *str);
> ...
>
> then again, I guess the "strdup" could be a hurdle, since the
> resultant string is interned, rather than allocated...
>
> so, my usual approach:
> any work on a string is done in a buffer;
> the string is interned, and regarded as immutable.
>
> granted, one doesn't want to use this with any large chunk of text,
> since typically these interned strings are not going away (making
> it "sort of like a memory leak"). some sort of GC-mechanism for
> interned strings could be done, but I have typically not done so
> (since short strings have a tendency of being very repetitive, and
> the total number of them being finite).
>
> it is worth noting, however, that a partial solution to this has
> been the use of the "allocate, bulk-free" strategy (or, in Quake
> terms, the "Hunk" strategy). basically, where the strings are
> interned into a temporary local heap, and upon leaving the general
> region, the entire strings-table is destroyed as well.
>
> this is actually the strategy typically used in my compilers (many
> of my compiler stages each use their own localized heaps).
>
> the reason for doing this was that compilers tend to produce huge
> amounts of "garbage" all at once, and because using the main
> heap/GC tended to hurt performance too badly...
>
> if there is one thing the "hunk" strategy is good at, it is being
> fast (since an entire heap can be torn down nearly all at once, vs
> having to manage and individually free particular items...).
>
>
> so, alas, maybe this is why "conventions" are disliked...
> the idea of each separate major library and subsystem having its
> own mini subset of the C runtime...
>
> but, hell, it works for me...
>
> one just has to understand my naming conventions.
>
> simple hint:
> if using anything that does not use my "library" notation, and does
> not have the same name prefix as the other code around it, take
> caution...
> SXIL_
> BASM_
> BGBCC_
> ...
>
> if in "SXIL" one sees a function call with a "BGBCC" prefix, this
> itself is a flag for alarm...
>
> note "sxil" or "basm" is not as bad (since these are typically
> simple utility functions), but still cause for concern (for
> example, in the case of the string functions, they may intern the
> string in the wrong heap, or potentially none at all...).
>
> but, alas, a good portion of my "style" revolves around naming
> conventions...
So that's why we C++ guys prefer std::string, which solves all of
this. :-)
Bo Persson
== 3 of 9 ==
Date: Fri, Jul 31 2009 12:49 pm
From: "Chris M. Thomasson"
"BGB / cr88192" <cr88192@hotmail.com> wrote in message
news:h4v8sr$p2d$1@news.albasani.net...
>
> "Juha Nieminen" <nospam@thanks.invalid> wrote in message
> news:abycm.52$sW4.12@read4.inet.fi...
>> Tech07 wrote:
>>> My
>>> secondary point was that RAII is only one stylistic approach one can
>>> take in
>>> C++ as "one size fits all" is never true.
>>
>> Well, I have found that RAII fits at least 99% of sizes, and that's
>> reason enough for me to prefer C++ over C. But that might be just me.
>
>
> well, unless one can live with alternative memory-management schemes (AKA:
> not malloc), which can offer some of the same benefits, but without
> necessitating using a C++ (good, for example, when a decent chunk of ones'
> project may be JIT compiled with a custom compiler...).
>
> as mentioned elsewhere, "localized heaps" is another strategy, where each
> task/subsystem is given its own localized heap...
>
>
> GC is another strategy, but is not used as much in many cases, in part,
> because it is slower (among other issues). as a result, local heaps and
> bulk freeing tends to be much better as a higher-performance strategy
> (leaving the GC mostly for more "generic" code...).
>
> that or devising a "more effective" garbage collector...
>
> at times, I had considered the possibility of integrating similar sorts of
> "bulk free" capabilities into the GC, but have not done so thus far. it
> would either require segregating the heap, or tagging objects, the latter
> allowing easily moving objects to the global heap (inferring from the
> APIs, I think the JVM does something like this...).
>
> however, the "bulk free" could be accomplished with a variation of the
> sweep phase, rather than needing to do a full GC pass...
>
> using seperate heaps/allocators is simpler though...
I am quite fond of region allocators. Here is a simple example
implementation I created:
http://pastebin.com/f37a23918
This region allocator does not force all allocations to be aligned up to a
so-called maximum alignment like `malloc' and friends are required to do.
For instance, allocations for a single char will not be forced to waste the
extra alignment space. This can have benefits in space constrained
environments (e.g., embedded devices). Also, its static in nature and can be
fed with a buffer residing on the stack. There are no underlying calls to
`malloc'. This can be useful in free standing environments that do not
support heap allocation. One other thing. Its a pure region allocator which
means you do not need to free individual objects. You can free the entire
region. This is more efficient than calling `malloc()/free()' for each
object. For instance, you can destroy all the nodes in a linked list just by
freeing the region(s) in which the nodes were allocated from. There is no
need to traverse the list to free its nodes. Its a sort of "manual" garbage
collection... ;^)
You can use it like:
_________________________________________________________________
#include <ralloc.h>
struct foo {
struct foo* next;
};
#include <stdio.h>
void crunch() {
char local_buffer[1024];
struct region local_region;
struct foo* head1 = NULL;
struct foo* head2 = NULL;
size_t i, r;
rinit(&local_region, local_buffer, sizeof(local_buffer));
for (r = 0; r < 1024; ++r) {
size_t c = 0;
for (i = 0; i < 64; ++i) {
struct foo* foo = ralloct(&local_region, 2, struct foo);
if (foo) {
foo->next = head1;
head1 = foo;
++foo;
foo->next = head2;
head2 = foo;
c += 2;
}
}
while (head1) {
head1 = head1->next;
--c;
}
while (head2) {
head2 = head2->next;
--c;
}
assert(! c);
rflush(&local_region);
}
}
int main(void) {
crunch();
crunch();
crunch();
return 0;
}
_________________________________________________________________
IMVHO, that's kind of cool... ;^)
== 4 of 9 ==
Date: Fri, Jul 31 2009 1:48 pm
From: Keith H Duggar
On Jul 14, 10:48 am, Blake McBride <bl...@mcbride.name> wrote:
> Miles Bader wrote:
> > Juha Nieminen <nos...@thanks.invalid> writes:
> >> "Dynace is not an interpretive language. Dynace programs are compiled
> >> with a standard C compiler. The majority of the code is just standard
> >> compiled C code with no performance penalty. The only place Dynace
> >> incurs a runtime cost is at the point of method dispatch. Since C++ also
> >> incurs a runtime cost when using virtual functions, there is not much of
> >> a difference between the performance of Dynace programs when compared to
> >> C++."
>
> >> is misleading. From what I can gather, in Dynace, like in Objective-C,
> >> *all* method calls are dynamically bound, so they always incur a
> >> penalty. You conveniently chose to compare them only to C++ virtual
> >> functions and skipped commenting on non-virtual functions. Someone who
> >> doesn't know C++ might get the wrong impression that in C++ all method
> >> calls are also always dynamically bound.
>
> In C++, if you use all virtual functions, the dispatch tables grow
> geometrically.
I don't think the phrase "grow geometrically" means what you think
it means. Please post the growth equation you have in mind. Pretty
much exactly what Nick asked for.
KHD
== 5 of 9 ==
Date: Fri, Jul 31 2009 3:47 pm
From: "BGB / cr88192"
"Bo Persson" <bop@gmb.dk> wrote in message
news:7dgu1rF2cak0cU1@mid.individual.net...
> BGB / cr88192 wrote:
>> "Juha Nieminen" <nospam@thanks.invalid> wrote in message
>> news:NlEcm.129$sW4.42@read4.inet.fi...
<snip>
>>
>> as a side note:
>> WRT strings, this is why I typically very rarely use strdup...
>> strdup is a memory leak just waiting to happen (likewise for
>> malloc...).
>> so, as part of my little "convention", I tend to use functions
>> which intern all the strings (typically, these are localized to
>> particular libraries).
>> char *basm_strdup(char *str);
>> char *sxil_strdup(char *str);
>> ...
>>
>> then again, I guess the "strdup" could be a hurdle, since the
>> resultant string is interned, rather than allocated...
>>
>> so, my usual approach:
>> any work on a string is done in a buffer;
>> the string is interned, and regarded as immutable.
>>
>> granted, one doesn't want to use this with any large chunk of text,
>> since typically these interned strings are not going away (making
>> it "sort of like a memory leak"). some sort of GC-mechanism for
>> interned strings could be done, but I have typically not done so
>> (since short strings have a tendency of being very repetitive, and
>> the total number of them being finite).
>>
>> it is worth noting, however, that a partial solution to this has
>> been the use of the "allocate, bulk-free" strategy (or, in Quake
>> terms, the "Hunk" strategy). basically, where the strings are
>> interned into a temporary local heap, and upon leaving the general
>> region, the entire strings-table is destroyed as well.
>>
>> this is actually the strategy typically used in my compilers (many
>> of my compiler stages each use their own localized heaps).
>>
>> the reason for doing this was that compilers tend to produce huge
>> amounts of "garbage" all at once, and because using the main
>> heap/GC tended to hurt performance too badly...
>>
>> if there is one thing the "hunk" strategy is good at, it is being
>> fast (since an entire heap can be torn down nearly all at once, vs
>> having to manage and individually free particular items...).
>>
>>
>> so, alas, maybe this is why "conventions" are disliked...
>> the idea of each separate major library and subsystem having its
>> own mini subset of the C runtime...
>>
>> but, hell, it works for me...
>>
>> one just has to understand my naming conventions.
>>
>> simple hint:
>> if using anything that does not use my "library" notation, and does
>> not have the same name prefix as the other code around it, take
>> caution...
>> SXIL_
>> BASM_
>> BGBCC_
>> ...
>>
>> if in "SXIL" one sees a function call with a "BGBCC" prefix, this
>> itself is a flag for alarm...
>>
>> note "sxil" or "basm" is not as bad (since these are typically
>> simple utility functions), but still cause for concern (for
>> example, in the case of the string functions, they may intern the
>> string in the wrong heap, or potentially none at all...).
>>
>> but, alas, a good portion of my "style" revolves around naming
>> conventions...
>
> So that's why we C++ guys prefer std::string, which solves all of this.
> :-)
>
yep...
C++ is for those who can safely use it though...
it is not as good when there is a high probability of JIT being thrown into
the mix, where "C-safe" options are essentially a requirement...
C++ is also a problem, since many of my automated tools are not really
capable of dealing with C++, ...
so, alas, C++ would be a general solution, if I (or someone else) were to
write all of the needed tools, such as, for example, the tools to
automatically process my source and write my headers for me... (for example,
I would have to rewrite my auto-headering tools to be capable of dealing
with C++ style syntactic elements...). note that these tools tend not to use
full parsers, so it is probably less of an issue than for tools which use
full parsers...
note that, as an interesting side effect, these semi-parser based tools are
very sensitive to issues of code formatting, since largely formatting is
used to help distinguish one piece of syntax from another... usually the
tools, depending on the task, either ignore or pass through any unrecognized
syntax (process the syntax that is cared about, ignore the rest...).
this is actually sort of like typical Objective-C frontends, which basically
process some elements, but ignore everything else...
so, costs of C++ in my case:
risks making an issue for JIT;
would, very possibly, force me to write all my own headers...
however, for some of my libraries I do use C++, but it is a subset...
one of the major things left out:
namespaces...
which is fairly sad, since that and operator overloading would be one of the
main temptations...
of course, the use of namespaces would defeat one of my major code
organization/management elements:
the use of specialized naming conventions...
my library which uses C++ though, mostly uses it for sake of classes and
operator overloading, and also because it is designed in a certain way:
the only things meant to be used externally are the main API, where the
whole API is declared "extern C"...
so, extern C for APIs, and I guess I will probably have to make many of my
auto-tools C++ friendly eventually... (actually... I think some partly are
already, as I had noticed when adapting some of my tools before for certain
tasks, support for things like '::' syntax and similar, probably as a result
of some of the rare code of mine which is C++...).
so, it is all tradeoffs...
or such...
>
> Bo Persson
>
>
== 6 of 9 ==
Date: Fri, Jul 31 2009 4:18 pm
From: "BGB / cr88192"
"Juha Nieminen" <nospam@thanks.invalid> wrote in message
news:w0Hcm.217$sW4.146@read4.inet.fi...
> BGB / cr88192 wrote:
>> you seem to be opposing "coding conventions".
>> coding conventions can be more or less equated with code being well
>> written...
>
> I'm not opposing coding conventions. I use lots of coding conventions
> when I develop programs.
>
> What I oppose are coding conventions which exist solely to get around
> limitations of the language. These tend to make programs more complex
> than they need to be.
>
> Yes, I readily admit that programming in C++ is in no way free of
> necessary coding conventions which exist because of the limitations of
> C++ (compared to many higher-level languages). My point is, however,
> that in well-written C++ *less* coding conventions of this type are
> needed compared to C, making development simpler. Also, many of these
> coding conventions are more familiar to most experienced C++ programmers
> and can be seen much more easily (eg. because they are used by the C++
> standard libraries and such). In C most of these coding conventions are
> quite programmer-specific.
>
actually, I refer to what you call "programmer specific" as "style"...
different programmers use different styles, yes, this much is granted.
however, the point is that one recognize the various common styles, and use
a style as appropriate for the code in question.
I have my own style as well, which is sort of a combination of the Linux
kernel, id, and OpenGL styles, or, another way: the Torvalds, John Carmack,
and SGI styles...
one can adhere to certain styles, such that their code looks nice and
pleasing...
so, beyond specific for particular coding conventions, style also
encompasses matters like variable naming, the use of whitespace and other
formatting issues, ...
it is also a good way to spot "outsiders"...
if (...) {
...
"WTF is this?... go away weirdo..."
>> why should one worry about more vs less conventions?...
>
> Because more coding conventions makes the program more difficult to
> read and understand.
>
personally, I don't see it this way.
the style and conventions are a good portion of the readability, IMO...
> A coding convention is kind of "metalanguage" in the sense that you
> are writing in your own "subset" of the programming language. You use a
> kind of "meta-C" on top of the bare C programming language, for the
> purpose of avoiding pitfalls and errors (such as memory leaks, etc).
>
granted...
> The problem is that your "metalanguage" might not be immediately
> obvious to someone reading your code and who doesn't know about your
> coding conventions.
>
hence, "outsiders"...
they are, naturally enough, to be viewed with suspicion, as they are bent on
fouling up ones' code with their ways...
> When these extra coding conventions are *not needed* (rather than
> intentionally avoided), the code tends to be more straightforward and
> simpler, without any hidden "metalanguage" being used.
not sure why...
my main reason for not going through all of the usual conventions is when
quickly beating together something under the "make it work" goal...
but typically, this sort of code tends to be ugly, buggy, and just generally
horrid...
and so, later, I clean it up...
it is like being in a store, and noticing all the terribly ill-behaved
children, and then being reminded of a certain rule: "children should be
seen but not heard"...
impulsive behavior and noise one year, is fornication and moral depravity
the next...
"he who spares the rod hates his son."
...
or such...
== 7 of 9 ==
Date: Fri, Jul 31 2009 4:27 pm
From: "BGB / cr88192"
"Chris M. Thomasson" <no@spam.invalid> wrote in message
news:lVHcm.49062$O23.35177@newsfe11.iad...
> "BGB / cr88192" <cr88192@hotmail.com> wrote in message
> news:h4v8sr$p2d$1@news.albasani.net...
>>
>> "Juha Nieminen" <nospam@thanks.invalid> wrote in message
>> news:abycm.52$sW4.12@read4.inet.fi...
>>> Tech07 wrote:
>>>> My
>>>> secondary point was that RAII is only one stylistic approach one can
>>>> take in
>>>> C++ as "one size fits all" is never true.
>>>
>>> Well, I have found that RAII fits at least 99% of sizes, and that's
>>> reason enough for me to prefer C++ over C. But that might be just me.
>>
>>
>> well, unless one can live with alternative memory-management schemes
>> (AKA: not malloc), which can offer some of the same benefits, but without
>> necessitating using a C++ (good, for example, when a decent chunk of
>> ones' project may be JIT compiled with a custom compiler...).
>>
>> as mentioned elsewhere, "localized heaps" is another strategy, where each
>> task/subsystem is given its own localized heap...
>>
>>
>> GC is another strategy, but is not used as much in many cases, in part,
>> because it is slower (among other issues). as a result, local heaps and
>> bulk freeing tends to be much better as a higher-performance strategy
>> (leaving the GC mostly for more "generic" code...).
>>
>> that or devising a "more effective" garbage collector...
>>
>> at times, I had considered the possibility of integrating similar sorts
>> of "bulk free" capabilities into the GC, but have not done so thus far.
>> it would either require segregating the heap, or tagging objects, the
>> latter allowing easily moving objects to the global heap (inferring from
>> the APIs, I think the JVM does something like this...).
>>
>> however, the "bulk free" could be accomplished with a variation of the
>> sweep phase, rather than needing to do a full GC pass...
>>
>> using seperate heaps/allocators is simpler though...
>
>
> I am quite fond of region allocators. Here is a simple example
> implementation I created:
>
>
> http://pastebin.com/f37a23918
>
>
> This region allocator does not force all allocations to be aligned up to a
> so-called maximum alignment like `malloc' and friends are required to do.
> For instance, allocations for a single char will not be forced to waste
> the
> extra alignment space. This can have benefits in space constrained
> environments (e.g., embedded devices). Also, its static in nature and can
> be
> fed with a buffer residing on the stack. There are no underlying calls to
> `malloc'. This can be useful in free standing environments that do not
> support heap allocation. One other thing. Its a pure region allocator
> which
> means you do not need to free individual objects. You can free the entire
> region. This is more efficient than calling `malloc()/free()' for each
> object. For instance, you can destroy all the nodes in a linked list just
> by
> freeing the region(s) in which the nodes were allocated from. There is no
> need to traverse the list to free its nodes. Its a sort of "manual"
> garbage
> collection... ;^)
>
>
yep...
granted, I typically either supply my mini-heaps with memory gained either
from malloc, or from mmap or VirtualAlloc or friends...
<snip, example>
>
>
> IMVHO, that's kind of cool... ;^)
>
yep...
== 8 of 9 ==
Date: Fri, Jul 31 2009 4:32 pm
From: "BGB / cr88192"
"Keith H Duggar" <duggar@alum.mit.edu> wrote in message
news:55307634-d32e-461f-80e6-c4aa6cd19613@b15g2000yqd.googlegroups.com...
> On Jul 14, 10:48 am, Blake McBride <bl...@mcbride.name> wrote:
>> Miles Bader wrote:
>> > Juha Nieminen <nos...@thanks.invalid> writes:
>> >> "Dynace is not an interpretive language. Dynace programs are compiled
>> >> with a standard C compiler. The majority of the code is just standard
>> >> compiled C code with no performance penalty. The only place Dynace
>> >> incurs a runtime cost is at the point of method dispatch. Since C++
>> >> also
>> >> incurs a runtime cost when using virtual functions, there is not much
>> >> of
>> >> a difference between the performance of Dynace programs when compared
>> >> to
>> >> C++."
>>
>> >> is misleading. From what I can gather, in Dynace, like in Objective-C,
>> >> *all* method calls are dynamically bound, so they always incur a
>> >> penalty. You conveniently chose to compare them only to C++ virtual
>> >> functions and skipped commenting on non-virtual functions. Someone who
>> >> doesn't know C++ might get the wrong impression that in C++ all method
>> >> calls are also always dynamically bound.
>>
>> In C++, if you use all virtual functions, the dispatch tables grow
>> geometrically.
>
> I don't think the phrase "grow geometrically" means what you think
> it means. Please post the growth equation you have in mind. Pretty
> much exactly what Nick asked for.
>
would be ammusing if it did though...
one writes a few classes, some with maybe a few too many methods: "holy
crap!... this EXE is HUGE!!...".
> KHD
== 9 of 9 ==
Date: Fri, Jul 31 2009 5:10 pm
From: Keith H Duggar
On Jul 31, 7:32 pm, "BGB / cr88192" <cr88...@hotmail.com> wrote:
> "Keith H Duggar" <dug...@alum.mit.edu> wrote in messagenews:55307634-d32e-461f-80e6-c4aa6cd19613@b15g2000yqd.googlegroups.com...
>
>
>
>
>
> > On Jul 14, 10:48 am, Blake McBride <bl...@mcbride.name> wrote:
> >> Miles Bader wrote:
> >> > Juha Nieminen <nos...@thanks.invalid> writes:
> >> >> "Dynace is not an interpretive language. Dynace programs are compiled
> >> >> with a standard C compiler. The majority of the code is just standard
> >> >> compiled C code with no performance penalty. The only place Dynace
> >> >> incurs a runtime cost is at the point of method dispatch. Since C++
> >> >> also
> >> >> incurs a runtime cost when using virtual functions, there is not much
> >> >> of
> >> >> a difference between the performance of Dynace programs when compared
> >> >> to
> >> >> C++."
>
> >> >> is misleading. From what I can gather, in Dynace, like in Objective-C,
> >> >> *all* method calls are dynamically bound, so they always incur a
> >> >> penalty. You conveniently chose to compare them only to C++ virtual
> >> >> functions and skipped commenting on non-virtual functions. Someone who
> >> >> doesn't know C++ might get the wrong impression that in C++ all method
> >> >> calls are also always dynamically bound.
>
> >> In C++, if you use all virtual functions, the dispatch tables grow
> >> geometrically.
>
> > I don't think the phrase "grow geometrically" means what you think
> > it means. Please post the growth equation you have in mind. Pretty
> > much exactly what Nick asked for.
>
> would be ammusing if it did though...
>
> one writes a few classes, some with maybe a few too many methods: "holy
> crap!... this EXE is HUGE!!...".
LOL ... yeah we would be looking forward to 128-bit and 256-bit
and so on systems just so we could address our exe images. LOL,
damn that was a good one, I needed that, thanks!
KHD
==============================================================================
TOPIC: static inline functions - possible?
http://groups.google.com/group/comp.lang.c++/t/0386357e12bd0064?hl=en
==============================================================================
== 1 of 2 ==
Date: Fri, Jul 31 2009 11:52 am
From: Juha Nieminen
Balog Pal wrote:
> "Juha Nieminen" <nospam@thanks.invalid>
>> Balog Pal wrote:
>>> I worked with those separated inlines -- at a time made some myself, my
>>> net
>>> conclusion is it makes things worse.
>> Makes what worse?
>
> readability, understandability, maitainance...
IMO the readability of a class declaration suffers if all the inline
functions are implemented inside the declaration. They tend to make the
class declaration very large (in lines of code).
If the class is very small (in number of inline member functions) and
all the inline functions are one-liners, then it's ok, but not otherwise.
== 2 of 2 ==
Date: Fri, Jul 31 2009 12:27 pm
From: "Balog Pal"
"Juha Nieminen" <nospam@thanks.invalid> az alábbiakat írta a következo
hírüzenetben: w3Hcm.219$sW4.158@read4.inet.fi...
> Balog Pal wrote:
>> "Juha Nieminen" <nospam@thanks.invalid>
>>> Balog Pal wrote:
>>>> I worked with those separated inlines -- at a time made some myself, my
>>>> net
>>>> conclusion is it makes things worse.
>>> Makes what worse?
>>
>> readability, understandability, maitainance...
>
> IMO the readability of a class declaration suffers if all the inline
> functions are implemented inside the declaration. They tend to make the
> class declaration very large (in lines of code).
>
> If the class is very small (in number of inline member functions) and
> all the inline functions are one-liners, then it's ok, but not otherwise.
Exactly :), that is how calsses shall better look. If there is a ton of
functions, and you want the compiler inline fat functions, I'd guess the
problems will not come from organizing them in the header, and will hardly
be cured by extracting those inlines.
And classes with non-obvoius interface need doxy-like tools even more.
==============================================================================
TOPIC: How to return a reference, when I really need it
http://groups.google.com/group/comp.lang.c++/t/2062f1cc85db88f2?hl=en
==============================================================================
== 1 of 3 ==
Date: Fri, Jul 31 2009 11:56 am
From: Juha Nieminen
Balog Pal wrote:
> returrning a vector filled with a copy of a row IS inefficient compared to
> retrirning a reference to that row.
I believe he was talking about *creating* a vector and returning it by
value, vs. *creating* a vector (somewhere) and returning a reference to it.
With return value optimization the vector instance will be created (in
optimal conditions) on the caller's stack, which will usually be more
efficient than creating it somewhere else and returning a reference to it.
But of course avoiding the *creation* of the vector in the first place
is the most optimal solution.
== 2 of 3 ==
Date: Fri, Jul 31 2009 11:57 am
From: Juha Nieminen
Jerry Coffin wrote:
> std::vector<float> row(matrix[i][0], matrix[i][cols]);
Are you sure that works? Maybe you meant:
std::vector<float> row(&matrix[i][0], &matrix[i][cols]);
== 3 of 3 ==
Date: Fri, Jul 31 2009 12:10 pm
From: Jerry Coffin
In article <c8Hcm.223$sW4.194@read4.inet.fi>, nospam@thanks.invalid
says...
>
> Jerry Coffin wrote:
> > std::vector<float> row(matrix[i][0], matrix[i][cols]);
>
> Are you sure that works? Maybe you meant:
>
> std::vector<float> row(&matrix[i][0], &matrix[i][cols]);
Oops -- of course you're right. My apologies for the obviously
incorrect code.
--
Later,
Jerry.
==============================================================================
TOPIC: ★⊙★Brand Shoes Online Store, wholesale Air Force one,Nike Jordan,Nike
Air Max,Nike Shox,Burberry,Bape,Adidas,etc.★-→www.fjrjtrade.com (Paypal
Payment&Free Shipping)
http://groups.google.com/group/comp.lang.c++/t/94e2d65f9049bf3d?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Jul 31 2009 12:12 pm
From: candy
China factory promotions Nike Shox NZ at www.fjrjtrade.com (paypal
payment)
LV SHOES
(http://www.fjrjtrade.com/category-940-b0-LV-Shoes.html)
New ACG shoes
Nike Air Max
(http://www.fjrjtrade.com/category-920-b0-Nike-Air-Max.html)
Girl TN
Man Nike Air Max 180
Man Nike Air Max 360 (paypal payment)(www.fjrjtrade.com)
Man Nike Air Max 2009
(http://www.fjrjtrade.com/category-920-b0-Nike-Air-Max.html)
Nike Air Max 87-91
Nike Air Max 95
Nike Air Max 97
(http://www.fjrjtrade.com/category-920-b0-Nike-Air-Max.html)
Nike Air Max 2003
Nike Air Max 2004
Nike Air Max 2005 (paypal payment)(www.fjrjtrade.com)
Nike Air Max 2006
Nike Air Max Ltd
Nike Air Max TN
(http://www.fjrjtrade.com/category-920-b0-Nike-Air-Max.html)
Women Nike Air Max 95
Women Nike Air Max TN
(http://www.fjrjtrade.com/category-920-b0-Nike-Air-Max.html)
Nike Dunk (paypal payment)(www.fjrjtrade.com)
High cup
Nike Dunk
women size (paypal payment)(www.fjrjtrade.com)
NIKE FREE
Nike Rift
Man Nike Rift (paypal payment)(www.fjrjtrade.com)
Women Nike Rift
(http://www.fjrjtrade.com/category-921-b0-Nike-Shox.html)
Nike Shox
New Man Nike Shox
New Women Nike Shox (paypal payment)(www.fjrjtrade.com)
Nike Shox Monster
Nike Shox NZ
Nike Shox NZ OZ Fusions
(http://www.fjrjtrade.com/category-921-b0-Nike-Shox.html)
Nike Shox OZ
Nike Shox R3
Nike Shox R4
(http://www.fjrjtrade.com/category-921-b0-Nike-Shox.html)
Nike Shox TL1
Nike Shox TL3 (paypal payment)(www.fjrjtrade.com)
Nike Shox TL5
Nike Shox Turob
(http://www.fjrjtrade.com/category-921-b0-Nike-Shox.html)
OBAMA 08 Shoes
PRADA SHOES
(http://www.fjrjtrade.com/category-945-b0-Prada-Shoes.html )
PUMA SHOES
(http://www.fjrjtrade.com/category-923-b0-Puma-Shoes.html)
RIFT
Sandal (paypal payment)(www.fjrjtrade.com)
Supra shoes
Timberland
(http://www.fjrjtrade.com/category-948-b0-Timberland-Shoes.html )
UGG BOOT
(http://www.fjrjtrade.com/category-922-b0-UGG-Shoes.html)
Ugg Boots
2008 SHOES
Adidas
(http://www.fjrjtrade.com/category-914-b0-Adidas-Shoes.html)
Man Adicolor
Men Adidas
Air Force 1
(http://www.fjrjtrade.com/category-916-b0-Air-Force-one.html)
AF1 Women
Air Force One High
Air force One low
Women Coach shoes (paypal payment)(www.fjrjtrade.com)
ARIMANI SHOES
Women ED Hardy Boots
Ato shoes
Men Ato shoes (paypal payment)(www.fjrjtrade.com)
Women Ato shoes
Suit
BAPE SHOES
CHANEL SHOES (paypal payment)(www.fjrjtrade.com)
CONVERSE shoes
DG SHOES
DSQUARED SHOES (paypal payment)(www.fjrjtrade.com)
FOOTBALL SHOES
GUCCI SHOES
(http://www.fjrjtrade.com/category-935-b0-GUCCI-Shoes.html)
Men Gucci High
Men Gucci Low
Woman Gucci High
Woman Gucci Low
(http://www.fjrjtrade.com/category-935-b0-GUCCI-Shoes.html)
ICE GREAM
James
JORDAN
(http://www.fjrjtrade.com/category-919-b0-Nike-Jordan.html)
AF1 Jordan 1 Fusions
AF1 Jordan 12 Fusions
AF1 Jordan 20 Fusions
AF1 Jordan 23 Fusions (paypal payment)(www.fjrjtrade.com)
Air Jordan11 Jorda13 Fusions
Air Jordan 7 Jordan 8 Fusions
Air Jordan 9 Jordan 23 Fusions (paypal payment)(www.fjrjtrade.com)
jordan6 jordan1 fusions
Jordan LE DMP
Jordan NEW
(http://www.fjrjtrade.com/category-919-b0-Nike-Jordan.html)
JORDAN WOMEN
Man Nike Air Jordan 24
Women AF1 Jordan 5 Fusions
Women AF1 Jordan 12 Fusions (paypal payment)(www.fjrjtrade.com)
Women AF1 Jordan 23 Fusions
Women Jordan 3 Jordan5 Fusions
(http://www.fjrjtrade.com/category-919-b0-Nike-Jordan.html)
Kid shoes
KOBE
LACOSTE SHOES
Website:
http://www.fjrjtrade.com
==============================================================================
TOPIC: Printing the last item of a structure twice
http://groups.google.com/group/comp.lang.c++/t/9fd75392aae26667?hl=en
==============================================================================
== 1 of 2 ==
Date: Fri, Jul 31 2009 12:42 pm
From: Rafael Anschau
"Yes, but that's not actually what you want it to do. You want it to
write the _value_ of rua, and the int. But that's not what it's doing.
"
How come ? I can read the file after I quit and come back(I just need
to set open to a+ for instance) If the data is not there, then where
is it ?
Thanks,
Rafael
On Jul 30, 8:54 pm, Jonathan Lee <cho...@shaw.ca> wrote:
> On Jul 30, 6:11 pm, Rafael Anschau <rafael.ansc...@gmail.com> wrote:
>
> > The following program reads a structure into a file 3 times
>
> Yes, but that's not actually what you want it to do. You want it to
> write the _value_ of rua, and the int. But that's not what it's doing.
>
> If you check sizeof(string) you will find that it is always the same
> regardless of the contents. On my machine, that's 4 bytes, probably
> because it is only a wrapper around a pointer.
>
> So when you do this:
>
> fwrite(&meu, sizeof(ender), 1, fp);
>
> you are only writing a pointer ("rua") and the int ("n"). You're not
> writing the string that "rua" is pointing to.
>
> Depending on your inputs, that pointer stored by "rua" might not
> actually change. So you write out the same pointer 3 times. Then you
> read that same pointer back 3 times and they all point to the same
> thing: the last string you've read from the keyboard.
>
> You really need a way to serialize the object (hint: Google "serialize
> C++") and a way to recover it. Doing it the way you have is a bad idea
> -- as you've seen it doesn't work.
>
> --Jonathan
== 2 of 2 ==
Date: Fri, Jul 31 2009 2:42 pm
From: Jonathan Lee
On Jul 31, 3:42 pm, Rafael Anschau <rafael.ansc...@gmail.com> wrote:
> > "Yes, but that's not actually what you want it to do. You want it to
> > write the _value_ of rua, and the int. But that's not what it's doing.
> How come ? I can read the file after I quit and come back(I just need
> to set open to a+ for instance) If the data is not there, then where
> is it ?
First I recommend trying this: add the following line before
you write to the file:
cout << "Writing " << sizeof(ender) << " bytes" << endl;
It will print the same thing for every record, on my system that's
8 bytes. It's 8 bytes if I enter a 2 letter string for the street
name, and it's 8 bytes if I enter 40 letters for the street name.
When it's done, "1.tst" is always 24 bytes. So if I've entered
three 40 letter names, how could the data possibly be there?
Now to answer your question. What fwrite is doing is writing
the 8 bytes (sizeof(ender)) located at the address &meu. Of course,
this contains an ender structure, which is roughly
struct ender {
string rua;
int n;
}
Now rua, the string object, is just a pointer to a char* buffer
(a bit of a simplification, but good enough for this discussion).
So in reality you have this:
struct ender {
char* rua; // the only data a string object "contains"
int n;
}
And rua only contains a pointer to the actual string data. So
this is what you get when you write it out to the file.
As a concrete example, suppose I type in the street name as
"ReallyLongStreetName" and the number as 9. When you read the
value into rua, it will allocate a char* to hold the data and
store that address inside the string object. Let's say that
address is 0x40302010. Then 'meu' will hold
0x40302010 // string rua;
0x00000009 // int n;
When you write out the file you will get something like
0x40, 0x30, 0x20, 0x10, 0x00, 0x00, 0x00, 0x09
in 1st.tst, which has nothing to do with "ReallyLongStreetName"
When you read it back you get the same address back and it
just happens to contain the same string, leading you to
think that it's working, when it isn't.
What you need to do is serialize the object, as I said before.
One way to do this would be:
write the string length as a number
write the C-string value of rua, pointed to by rua.c_str()
write the street number
One final note: writing numbers is not portable. There is the
matter of "endianness", and also sizeof(int). But maybe convince
yourself of the above first...
--Jonathan
==============================================================================
TOPIC: dealing with lower level programmers
http://groups.google.com/group/comp.lang.c++/t/f708a2c0cfa8ce2d?hl=en
==============================================================================
== 1 of 2 ==
Date: Fri, Jul 31 2009 3:29 pm
From: Ian Collins
Noah Roberts wrote:
> James Kanze wrote:
>> Noah was very right about one thing: you have to
>> measure.
>
> Actually, what I said was that in order for something to be empirically
> based there must have been a measurement done.
>
> I don't agree with you that software "goodness" is something that can be
> measured. In fact, I can't think of any "goodness" that is possible to
> measure. Various things that various people think are "good", sure, but
> "goodness" is a subjective term that can't be empirically measured or
> applied.
>
> For example, you are using "goodness" to mean, "lack of errors." We can
> measure errors, somewhat, but since not everyone agrees with your use of
> the term "good" we haven't objectively measured "goodness". This is why
> when speaking empirically it is best to use objective terms like "lack
> of error" instead of "goodness". Then people know WTF you're talking
> about.
Could it be that we are looking at quality or "goodness" from different
perspectives?
My perspective is that of a business supplying a product (which happens
to be code) to a customer. From that perspective I don't really care
how many lines of code there are. I care about customer satisfaction
and my bottom line. Sure I strive for perfection, but that has to be
balanced with cost and delivery dates. "Good" code is code makes my
customers happy, generates follow up work and doesn't cost me time in
bug fixes (I don't charge for those).
My customers are happy and I haven't gone bust, so therefore I must be
producing good code!
--
Ian Collins
== 2 of 2 ==
Date: Fri, Jul 31 2009 10:09 pm
From: Gerhard Fiedler
Ian Collins wrote:
> My customers are happy and I haven't gone bust, so therefore I must be
> producing good code!
So you agree that Microsoft must be producing good code? Just
checking... :)
Gerhard
==============================================================================
TOPIC: ♡♪♡Wholesale Nokia ,Iphone, Samsung, Blackberry, Sony, Motorola,etc
brand mobiles "www.toptradea.com" ◆ Our policy: order 1-3pce brand mobile with
a free polo Tshirt, order more than 5 pcs brand mobiles with a free nike
sneaker (time limited)
http://groups.google.com/group/comp.lang.c++/t/fe3606d4b2851580?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Jul 31 2009 7:29 pm
From: "www.toptradea.com Toptradea"
♡♪♡Wholesale Iphone http://www.toptradea.com/category.php?id=435
Nokia http://www.toptradea.com/category.php?id=436
Blackberry http://www.toptradea.com/category.php?id=437
HTC http://www.toptradea.com/category.php?id=438
Samsung http://www.toptradea.com/category.php?id=440
Motorola http://www.toptradea.com/category.php?id=439,etc brand
mobiles "www.toptradea.com" ◆ Our policy: order 1-3pce brand mobile
with a free polo Tshirt, order more than 5 pcs brand mobiles with a
free nike sneaker (time limited)
Iphone http://www.toptradea.com/category.php?id=435
Nokia http://www.toptradea.com/category.php?id=436
Blackberry http://www.toptradea.com/category.php?id=437
HTC http://www.toptradea.com/category.php?id=438
Samsung http://www.toptradea.com/category.php?id=440
Motorola http://www.toptradea.com/category.php?id=439
==============================================================================
TOPIC: ◎♥◎Wholesale Tshirt and Jeans BBC,Evis,POLO,Lacoste,Affliction ,Gucci,
Edhardy,Armani,LV,Christina Audigier ◎www.toptradea.com◎
http://groups.google.com/group/comp.lang.c++/t/ae9996302e270d55?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Jul 31 2009 7:31 pm
From: "www.toptradea.com Toptradea"
◎♥◎Wholesale Tshirt and Jeans
BBC,Evis,POLO,Lacoste,Affliction ,Gucci,Edhardy,Armani,LV,Christina
Audigier ◎www.toptradea.com◎
T-shirt: Bape http://www.toptradea.com/category.php?id=282,
Christina Audigier http://www.toptradea.com/category.php?id=285
,
D&G http://www.toptradea.com/category.php?id=290 ,
Ed hardy http://www.toptradea.com/category.php?id=292 ,
BBC http://www.toptradea.com/category.php?id=405 ,
Burberry http://www.toptradea.com/category.php?id=407 ,
G-star http://www.toptradea.com/category.php?id=408 ,
Gucci http://www.toptradea.com/category.php?id=411 ,
Lacoste http://www.toptradea.com/category.php?id=417 ,
Polo http://www.toptradea.com/category.php?id=423 ,
LV http://www.toptradea.com/category.php?id=422 ,
Smet http://www.toptradea.com/category.php?id=430 ,
Affliction http://www.toptradea.com/category.php?id=174 ,
Armani http://www.toptradea.com/category.php?id=180
Jeans: Evisu http://www.toptradea.com/category.php?id=363 ,
Gucci http://www.toptradea.com/category.php?id=365 ,
G-star http://www.toptradea.com/category.php?id=364 ,
LV http://www.toptradea.com/category.php?id=382 ,
D&G http://www.toptradea.com/category.php?id=192 ,
Ed hardy http://www.toptradea.com/category.php?id=186 ,
Iceberg http://www.toptradea.com/category.php?id=379 ,
BBC http://www.toptradea.com/category.php?id=191 ,
RMC http://www.toptradea.com/category.php?id=369 ,
Coogi http://www.toptradea.com/category.php?id=380,
Prada http://www.toptradea.com/category.php?id=193
==============================================================================
TOPIC: ☆*-*☆Handbags supplier ¤www.toptradea.com¤ Lady Handbags Juicy,Gucci,LV,
Prada,D&G,Edhardy,Chanel,Coach, Jimmy-Hoo,Burberry,DB ┈━♥◎♥→
http://groups.google.com/group/comp.lang.c++/t/94fa848366c7d863?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Jul 31 2009 7:35 pm
From: "www.toptradea.com Toptradea"
☆*-*☆Handbags supplier ¤www.toptradea.com¤ Lady Handbags
Juicy,Gucci,LV,Prada,D&G,Edhardy,Chanel,Coach, Jimmy-Hoo,Burberry,DB
┈━♥◎♥→
Handbags http://www.toptradea.com/category.php?id=66
Prada Handbags http://www.toptradea.com/category.php?id=395
LV Handbags http://www.toptradea.com/category.php?id=394
Juicy Handbags http://www.toptradea.com/category.php?id=393
Jordan Handbags http://www.toptradea.com/category.php?id=392
Jimmy Hoo Handbags http://www.toptradea.com/category.php?id=391
Ed hardy Handbags http://www.toptradea.com/category.php?id=390
Fendi Handbags http://www.toptradea.com/category.php?id=389
DB Handbags http://www.toptradea.com/category.php?id=388
Coach Handbags http://www.toptradea.com/category.php?id=387
Chloe Handbags http://www.toptradea.com/category.php?id=386
Burberrys Handbags http://www.toptradea.com/category.php?id=385
Gucci Handbags http://www.toptradea.com/category.php?id=183
Chanel Handbags http://www.toptradea.com/category.php?id=185
D&G Handbags http://www.toptradea.com/category.php?id=184
Brand-Luggages http://www.toptradea.com/category.php?id=384
==============================================================================
TOPIC: ☆◆☆Wholesale Nokia N series N97,N96,N86,N81,N85,N78,N79,N72,5800,8800,
8600,6500,6300,5800 ♪ ♪ ♪ Our policy: order 1-3pce brand mobile with a free
polo Tshirt, order more than 5 pcs brand mobiles with a free nike sneaker (
time limited)♪♪♪
http://groups.google.com/group/comp.lang.c++/t/8912ce8c161014b7?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Jul 31 2009 7:39 pm
From: "www.toptradea.com Toptradea"
☆◆☆Wholesale Nokia http://www.toptradea.com/category.php?id=436 N
series N97 http://www.toptradea.com/category.php?id=436 ,N96
http://www.toptradea.com/category.php?id=436 ,N86
http://www.toptradea.com/category.php?id=436 ,N81
http://www.toptradea.com/category.php?id=436 ,N85
http://www.toptradea.com/category.php?id=436 ,N78
http://www.toptradea.com/category.php?id=436 ,N79
http://www.toptradea.com/category.php?id=436 ,N72
http://www.toptradea.com/category.php?id=436 ,5800
http://www.toptradea.com/category.php?id=436 ,8800
http://www.toptradea.com/category.php?id=436 ,8600
http://www.toptradea.com/category.php?id=436 ,6500
http://www.toptradea.com/category.php?id=436 ,6300
http://www.toptradea.com/category.php?id=436 ,5800
http://www.toptradea.com/category.php?id=436 ♪ ♪ ♪ Our policy: order
1-3pce brand mobile with a free polo Tshirt, order more than 5 pcs
brand mobiles with a free nike sneaker (time limited)♪♪♪
==============================================================================
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
