comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=encomp.lang.c++@googlegroups.com
Today's topics:
* C++ build systems - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/a9c4e538f1e6792e?hl=en
* Emulating 'swizzling' in C++ - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/5fc8c96b1dfd125c?hl=en
* using local static variable inside a function - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/7d53e8ea36d0502c?hl=en
* Create a permutation list - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/d6a888bf1cdb5a51?hl=en
* ... so why do I have to give the class name when getting the address of a
member function? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/508511fb6f1975b3?hl=en
* Why doesn't the default argument allow const member? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/5b4659040c4a93de?hl=en
* about new and delete - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/85fc26a34c7b73d3?hl=en
* Any surveys about the premature optimization status nowadays? - 4 messages,
4 authors
http://groups.google.com/group/comp.lang.c++/t/dae885f4f1cdfad5?hl=en
* How to get file count under a directory? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/85c9fe56a4fecd6f?hl=en
* Cheap Ed hardy,Polo,BBC,Gucci,Armani,LV,Christina Audigier hardy clothing on
www.ebaychinaonline.com paypal payment - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/ea2375c5d515e396?hl=en
* ★№1★wholesale Blackberry,Iphone,Nokia,Samsung,Vertu,etc brand new mobile
phones★№1★ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/de0ceb7f7d7cfc6e?hl=en
* WHOLESALE……◆Perfect quality! Nike shox, rift,Jordan, Gucci, Puma, D&G, LV,
Chanel, Bape, Ed hardy, Lacoste sneakers◆ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/0419ad8f240e155c?hl=en
* ๑◎๑Wholesale Jacket Christina Audigier,G-star,Gucci,Lacost,Adidas,Bape,BBC,
Burberry, Jackets NO.1 Quality๑◎๑ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/15b34030604e2b04?hl=en
* Pass a pointer variable to a function accept reference - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/330170d81fae3d1c?hl=en
==============================================================================
TOPIC: C++ build systems
http://groups.google.com/group/comp.lang.c++/t/a9c4e538f1e6792e?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Sep 30 2009 12:21 pm
From: Jorgen Grahn
On Tue, 2009-09-29, Joe Smith wrote:
...
> There are only two types of systems for identifying if a file is out of
> date. Timestamp based systems are one. Content based systems are annother.
> With content based systems, the build system maintains a copy of the source
> file, and dependencies (headers) that resulted in the current output file.
> The system rebuilds the source only if the current file's contents are
> different from the stored copy.
Unless you count the one ClearCase and its clearmake utility uses:
It keeps track of the /versions/ of all things involved in creating
the target. If someone, at some time, ran "cc -c foo.c" with "cc",
"foo.c" and "foobar.h" at the same revision level that you have now,
don't run the compiler, just "wink in" (to use their term) the foo.o
which was generated last time.
IIRC, that breaks horribly if clearmake doesn't know of all foo.o's
dependencies, which means you have to be pretty darn sure your
Makefile is correct at all times. On the other hand, you can go from a
clean build directory to a ready build without running the compiler or
linker a single time!
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
==============================================================================
TOPIC: Emulating 'swizzling' in C++
http://groups.google.com/group/comp.lang.c++/t/5fc8c96b1dfd125c?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Sep 30 2009 12:25 pm
From: Jorgen Grahn
On Fri, 2009-09-18, Alan Woodland wrote:
> Hi,
>
> A number of 'C-style' languages define a 'swizzle' operator which allows
> the permutation of the elements of vector datatypes. This is typically
> done with an extra meaning to the . operator.
Which languages are that? Not even Perl has a operator called
'swizzle' (unless it's new in Perl 6).
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 2 of 2 ==
Date: Wed, Sep 30 2009 2:17 pm
From: legalize+jeeves@mail.xmission.com (Richard)
[Please do not mail me a copy of your followup]
Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
<slrnhc7c4l.o8a.grahn+nntp@frailea.sa.invalid> thusly:
>On Fri, 2009-09-18, Alan Woodland wrote:
>> A number of 'C-style' languages define a 'swizzle' operator which allows
>> the permutation of the elements of vector datatypes. This is typically
>> done with an extra meaning to the . operator.
>
>Which languages are that? Not even Perl has a operator called
>'swizzle' (unless it's new in Perl 6).
It comes from GPU shader languages where the registers are 4-component
vectors and variables declared as vectors can arbitrarily multiplex
(and replicate) the components of the vectors to product new vectors.
This happens quickly and directly in the hardware and so is supported
as an intrinsic on the vector types.
Look up Cg, GLSL and HLSL on Wikipedia for more info.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
==============================================================================
TOPIC: using local static variable inside a function
http://groups.google.com/group/comp.lang.c++/t/7d53e8ea36d0502c?hl=en
==============================================================================
== 1 of 3 ==
Date: Wed, Sep 30 2009 12:29 pm
From: Pete Becker
SG wrote:
> On 30 Sep., 16:25, Pete Becker wrote:
>> AnonMail2...@gmail.com wrote:
>>
>>> Static variable inside a function have compiler generated code that
>>> makes sure the object is only constructed and initialized once. Since
>>> standard C++ knows nothing about threads, the mechanism used to ensure
>>> this is not thread safe.
>> Sorry, but that's a copout. If a compiler supports multiple threads,
>> then it should provide a thread-safe mechanism for initializing
>> function-static data objects. If it doesn't, don't blame the standard.
>> Blame the compiler.
>
> If it doesn't it might still be a standards compliant compiler. I
> think this was AnonMail's point.
>
Yes, of course it was. But the claim was:
Since standard C++ knows nothing about threads,
the mechanism used to ensure this is not thread safe.
The conclusion doesn't follow from the premise. The C++ standard does
not require that the initialization mechanism for function-static data
object not be thread safe.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)
== 2 of 3 ==
Date: Wed, Sep 30 2009 2:21 pm
From: Paul N
On 30 Sep, 13:23, "subramanian10...@yahoo.com, India"
<subramanian10...@yahoo.com> wrote:
> Is it advisable to use a local static variable inside a function ? I
> want to know whether there are any drawbacks of using local static
> variable inside a function.
You can get nasty results if you forget what you're doing. For
instance, suppose you have a function that returns a string - say, the
date, or time, or a formatted version of several inputs. To save
allocating, you have a static array of char in the function. Things
can go wrong if you call the function twice without copying the
result. For example:
char *formatted_time(void) {
static char buff[20];
// load up buff with, eg, "22:16"
return buff;
}
...
char *before, *after;
before = formatted_time();
// do stuff
after = formatted_time();
if (strcmp(before, after) == 0) printf("Why did it take no time?");
The problem here is that before and after are both pointers into the
same buffer so have the same values and the same contents.
Hope that helps.
Paul.
== 3 of 3 ==
Date: Wed, Sep 30 2009 3:42 pm
From: Pete Becker
Paul N wrote:
> On 30 Sep, 13:23, "subramanian10...@yahoo.com, India"
> <subramanian10...@yahoo.com> wrote:
>> Is it advisable to use a local static variable inside a function ? I
>> want to know whether there are any drawbacks of using local static
>> variable inside a function.
>
> You can get nasty results if you forget what you're doing. For
> instance, suppose you have a function that returns a string - say, the
> date, or time, or a formatted version of several inputs. To save
> allocating, you have a static array of char in the function. Things
> can go wrong if you call the function twice without copying the
> result. For example:
>
> char *formatted_time(void) {
> static char buff[20];
> // load up buff with, eg, "22:16"
> return buff;
> }
>
> ...
> char *before, *after;
>
> before = formatted_time();
> // do stuff
> after = formatted_time();
> if (strcmp(before, after) == 0) printf("Why did it take no time?");
>
> The problem here is that before and after are both pointers into the
> same buffer so have the same values and the same contents.
>
Note, however, that this is true for all static variables, not just
function-static variables.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)
==============================================================================
TOPIC: Create a permutation list
http://groups.google.com/group/comp.lang.c++/t/d6a888bf1cdb5a51?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Sep 30 2009 12:29 pm
From: Jerry Coffin
In article <6273cccb-0511-4cb5-acff-
f188e37b66fa@l9g2000yqi.googlegroups.com>, markredd85@gmail.com
says...
>
> Hello world,
> I'm looking for an algorithm in order to perform this operation: I
> have a set of N possible values and I want to generate all the
> possibile permutations composed by M slots without repetitions and not
> considering the order.
>
> Note: I don't know what are the values of N and M befor the software
> starts, so i have to implement it at run-time.
>
> For example, if N=4 with values {1 , 2 , 3 , 4} and M=3, I will obtain
> only 4 combinations, for example:
> (1,2,3) [or (3,2,1), or (2,1,3), the order doesn't matter]
> (1,3,4)
> (1,2,4)
> (2,3,4)
>
> Can you describe an algorithm? (I don't need code, I hope I will able
> to develop it!)
From a C++ viewpoint, the proper answer would probably be
std::next_permutation (and possibly std::prev_permutation).
--
Later,
Jerry.
== 2 of 2 ==
Date: Wed, Sep 30 2009 1:08 pm
From: Kai-Uwe Bux
Jerry Coffin wrote:
> In article <6273cccb-0511-4cb5-acff-
> f188e37b66fa@l9g2000yqi.googlegroups.com>, markredd85@gmail.com
> says...
>>
>> Hello world,
>> I'm looking for an algorithm in order to perform this operation: I
>> have a set of N possible values and I want to generate all the
>> possibile permutations composed by M slots without repetitions and not
>> considering the order.
>>
>> Note: I don't know what are the values of N and M befor the software
>> starts, so i have to implement it at run-time.
>>
>> For example, if N=4 with values {1 , 2 , 3 , 4} and M=3, I will obtain
>> only 4 combinations, for example:
>> (1,2,3) [or (3,2,1), or (2,1,3), the order doesn't matter]
>> (1,3,4)
>> (1,2,4)
>> (2,3,4)
>>
>> Can you describe an algorithm? (I don't need code, I hope I will able
>> to develop it!)
>
> From a C++ viewpoint, the proper answer would probably be
> std::next_permutation (and possibly std::prev_permutation).
I guess, there is a confusion caused by the OP's use of "permutation" in the
subject line. The example of the post, however, makes is pretty clear that
the OP really wants to iterate through the list of M-element subsets of an
N-element set. He even points out that order does not matter.
Hint to the OP: think of the numbers 0, 1, 2, ..., 2^N - 1. These are
exactly the numbers that can be encoded by N bits, i.e., they correspond to
subsets of an N-element set (the 1-bits indicate the chosen elements). You
could now create a next_M_subset() function by answering the following
question:
Given a number k in [0,2^N) that has M set bits, what is the
next number that has M bits set?
E.g.: N = 5, M = 3 would yield the following order:
00111
01011
01110
10011
10101
10110
11001
11010
11100
Also note that comp.programming is better suited for language independent
questions.
Best
Kai-Uwe Bux
==============================================================================
TOPIC: ... so why do I have to give the class name when getting the address of
a member function?
http://groups.google.com/group/comp.lang.c++/t/508511fb6f1975b3?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Sep 30 2009 1:17 pm
From: Andy Champ
So to steal a couple of lines from the FAQ, I have
typedef int (Fred::*FredMemFn)(char x, float y);
FredMemFn a[] = { &Fred::f, &Fred::g, &Fred::h, &Fred::i };
If this is inside another member function of Fred, why do I have to give
the class name? After all, if I wanted to _call_ f(char, float) it
would happily work it out.
Just curious... (had to code up some calls passing member functions
today, which is not something I do a lot)
Andy
== 2 of 2 ==
Date: Wed, Sep 30 2009 1:51 pm
From: Victor Bazarov
Andy Champ wrote:
> So to steal a couple of lines from the FAQ, I have
>
> typedef int (Fred::*FredMemFn)(char x, float y);
> FredMemFn a[] = { &Fred::f, &Fred::g, &Fred::h, &Fred::i };
>
> If this is inside another member function of Fred, why do I have to give
> the class name? After all, if I wanted to _call_ f(char, float) it
> would happily work it out.
>
> Just curious... (had to code up some calls passing member functions
> today, which is not something I do a lot)
The boilerplate answer is, "Because the Standard says so in
[expr.unary.op]/2." Not often is it satisfactory, however...
I think that's just how the name lookup works. So, your question is
really, "why does name lookup for pointers-to-member requires the fully
qualified name (member name with name of the class and colons)?" My
guess is to limit the looked-up scope, and thus probably simplify the
process. But I don't know squat about writing that part of the compiler.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
==============================================================================
TOPIC: Why doesn't the default argument allow const member?
http://groups.google.com/group/comp.lang.c++/t/5b4659040c4a93de?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Sep 30 2009 2:28 pm
From: Daniel Pitts
Francesco S. Carta wrote:
> Right, thanks, but that has already been pointed out and acknowledged.
>
> Follow the threads thoroughly please.
Not every message is sent and received instantly. It was not
pointed-out and acknowledge in my view.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
== 2 of 2 ==
Date: Wed, Sep 30 2009 2:56 pm
From: "Francesco S. Carta"
On 30 Set, 23:28, Daniel Pitts
<newsgroup.spamfil...@virtualinfinity.net> wrote:
> Francesco S. Carta wrote:
> > Right, thanks, but that has already been pointed out and acknowledged.
>
> > Follow the threads thoroughly please.
>
> Not every message is sent and received instantly. It was not
> pointed-out and acknowledge in my view.
Fine, please accept my apologies.
Taking in account that both of my posts (the one you were replying to
and the one where I acknowledged the better workaround) have been
posted circa one week ago from the same identical newsreader
(GoogleGroups), coming to know that you received the latter with a one-
week delay seems a bit odd to me.
But these are just lucubrations of mine and I must trust your word.
My apologies, once again.
Have good time,
Francesco
--
Francesco S. Carta, hobbyist
http://fscode.altervista.org
==============================================================================
TOPIC: about new and delete
http://groups.google.com/group/comp.lang.c++/t/85fc26a34c7b73d3?hl=en
==============================================================================
== 1 of 3 ==
Date: Wed, Sep 30 2009 3:16 pm
From: Juha Nieminen
Sam wrote:
> Very interesting. So a situation where one needs all existing iterators
> to remain valid, after an element gets added to the container, are
> "imaginary", and will never happen in practice. Gee, why would you
> *possibly* want something like that?
>
> Well, that's a comforting thought.
Exactly as imaginary as someone needing 10 thousand elements or random
access in constant time.
You seem to be very eager to dismiss features as "theoretical" when it
best suits your argument.
== 2 of 3 ==
Date: Wed, Sep 30 2009 4:02 pm
From: Juha Nieminen
Sam wrote:
>>> std::list<obj> theList;
>>>
>>> // …
>>>
>>> std::list<obj>::iterator p;
>>>
>>> // …
>>>
>>> theList.erase(p); // Warning, O(n)!!!!!
>>>
>>> Very funny.
>>
>> That's not O(n) or O(1).
>
> Not according to you, it is.
No. According to me it's undefined behavior.
>
>> That's Undefined Behavior because you haven't
>> initialized p to anything.
>
> Free honking clue: the "// …" parts specifies bits of code left out of
> the example, for brevity.
"For brevity" is an excuse for "I can't give you actual code which you
can compile and which would demonstrate removal in constant time".
>> You conveniently left out the initialization of p. Please show me how
>> you initialize p to point to the exact middle of theList.
>
> Well, just for shits and giggles:
>
> theList.push_front(obj());
>
> p=theList.front();
>
> // … (for a smaller value of …)
>
> theList.erase(p); // Warning, O(n), according to Juha!!!!!
>
> Happy now?
p doesn't point to the middle of the container. You claimed that an
element can be removed from the middle in O(1). Your code doesn't
demonstrate that.
If you are now changing your argument to "you can remove from the
beginning in O(1)" then your whole dismissal of std::deque crumbles
because you can remove from the beginning of a std::deque in O(1) as well.
You won't give an actual example of removing from the *middle* of a
std::list in O(1) because it's not possible. You have to get to the
middle somehow, you can't get the iterator pointing there by magic. You
have to obtain it somehow, and that somehow is an O(n) operation.
That's why you refuse to give me the function which takes a std::list
and removes the middle element. Because IT'S NOT POSSIBLE to do that in
O(1), and your whole argument would crumble.
>>> What you fail to grok, is that when you have a member of containe that
>>> you want removed, you already have its iterator, you don't need to
>>> search for it.
>>
>> What do you mean I already have its iterator? No I don't.
>
> That's why nobody will let you write production code :-)
You are still refusing to show me the function which removes the
middle element in a std::list in constant time.
Remember, that's *exactly* what you claimed: That you can remove an
element from the middle of a std::list in constant time. Well, prove it.
How hard can it be? Just give me the function which will do exactly that.
But of course you won't do it, because IT'S NOT POSSIBLE.
>> Please show me how you get that iterator. You claim that removing an
>> object from the middle of a list is O(1). Prove it to me. You are so
>> smart that it shouldn't be a problem to you.
>
> I'm very smart. If I add objects to a list, that I know that I'll want
> to remove later, I'll save their iterator, someplace, so when I need to
> remove it, I won't need to search for it.
By doing that you are just hiding the O(n) behavior inside the list
initialization. Your removal didn't become O(1). You simply moved part
of the removal routine from one place to another to try to hide the fact.
> That's why they pay me the big bucks, Grasshopper.
They pay you big bucks even though you didn't even realize that
std::deque beats your beloved std::list hands down in speed. Then you
come here with a proud tone of voice to announce how std::list is the
best solution to the original problem because it's the fastest solution.
>>> You're just grasping at straws here, desperately trying to create a
>>> contrived situation that fits your preconceived notions.
>>
>> I don't think it's very contrived: Write a C++ function which takes a
>> std::list as (a reference) parameter, and removes the element in the
>> exact middle of the list.
>
> I'll write it as soon as I lose the ability to write entire applications
> correctly.
You will never write it because IT'S NOT POSSIBLE. A function which
does that in O(1) cannot exist. You cannot magically get an iterator to
the middle element of a std::list in O(1). Hence you cannot remove the
middle element in O(1).
>>> This is
>>> something that will often occur inside ivory halls of academia, where
>>> brownie points are awarded for completing a purely theoretical excersize
>>> that bears no relevance to anything that will occur in practice.
>>
>> Yes, in practice you will never need to, for example, pick elements
>> from a container in random order, without repetitions (and of course as
>> fast as possible).
>
> Of course you do.
You don't even seem to understand sarcasm. And by misunderstanding my
sarcasm you disproved your own claim that removing an element from a
std::vector in O(1) without preserving the ordering would only be
theoretical rather than a useful technique in practice.
>>>> See? Look who is changing the topic.
>>>
>>> The individual who first brought up dequeue. Hint: it wasn't me.
>>
>> I find it hilarious that when std::deque beats your beloved std::list
>> in all possible ways, you try to shrug it off with some ridiculous
>> meta-argument about changing topics.
>
> Your sense of humor is a bit bizarre, then. You've just shrugging off me
> pointing out that it was you who changed the topic by bringing up deque
> in the first place, yet you don't find /that/ funny. How come?
Yes, try to shrug the whole embarrassing std::deque beating your
std::list in speed (which was your *original* argument in this thread)
by keeping that ridiculous "don't change the topic" argument.
It was you who said that std::list is a "win" in the original
situation. I proved you that it isn't because there's an even more
efficient data container than std::list, namely std::deque. Now you are
so embarrassed to admit that it indeed is so, that you just keep with
your "don't change the topic" argument.
>>> "fastest" != "always fastest". Elementary, my dear Watson, elementary.
>>
>> Pushing back into a std::deque is, as far as I can see, *always*
>> faster than pushing back into a std::list. Please show me otherwise.
>
> "As far as I can see" is a revealing hint that you are not necessarily
> convinced of that yourself. Your homework assignment (since you're so
> fond of them), is to find the cases when it's not.
Unlike you, I actually measured it and posted some code and results.
You never disproved those results, nor presented any argument whatsoever
why std::list would be faster than std::deque in *any* situation. It's
all there. You can test it yourself.
Then you accuse me of theoretical stuff.
I really find it hilarious how you are unable to disprove the results,
yet are too proud to admit anything, to give any concession. You are too
proud to say "yes, I was wrong, std::deque is indeed much faster than
std::list, making it a better choice for the original poster".
Instead, you keep repeating your "insert in the middle" and "don't
change topics" arguments.
>> Then please give me the function which removes the element in the
>> exact middle of a std::list in constant time. Show me some *practical*
>> code, rather than relying on *theoretical* claims.
>
> You know perfectly well how you've been nailed to the wall on this one.
> Removing elements from a list is O(1), and flapping your arms and
> throwing a bunch of extra conditions and requirements is not going to
> change the basic, underlying fact.
Well, if removing elements from a list is O(1), then give me a
function which removes the middle element of a list in O(1).
You won't give me the function because you *can't* give me the
function. No matter how many times you repeat "you can remove the middle
element in O(1)", that doesn't make it true. If it's true, surely you
can show me some actual code doing so. You won't because you can't.
You accuse me of imposing some requirements. Well, do you really think
that removing an element from a list in O(1) has no requirements? If you
think hard, you'll see what this special requirement is. It's pretty
simple. When you say "you can remove an element in O(1)" you are
blissfully ignoring this small requirement.
>> When you say "removing *from the middle* can be done in constant time"
>> you are conveniently skipping the part where you have to actually get an
>> actual iterator pointing to the middle. You are only focusing on the
>
> And you are conveniently ignoging the part where you don't need to "get"
> an iterator, since you've already "got" it, when you added the object to
> the list in the first place.
"flapping your arms and throwing a bunch of extra conditions and
requirements is not going to change the basic, underlying fact."
It's funny how you accuse me of imposing extra requirements, while you
are doing the exact same thing.
Besides, by putting the retrieval of the middle element inside the
initialization of the list you are not changing the O() complexity in
any way. You are simply trying to disguise it. Getting the iterator is
still O(n). You are still doing it inside a loop which is traversing the
list.
Even I can think of better ways of getting an iterator pointing to the
middle of a list.
> I think that the disconnect here is that you're not really familiar with
> std::list, you've rarely used it, so you are ignorant of how to properly
> use this container in practice.
Haha. For your information, I have implemented a data container which
is (almost) completely equivalent to std::list, but uses a slightly
different technique (namely, it's a xor list). I have a pretty good idea
how std::list works. (The advantage of a xor list is that each node
consumes less memory, especially when used with a space-efficient memory
allocator. The disadvantage is that modifying the list using an iterator
also invalidates any iterator which might be pointing to the next
element (or previous, depending on how you implement it).)
Implementing your own STL-style data container (such as a linked list)
is actually pretty didactic. You get to understand quite a lot about the
design of the standard library.
For example, while trying to implement the container, you will
invariably encounter this problem: You will need to have these two
constructors:
YourList::YourList(size_type n, const value_type& value);
template<typename InputIterator>
YourList::YourList(InputIterator b, InputIterator e);
Why is that a problem? Because if you do this:
YourList<int> l(10, 20);
you will see that the compiler actually calls the constructor taking two
input iterators (because it's a better match), not the constructor
taking the integrals. Yet, somehow, the STL data containers still manage
to do the right thing, even though the wrong constructor is being
called. If you want to make your own data container fully compatible
with STL containers, you'll have to solve that problem yourself as well.
Another interesting problem is this: A std::list takes an allocator as
template parameter (and an instance of such allocator as constructor
parameter). However, the allocator specified as template parameter is
configured to allocate objects of type value_type, not objects of the
internal node type. But std::list needs to allocate interal nodes (which
is usually a struct), not objects of type value_type. How is this
problem solved with allocators?
And yet another interesting question: If you have two lists, A and B,
and you have an iterator pointing to A.end(), and then you perform a
"A.swap(B);", where will the iterator end up pointing? To the end of A
or to the end of B?
I do know a fair bit about std::list. Your move.
== 3 of 3 ==
Date: Wed, Sep 30 2009 5:50 pm
From: Sam
Juha Nieminen writes:
> Sam wrote:
>>>> std::list<obj> theList;
>>>>
>>>> // …
>>>>
>>>> std::list<obj>::iterator p;
>>>>
>>>> // …
>>>>
>>>> theList.erase(p); // Warning, O(n)!!!!!
>>>>
>>>> Very funny.
>>>
>>> That's not O(n) or O(1).
>>
>> Not according to you, it is.
>
> No. According to me it's undefined behavior.
Fortunately, you do not get to define C++.
>>
>>> That's Undefined Behavior because you haven't
>>> initialized p to anything.
>>
>> Free honking clue: the "// …" parts specifies bits of code left out of
>> the example, for brevity.
>
> "For brevity" is an excuse for "I can't give you actual code which you
> can compile and which would demonstrate removal in constant time".
The "theList.erase(p);" part compiles just fine for me.
>
>>> You conveniently left out the initialization of p. Please show me how
>>> you initialize p to point to the exact middle of theList.
>>
>> Well, just for shits and giggles:
>>
>> theList.push_front(obj());
>>
>> p=theList.front();
>>
>> // … (for a smaller value of …)
>>
>> theList.erase(p); // Warning, O(n), according to Juha!!!!!
>>
>> Happy now?
>
> p doesn't point to the middle of the container.
Yes, it does.
> You claimed that an
> element can be removed from the middle in O(1). Your code doesn't
> demonstrate that.
std::list<T>::erase is O(1), as defined in the C++ standard. Facts disagree
with you.
> If you are now changing your argument to "you can remove from the
> beginning in O(1)" then your whole dismissal of std::deque crumbles
> because you can remove from the beginning of a std::deque in O(1) as well.
I am not changing anything. Whether the iterator points to the beginning,
the end, or somewhere else in the container, std::list<T>::erase is O(1).
The same cannot be said for std::vector<T>::erase, unfortunately.
> You won't give an actual example of removing from the *middle* of a
> std::list in O(1) because it's not possible.
Just because it's not possible for you, does not mean that it's not possible
at all.
> You have to get to the
> middle somehow, you can't get the iterator pointing there by magic. You
> have to obtain it somehow, and that somehow is an O(n) operation.
For you, it's a "somehow". For others, it's a "known process".
> That's why you refuse to give me the function which takes a std::list
> and removes the middle element.
I gave you this function many times: std::list<T>::erase. Look it up.
> Because IT'S NOT POSSIBLE to do that in
> O(1), and your whole argument would crumble.
Maybe for you it's impossible, but, you're just special in that regard.
>>>> What you fail to grok, is that when you have a member of containe that
>>>> you want removed, you already have its iterator, you don't need to
>>>> search for it.
>>>
>>> What do you mean I already have its iterator? No I don't.
>>
>> That's why nobody will let you write production code :-)
>
> You are still refusing to show me the function which removes the
> middle element in a std::list in constant time.
I've already shown in to you many times. It's right in front of you, you're
just refusing to see it.
> Remember, that's *exactly* what you claimed: That you can remove an
> element from the middle of a std::list in constant time.
Right.
> Well, prove it.
theList.erase(p), FTW.
> How hard can it be? Just give me the function which will do exactly that.
It's still std::list<T>::erase. It always was std::list<T>::erase. It will
always be std::list<T>::erase.
> But of course you won't do it, because IT'S NOT POSSIBLE.
It's been very much possible, for quite a while now.
>
>>> Please show me how you get that iterator. You claim that removing an
>>> object from the middle of a list is O(1). Prove it to me. You are so
>>> smart that it shouldn't be a problem to you.
>>
>> I'm very smart. If I add objects to a list, that I know that I'll want
>> to remove later, I'll save their iterator, someplace, so when I need to
>> remove it, I won't need to search for it.
>
> By doing that you are just hiding the O(n) behavior inside the list
> initialization.
You are confused: std::list<T>::push_front is O(1), not O(n).
> Your removal didn't become O(1).
Of course it didn't become O(1), it was O(1) right from the start.
> You simply moved part
> of the removal routine from one place to another to try to hide the fact.
I didn't move the call to erase() anywhere, it was always where it was.
>> That's why they pay me the big bucks, Grasshopper.
>
> They pay you big bucks even though you didn't even realize that
> std::deque beats your beloved std::list hands down in speed.
No, it doesn't.
>>> I don't think it's very contrived: Write a C++ function which takes a
>>> std::list as (a reference) parameter, and removes the element in the
>>> exact middle of the list.
>>
>> I'll write it as soon as I lose the ability to write entire applications
>> correctly.
>
> You will never write it because IT'S NOT POSSIBLE. A function which
It's not merely possible, my friend, it's very easy. All that's necessary is
a good, thorough understanding of the STL, and the right container to use in
each situation.
> does that in O(1) cannot exist. You cannot magically get an iterator to
> the middle element of a std::list in O(1). Hence you cannot remove the
> middle element in O(1).
I do the impossible every day. And damn proud of it.
>>> I find it hilarious that when std::deque beats your beloved std::list
>>> in all possible ways, you try to shrug it off with some ridiculous
>>> meta-argument about changing topics.
>>
>> Your sense of humor is a bit bizarre, then. You've just shrugging off me
>> pointing out that it was you who changed the topic by bringing up deque
>> in the first place, yet you don't find /that/ funny. How come?
>
> Yes, try to shrug the whole embarrassing std::deque beating your
> std::list in speed (which was your *original* argument in this thread)
No, my confused friend. I did not bring up any such argument. You were the
one that started yammering on something about std::deque, not me.
> It was you who said that std::list is a "win" in the original
> situation.
And, it was.
> I proved you that it isn't because there's an even more
> efficient data container than std::list, namely std::deque.
No, you didn't.
>>>> "fastest" != "always fastest". Elementary, my dear Watson, elementary.
>>>
>>> Pushing back into a std::deque is, as far as I can see, *always*
>>> faster than pushing back into a std::list. Please show me otherwise.
>>
>> "As far as I can see" is a revealing hint that you are not necessarily
>> convinced of that yourself. Your homework assignment (since you're so
>> fond of them), is to find the cases when it's not.
>
> Unlike you, I actually measured it and posted some code and results.
So did I.
> You never disproved those results, nor presented any argument whatsoever
Your results were irrelevant as far as the original topic was concerned.
There was nothing to disprove.
> Instead, you keep repeating your "insert in the middle" and "don't
> change topics" arguments.
That's because it's always better to have some facts, at one's disposal,
that's all.
>> You know perfectly well how you've been nailed to the wall on this one.
>> Removing elements from a list is O(1), and flapping your arms and
>> throwing a bunch of extra conditions and requirements is not going to
>> change the basic, underlying fact.
>
> Well, if removing elements from a list is O(1), then give me a
> function which removes the middle element of a list in O(1).
I keep giving it to you: std::list<T>::erase. You are merely in denial.
Denying the existing of this method won't make it go away.
> You accuse me of imposing some requirements. Well, do you really think
> that removing an element from a list in O(1) has no requirements? If you
It has the same requirements that all other containers have, of course. It
goes without saying that the container must exist, the iterator for the
element to remove must be valid, etc…
> think hard, you'll see what this special requirement is.
There's nothing special about a list iterator; not any more special than
about a vector iterator.
>>> When you say "removing *from the middle* can be done in constant time"
>>> you are conveniently skipping the part where you have to actually get an
>>> actual iterator pointing to the middle. You are only focusing on the
>>
>> And you are conveniently ignoging the part where you don't need to "get"
>> an iterator, since you've already "got" it, when you added the object to
>> the list in the first place.
>
> "flapping your arms and throwing a bunch of extra conditions and
> requirements is not going to change the basic, underlying fact."
It's not a requirement, my confused friend. You automatically get the
iterator when you insert an element into the list. You don't have to require
or demand its creation, somehow.
> Besides, by putting the retrieval of the middle element inside the
> initialization of the list you are not changing the O() complexity in
> any way. You are simply trying to disguise it.
Facts maybe "disguised" or hidden from you, somehow, but that's just due
to your inexperience with STL containers and iterators.
> Getting the iterator is
> still O(n).
Not std::list<T>::begin() in my version of the STL.
> You are still doing it inside a loop which is traversing the
> list.
I'm not traversing the list, my confused friend. After a push_front(), the
iterator for my element is obtained by begin(), and, unlike with
std::vector, when additional elements are added to the std::list, the
iterator value remains valid, and you don't need to traverse the list again,
when you need to remove the original element.
Facts are stubborn things.
>> I think that the disconnect here is that you're not really familiar with
>> std::list, you've rarely used it, so you are ignorant of how to properly
>> use this container in practice.
>
> Haha. For your information, I have implemented a data container which
> is (almost) completely equivalent to std::list, but uses a slightly
> different technique (namely, it's a xor list). I have a pretty good idea
> how std::list works.
That's very hard to believe, given your deep misunderstanding as to its
application and proper usage.
> I do know a fair bit about std::list. Your move.
Sure, professor: what's the complexity of std::list<T>::erase()?
(cue Jeopardy theme)
==============================================================================
TOPIC: Any surveys about the premature optimization status nowadays?
http://groups.google.com/group/comp.lang.c++/t/dae885f4f1cdfad5?hl=en
==============================================================================
== 1 of 4 ==
Date: Wed, Sep 30 2009 4:17 pm
From: Juha Nieminen
jimxoch wrote:
> Having read many discussions about software optimization, I have
> noticed that in most of them the premature optimization is regarded as
> a very frequent habit of the professional software developers.
> However, working as a professional programmer myself, I know for a
> fact that the reality can differ a lot from these assumptions.
> Furthermore, while I understand that premature optimization was
> probably a frequent habit back in the 60s and 70s, when programming
> was more like an art and less like a 9 to 5 job, I seriously doubt
> that the situation remains the same till today.
I think it depends on the exact definition of "premature
optimization". There are two possible definitions:
1) Micro-optimization (also called "hacker optimization"), often done
in places which don't need it and don't benefit from it at all, at the
cost of clarity and maintainability, for the sole reason that the
programmer has completely wrong priorities. Micro-optimization is seldom
motivated by actually profiling existing code and finding the need for
it (which is what makes it premature optimization).
2) The opposite of "premature pessimization". In other words, rather
than thinking "I will use a naive solution for this critical part of the
code and optimize it later", the programmer thinks of the optimal
solution first and only then implements that critical part. Unlike
micro-optimization, this kind of optimization happens at the algorithm
level, rather than at the hardware level.
IMO option 1 is a bad thing, and *not* doing option 2 is also a bad
thing. Option 2 *might* in some cases delay the implementation of the
software by some amount without any real benefit (ie. even though the
algorithm is efficient and sound, it never actually gets run on an
amount of data which would show a benefit). This would be what makes it
"premature optimization". However, IMO it's in no way a bad thing
because the code will be already prepared for the case that in the
future the domain of the application expands, so that it will be able to
handle expanded data sets efficiently without having to go over the
existing code to optimize naive algorithms.
== 2 of 4 ==
Date: Wed, Sep 30 2009 4:29 pm
From: Rune Allnor
On 1 Okt, 01:17, Juha Nieminen <nos...@thanks.invalid> wrote:
> 2) The opposite of "premature pessimization".
What term is used for this? Pragmatic preparation?
> However, IMO it's in no way a bad thing
> because the code will be already prepared for the case that in the
> future the domain of the application expands, so that it will be able to
> handle expanded data sets efficiently without having to go over the
> existing code to optimize naive algorithms.
Agreed.
Rune
== 3 of 4 ==
Date: Wed, Sep 30 2009 11:29 pm
From: jimxoch
Thank you very much for answering and thank you for your very
interesting thoughts.
However my question is not "what is the correct way to perform
optimizations". (Which is quite subjective by the way...) The question
is: How *actually* the professional programmers of our generation
perform the optimizations in the real world? What is more frequent, do
they optimize too late or too early? Do you happen to know any surveys
or polls which could enlighten us a little?
Best regards,
Jim Xochellis
Homepage: http://jimxoch.freehost.gr/
== 4 of 4 ==
Date: Wed, Sep 30 2009 11:35 pm
From: "apatrinos@gmail.com"
It seems to me that the golden rule is "write correct code first,
optimize it later". However this does not rule out applying well known
optimizations, algorithms or optimal library routines in the first
writeup of the code. For example, when calculating the value a high
degree polynomial, Horner's rule is an accuracy optimization that
could be applied in the first place, although this is rarely done
because it takes maybe ten minutes to write instead of one.
Obiously when time is a strict constraint something's gotta give.
Mostly this is quality, in any form, e.g. bugs or speed of execution
and one's manager has to be aware of this and not place absurd
demands. With regard to surveys, I think they are no replacement for
lessons learned from years of experience. Moreover, there is no
guarantee that just because most people use one approach, this is the
right one, or that it is the best one for the particular circumstances
one faces.
-Anthony Patrinos
==============================================================================
TOPIC: How to get file count under a directory?
http://groups.google.com/group/comp.lang.c++/t/85c9fe56a4fecd6f?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Sep 30 2009 5:05 pm
From: "Francesco S. Carta"
On 30 Set, 21:04, Rune Allnor <all...@tele.ntnu.no> wrote:
> On 29 Sep, 09:45, James Kanze <james.ka...@gmail.com> wrote:
>
> > On Sep 28, 9:18 pm, Marcel Müller <news.5.ma...@spamgourmet.com>
> > wrote:
> > > Use a time stamp and use a naming convention that follows a
> > > canonical sort order. E.g. mylogfile_yyyy-mm-dd_hh-mm-ss.txt.
> > > The guys that must service your application will appreciate
> > > greatly. Furthermore you should prefer UTC time stamps for
> > > logging to avoid confusion with daylight saving.
>
> > That sounds like a good idea. I'm used to putting the date in
> > the logfile name, and using a sequential number (with a fixed
> > number of digits, so a straight sort will put them in order),
> > but using the time does sound better.
>
> Simple, effective, and still perfectly possible to screw up.
>
> Once upon a time the company I worked for requested some logs
> produced by a software system to be tagged by time instead of
> running index. The patch we got wrote the timestamps on
> a format more or less like (I never got around to actually
> decode it)
>
> printf("log-file-%d%d%d%d%d%d",
> year,month,day,hour,minute,second);
>
> Which was useless to us (why?).
Is that a rhetorical question? That format is impossible to decode
unambiguously!
Heck, I normally lose a bit of hope to get a living from coding at
every single day that passes, but reading code like the above thrusts
me decisively up on optimism.
If the coder that wrote that patch was getting paid, somehow, that
means that I still have a chance ;-)
Your memory made my day, thanks a lot.
Have good time,
Francesco
--
Francesco S. Carta, hobbyist
http://fscode.altervista.org
==============================================================================
TOPIC: Cheap Ed hardy,Polo,BBC,Gucci,Armani,LV,Christina Audigier hardy
clothing on www.ebaychinaonline.com paypal payment
http://groups.google.com/group/comp.lang.c++/t/ea2375c5d515e396?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Sep 30 2009 6:43 pm
From: shoesclothes
For more information,please contact Sophie, Yahoo:
globaltrader2009@yahoo.com.cn
Minimum order is one,factory price also!Paypal payment free
shipping,ship time will take 4-7 working days.
All kind of T-shirts *** www.ebaychinaonline.com
T-Shirts,AFF T-shirt,ARMANI T-shirt,BAPE T-shirt,BBC T-shirt,BOSS T-
shirt,Burberry T-shirt,CA T-shirt men's,CA T-shirt women's,COOGI T-
shirt,CRYSTAL ROCK women's,D&G T-shirt,DIESEL T-shirt,DSQUARED T-shirt
men's,DSQUARED T-shirt women's,Eck Unltd T-shirt,Ed Hardy T-shirt
men's,Ed Hardy T-shirt women's,EVISU T-shirt,GGG T-shirt,G-STAR T-
shirt,HLST T-Shirt,LRG T-shirt,O&L T-shirt,POLO 3 T-shirt,POLO 4 T-
shirt,POLO 5 T-shirt,POLO T-shirt men's,POLO T-shirt women's,Prada T-
shirt,RUEHL T-Shirt,SMET T-Shirt men's,SMET T-Shirt women's,VERSACE T-
shirt,A&F T-shirt men's,A&F T-shirt women's,Gucci T-shirt......
Clothing/Jacket *** www.ebaychinaonline.com
A&F women's,A&F men's,Adicolor men's,Adidas men's,BAPE,BBC
(M-4XL),COOGI,Adidas women's,Jordan NBA,Dsquared,GGG,G-STAR,LRG
(M-4X),NY,A&F Sweater Men's,BOSS Sweater,D&G,ARMANI Sweater,
VERSACE Sweater,POLO Sweater,THE NORTH FACE,A&F Sweater Women's,CA
men's,JUICY,Ed Hardy men's,Ed Hardy women's,EVISU,SMET Women's,C A
women's,Polo men's,Polo women's,Puma men's,Puma women's,kappa
men's,kappa women's,Gucci men's ......
==============================================================================
TOPIC: ★№1★wholesale Blackberry,Iphone,Nokia,Samsung,Vertu,etc brand new
mobile phones★№1★
http://groups.google.com/group/comp.lang.c++/t/de0ceb7f7d7cfc6e?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Sep 30 2009 6:58 pm
From: peng Selina
★№1★wholesale Blackberry,Iphone,Nokia,Samsung,Vertu,etc brand new
mobile phones★№1★
"Apple [www.toptradea.com & www.toptradea.606c.com]
Nokia [www.toptradea.com & www.toptradea.606c.com]
Blackberry [www.toptradea.com & www.toptradea.606c.com]
Samsung [www.toptradea.com & www.toptradea.606c.com]
Sony Ericsson [www.toptradea.com & www.toptradea.606c.com]
HTC [www.toptradea.com & www.toptradea.606c.com]
"
==============================================================================
TOPIC: WHOLESALE……◆Perfect quality! Nike shox, rift,Jordan, Gucci, Puma, D&G,
LV, Chanel, Bape, Ed hardy, Lacoste sneakers◆
http://groups.google.com/group/comp.lang.c++/t/0419ad8f240e155c?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Sep 30 2009 9:35 pm
From: peng Selina
WHOLESALE……◆Perfect quality! Nike shox, rift,Jordan, Gucci, Puma, D&G,
LV, Chanel, Bape, Ed hardy, Lacoste sneakers◆
"Nike Air Jordan sneaker www.toptradea.com & www.toptradea.606c.com
Air-Jordan-J1 sneaker www.toptradea.com & www.toptradea.606c.com
Air-Jordan-J3 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J4 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J5 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J6 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J7 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J8 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J9 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J10 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan 11 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J12 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J13 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J14 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J16 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J17 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J18 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J19 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J23 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J24 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J25 sneaker www.toptradea.com & www.toptradea.606c.com
Jordan True Flight sneaker www.toptradea.com & www.toptradea.606c.com
+Air Jordan Fusion sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan mix1257 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan fly 45 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan Anthony M sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J1+AF1 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J1 23 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan mix6 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan mix sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan Mix9 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan mix3 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J5 mixman sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan 6+AF1 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J11 mix6 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J11 23woman sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J11 Obama sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J11 Antho sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J12mix sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J13+16 sneaker www.toptradea.com & www.toptradea.606c.com
Jordan J13+AF1 new sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J20AF1 sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan J23 mix sneaker www.toptradea.com & www.toptradea.606c.com
"
"Nike Air Max sneaker www.toptradea.com & www.toptradea.606c.com
Air Max 91 sneaker www.toptradea.com & www.toptradea.606c.com
Nike-ID sneaker www.toptradea.com & www.toptradea.606c.com
Air Max 87 sneaker www.toptradea.com & www.toptradea.606c.com
Air-Max-2003 sneaker www.toptradea.com & www.toptradea.606c.com
Air max 5 sneaker www.toptradea.com & www.toptradea.606c.com
Air-Max-Tailwind-09 sneaker www.toptradea.com & www.toptradea.606c.com
Air-Max-new-180 sneaker www.toptradea.com & www.toptradea.606c.com
Air-Max-LTD sneaker www.toptradea.com & www.toptradea.606c.com
Air-Max-2006 sneaker www.toptradea.com & www.toptradea.606c.com
Air Max 97 sneaker www.toptradea.com & www.toptradea.606c.com
Air Max 92 sneaker www.toptradea.com & www.toptradea.606c.com
Air Max 90 sneaker www.toptradea.com & www.toptradea.606c.com
Air-Max-Yeezy sneaker www.toptradea.com & www.toptradea.606c.com
Air Max 09 sneaker www.toptradea.com & www.toptradea.606c.com
Air-Max-TN sneaker www.toptradea.com & www.toptradea.606c.com
Air Jordan LTD2 sneaker www.toptradea.com & www.toptradea.606c.com
Air-Max-Skyline sneaker www.toptradea.com & www.toptradea.606c.com
Air-Max-miniBMW sneaker www.toptradea.com & www.toptradea.606c.com
Air-Max-2009 sneaker www.toptradea.com & www.toptradea.606c.com
Air-Max180 sneaker www.toptradea.com & www.toptradea.606c.com
Air Max 95 sneaker www.toptradea.com & www.toptradea.606c.com
+Nike Shox sneaker www.toptradea.com & www.toptradea.606c.com
Nike-shox-TR sneaker www.toptradea.com & www.toptradea.606c.com
Nike-shox-TL3 sneaker www.toptradea.com & www.toptradea.606c.com
Nike-shox-R3 sneaker www.toptradea.com & www.toptradea.606c.com
Nike-air-Plata sneaker www.toptradea.com & www.toptradea.606c.com
Nike-shox-new sneaker www.toptradea.com & www.toptradea.606c.com
Nike-shox-87 sneaker www.toptradea.com & www.toptradea.606c.com
Nike-shox-97 sneaker www.toptradea.com & www.toptradea.606c.com
Nike-shox-NZ sneaker www.toptradea.com & www.toptradea.606c.com
Nike-shox-R5 sneaker www.toptradea.com & www.toptradea.606c.com
Nike-shox-R4 sneaker www.toptradea.com & www.toptradea.606c.com
Nike-shox-TL1 sneaker www.toptradea.com & www.toptradea.606c.com
Nike-shox-OZ sneaker www.toptradea.com & www.toptradea.606c.com
Nike-shox-TZ sneaker www.toptradea.com & www.toptradea.606c.com
Nike-shox-torch sneaker www.toptradea.com & www.toptradea.606c.com
+Air Force 1 sneaker www.toptradea.com & www.toptradea.606c.com
Air-Force-1 sneaker www.toptradea.com & www.toptradea.606c.com
AF1-low-shoes sneaker www.toptradea.com & www.toptradea.606c.com
AF1-Supreme-TZ-man sneaker www.toptradea.com & www.toptradea.606c.com
+Nike Rift sneaker www.toptradea.com & www.toptradea.606c.com
Nike-Air-zenyth sneaker www.toptradea.com & www.toptradea.606c.com
Nike-Rift sneaker www.toptradea.com & www.toptradea.606c.com
"
"Adidas Shoes sneaker www.toptradea.com & www.toptradea.606c.com
Adidas-Good-Year sneaker www.toptradea.com & www.toptradea.606c.com
Adidas-Good-Year2 sneaker www.toptradea.com & www.toptradea.606c.com
+Puma Shoes sneaker www.toptradea.com & www.toptradea.606c.com
Puma-woman-shoes sneaker www.toptradea.com & www.toptradea.606c.com
Puma-man-shoes sneaker www.toptradea.com & www.toptradea.606c.com
Puma-centennial sneaker www.toptradea.com & www.toptradea.606c.com
Puma sneaker www.toptradea.com & www.toptradea.606c.com
Puma-6 sneaker www.toptradea.com & www.toptradea.606c.com
Puma-new sneaker www.toptradea.com & www.toptradea.606c.com
Puma-Kimi-Rainkkonen sneaker www.toptradea.com & www.toptradea.606c.com
Puma-Anniversary sneaker www.toptradea.com & www.toptradea.606c.com
Puma-8813 sneaker www.toptradea.com & www.toptradea.606c.com
Puma-5 sneaker www.toptradea.com & www.toptradea.606c.com
+Nike Blazer sneaker www.toptradea.com & www.toptradea.606c.com
Nike-Blazer sneaker www.toptradea.com & www.toptradea.606c.com
+Edhardy Shoes sneaker www.toptradea.com & www.toptradea.606c.com
man-shoes sneaker www.toptradea.com & www.toptradea.606c.com
canvas-low-shoes sneaker www.toptradea.com & www.toptradea.606c.com
woman-shoes sneaker www.toptradea.com & www.toptradea.606c.com
Casual-shoes sneaker www.toptradea.com & www.toptradea.606c.com
canvas-high-shoes sneaker www.toptradea.com & www.toptradea.606c.com
+Gucci Shoes sneaker www.toptradea.com & www.toptradea.606c.com
Gucci-size14 sneaker www.toptradea.com & www.toptradea.606c.com
Man-low-shoes sneaker www.toptradea.com & www.toptradea.606c.com
woman-high-shoes sneaker www.toptradea.com & www.toptradea.606c.com
Gucci-shoes-A sneaker www.toptradea.com & www.toptradea.606c.com
Man-high-shoes sneaker www.toptradea.com & www.toptradea.606c.com
woman-low-shoes sneaker www.toptradea.com & www.toptradea.606c.com
+Lacoste Shoes sneaker www.toptradea.com & www.toptradea.606c.com
Lacoste-woman-shoes sneaker www.toptradea.com & www.toptradea.606c.com
Lacoste-man-shoes sneaker www.toptradea.com & www.toptradea.606c.com
Lacoste-white-man sneaker www.toptradea.com & www.toptradea.606c.com
+Prada Shoes sneaker www.toptradea.com & www.toptradea.606c.com
Prada-shoes sneaker www.toptradea.com & www.toptradea.606c.com
+Chanel Shoes sneaker www.toptradea.com & www.toptradea.606c.com
Chanel woman shoes sneaker www.toptradea.com & www.toptradea.606c.com
+Coach Shoes sneaker www.toptradea.com & www.toptradea.606c.com
Coach-woman-shoes sneaker www.toptradea.com & www.toptradea.606c.com
Coach-man-shoes sneaker www.toptradea.com & www.toptradea.606c.com
+D&G Shoes sneaker www.toptradea.com & www.toptradea.606c.com"
==============================================================================
TOPIC: ๑◎๑Wholesale Jacket Christina Audigier,G-star,Gucci,Lacost,Adidas,Bape,
BBC, Burberry, Jackets NO.1 Quality๑◎๑
http://groups.google.com/group/comp.lang.c++/t/15b34030604e2b04?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Sep 30 2009 9:37 pm
From: peng Selina
๑◎๑Wholesale Jacket Christina Audigier,G-
star,Gucci,Lacost,Adidas,Bape,BBC, Burberry, Jackets NO.1 Quality๑◎๑
"Jeans Series<www.toptradea.com & www.toptradea.606c.com>
Evisu Jeans Series<www.toptradea.com & www.toptradea.606c.com >
Christina Audigier Jeans Series<www.toptradea.com & www.toptradea.606c.com
>
ZEN Jeans Series<www.toptradea.com & www.toptradea.606c.com >
Levis Jeans Series<www.toptradea.com & www.toptradea.606c.com >
Iceberg Jeans Series<www.toptradea.com & www.toptradea.606c.com>
Black-Lable Jeans Series<www.toptradea.com & www.toptradea.606c.com>
True Religion Jeans Series<www.toptradea.com & www.toptradea.606c.com
>
Laguna Jeans Series<www.toptradea.com & www.toptradea.606c.com >
G-star Jeans Series<www.toptradea.com & www.toptradea.606c.com>
Diesel Jeans Series<www.toptradea.com & www.toptradea.606c.com >
Bape Jeans Series<www.toptradea.com & www.toptradea.606c.com>
LV Jeans Series<www.toptradea.com & www.toptradea.606c.com>
D&G Jeans Series<www.toptradea.com & www.toptradea.606c.com >
Coogi Jeans Series<www.toptradea.com & www.toptradea.606c.com>
Cavalli Jeans Series<www.toptradea.com & www.toptradea.606c.com>
Artful-Dodger-Jeans Jeans Series<www.toptradea.com & www.toptradea.606c.com
>
RMC Jeans Series<www.toptradea.com & www.toptradea.606c.com >
Gucci Jeans Series<www.toptradea.com & www.toptradea.606c.com>
Ed hardy Jeans Series<www.toptradea.com & www.toptradea.606c.com>
Armani Jeans Series<www.toptradea.com & www.toptradea.606c.com>
BBC Jeans Series<www.toptradea.com & www.toptradea.606c.com>
Prada Jeans Series<www.toptradea.com & www.toptradea.606c.com>
"
==============================================================================
TOPIC: Pass a pointer variable to a function accept reference
http://groups.google.com/group/comp.lang.c++/t/330170d81fae3d1c?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Sep 30 2009 10:37 pm
From: Michael Tsang
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Louis wrote:
> Hi Michael:
>
> 1. test is a void function accepting an int lvalue
> 2. c is passed into test
>
> Is that means i'm passing an int c, and temp is reference to c , eq int
> &temp = c.
That is, &temp = &c
>
> Let say for some reason, i must use pointer in main
> int *ptr = new int(10);
>
> and another function must accept an reference like void test(int &temp)
>
> so passing ptr to test by using
>
> test(*ptr);
>
> will result passing as reference? is there any better way to do it? or
> this is normal?
Dereferencing a pointer gets a l-value (reference), it will result passing
as reference
>
> Many Thanks
> L
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkrEQAQACgkQG6NzcAXitM+YIgCglTs13G/xVu0kqnMHM7ubLVGg
iWMAn3aHniSgD3/4nASg2Kgiv4UzGD3Z
=SMoQ
-----END PGP SIGNATURE-----
==============================================================================
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
