Comment On Let's All Reinvent the Wheel... Again, and More

Some:

Spectre:

Here's a trick question. Observe the following snippet, which is supposed to set every element of the array to 42. N is a positive integer.

short a[N];



for (short * p = a + N - 1; p >= a; --p)

  *p = 42;

This code, besides being literally backwards, looks normal, right? Right?

1) Why is this code wrong from the theoretical point of view? Bonus points for citing relevant portion of the standard.
2) Name a real scenario in which the code would b0rk.
3) How would you do the task (that is, fill an array with 42's) in C? In C++?

At the last loop p will run outside the "a" momory-section and will cause Memory Access error...

Nope. At the last loop the p will be equal to a. Methinks.

The problem is that incrementing a pointer one past the end of the allocated memory area is an undefined operation per standard (IIRC). a+N-1 does not need to be optimized, it may literally take address of the array, increment it by N elements, and then move back one element. On most platforms this will work as you expect it to. But it's not guaranteed to.

As for filling the array in C, there's no standard way IIRC. If sizeof(char)==sizeof(short) then memset will work. In C++, there's std::fill.

I don't think there are real scenarios where the code would b0rk, unless you're on some crazy architecture. Maybe some big iron would mind such code. I mean architectures contorted enough to have a dereferenceable (w/o violations) NULL pointers.

I can't think of a commonplace "consumer" architecture where pointer arithmetic isn't done modulo some power of two, and pointers can't store crap without further ado. I'd have to look up how Turbo C did pointer arithmetic, but in all models I think this would still work as you expect, even if the segment registers would be tweaked along the way.

Am I missing something obvious (it's late here)?

"Oh, that..." she said, "I didn't know what this 'std' means."

"I see," I said, and ended the interview immediately.

That's pretty harsh. Did she not understand the concept of a namespace? What about polymorphism, operator overloading, virtual functions, is-a versus has-a, or other object-oriented concepts? Or did you end the interview before you could find out?

Tool.

Kuba:

Nope. At the last loop the p will be equal to a. Methinks.

Nope. In order for loop to break the comparison

p >= a

must evaluate to false. Thus p must have decremented to a pointer value before the array.

The problem is that incrementing a pointer one past the end of the allocated memory area is an undefined operation per standard (IIRC). a+N-1 does not need to be optimized, it may literally take address of the array, increment it by N elements, and then move back one element. On most platforms this will work as you expect it to. But it's not guaranteed to.

The concern of a+N-1 does not actually apply to this case. The calculation will be correct even if a[] takes up the last N addressable words (which is why the spec makes *(a+N) undefined to begin with).

The problem with the original code was

--p

. After the last loop, when p == &a[0], there is no gaurantee that --p will result in a p value less than &a[0]. Specifically if &a[0] = 0 (a[0] is the first addressable word), then the last --p will result in p much larger than a since pointers are unsigned.

If sizeof(char)==sizeof(short) then memset will work.

I don't think that matters,

memset(a,42,sizeof(short)*N);

should always work.

I don't think there are real scenarios where the code would b0rk, unless you're on some crazy architecture.

If &a[0] < sizeof(short *) then the pointer arithmetic on p will underflow causing p to have a very large value. I'm not sure which OS would give you a data segment with a virtual address starting at 0x00000, but it is conceivable and it would die.

Am I missing something obvious (it's late here)?

I wouldn't call it obvious.

tsmith:

"Oh, that..." she said, "I didn't know what this 'std' means."

"I see," I said, and ended the interview immediately.

That's pretty harsh. Did she not understand the concept of a namespace? What about polymorphism, operator overloading, virtual functions, is-a versus has-a, or other object-oriented concepts? Or did you end the interview before you could find out?

Tool.

Contrary to what was stated, their standards are not "immensely high", they are "exclusive." They may be high as well, but the primary effect is exclusivity. There is a difference.

Most employers make this mistake. They will pass over extraordinarily capable candidates because "they didn't have enough knowledge of Specific Technology X." I'm sure most employers would turn down Donald Knuth for a job writing Ruby code because he didn't have specific knowledge of Ruby even though he is one of the most renowned computer scientists in the world.

SuperousOxide:

Why is copying the variable to make the pass-by-value parameter more efficient than copying the variable to make a local variable?

Because the pass-by-value parameter is constructed by the calling function, saving one copy operation in some cases. For instance:

void twistAndPrint(const std::string& thestring);



void readTwistAndPrint()

{

  std::string input;

  std::cin >> input;

  twistAndPrint(input);

}

This will create an empty string, fill the string using the stream operator >>, pass a reference to this string on to twistAndPrint, where it will be copied.

On the other hand, if twistAndPrint accepted an std::string, the compiler could easily figure out that since "input" is no longer used after "twistAndPrint" (the only method that will be called on "input" after twistAndPrint is the destructor), the compiler could create "input" on the stack in a location suitable to the subsequent invocation of twistAndPrint, and no copy operation would be necessary.

Of course, given sufficient knowledge of what twistAndPrint does and where it is used, the compiler might make the same optimization in the "const std::string&" case. But the point is that this requires the compiler to perform global optimization, using much more knowledge of the entire program, whereas the original optimization requires only local ("peephole") knowledge including the already known signature of twistAndPrint. Therefore, real world compilers will be much more likely to perform the optimization in the pass-by-value case than in the pass-by-reference case. Also, there could be incompatible uses of twistAndPrint which prevent the optimization in the latter case anyhow (most importantly if twistAndPrint is used in a way which prevents the compiler from altering the calling convention without breaking the linked program, i.e. exported to external programs or passed to external programs as a callback).

For further information, see "Move Constructors" by Andrei Alexandrescu.

Kuba:

The problem is that incrementing a pointer one past the end of the allocated memory area is an undefined operation per standard (IIRC).

No, that part is ok. It is fine to point one past the end of an array, as long as you don't dereference, and this is what users of the STL do all the time (remember that pointers are iterators!). The problem is that this code tries to move the pointer one past the beginning of the array, and that is illegal.

Kuba:

I don't think there are real scenarios where the code would b0rk, unless you're on some crazy architecture. Maybe some big iron would mind such code. I mean architectures contorted enough to have a dereferenceable (w/o violations) NULL pointers.

Yes, segmented memory. The array could be at offset 0 in a memory segment. The corresponding pointer is not a NULL pointer, but either the decrement itself or the following comparison will easily cause mayhem.

Segmented memory may be an oddity on x86 (32 or 64 bit) today because the flat memory model basically won, but no exotic processor architecture is necessary, only a more or less exotic rsp. outdated OS.

Kuba:

I think this would still work as you expect, even if the segment registers would be tweaked along the way.

In real mode, the compiler-generated code may be smart enough to handle this case. But even then, in Borland C++ it would not work in all memory models because only in the "huge" memory model would the compiler bother to insert expensive segment adjustment code for pointer arithmetic in all cases. In other memory models, you had to use a special type of far pointer if you wanted that to happen IIRC.

In protected mode, segment adjustment isn't even possible in the general case, so all bets are off.

Erik:

Clearly the woman applying for the clerical position is very detail orented.

And she has an penchant for using the wrong indefinite article. On the other hand, she does have a pleasant phony voice. :-)

Russ:

What if they did C++ on a *nix platform? Not the whole world is MS centric you know.

Oh, right, I almost forgot that MS invented the STL, and SGI (IRIX anyone?) never implemented that sucker, and never donated the code to the GNU libc++ project, and that libc++ is actually not available on a huge range of UNIX platforms be they Solaris, Linux, Mac OS X or many others. Sheesh.

FredSaw:

real_aardvark:

FredSaw:

OedipusPrime:

I REALLY hope that even the juniorest guy in the room can tell you the difference between assignment and comparison operators.

Depends on the language. In VB they are the same.

*Ahem* No they are not. They happen to be represented by the same symbol (which is idiotic) and are thus lexically the same. Unfortunately, and invisibly, they are syntactically distinct.

Mind you, this would make for a whole 'nother set of useful interview questions if, for some obscure and twisted reason, you are seeking to hire a VB programmer.

RA, I respect you more than to say, "What a dumbass reply." So I won't.

i've lost count the number of times this topic has come up for discussion. wrt the = sign in vb, it's context sensitive.

hmmm... what's that on ur face? oh it's just egg.

I'm (almost) certain that the interviewed guy said that as a joke (no code reuse, just likes to start over).

  short a[N];



    for (size_t i = 0; i < N; ++i) {



        a[i] = 42;



    

As A C novice, I keep wondering why ++i is used instead of i++. Wouldn't that overflow the array at the last iteration, and keep the short with index 0 uninitialized??

Filthy_Liar:

If sizeof(char)==sizeof(short) then memset will work.

I don't think that matters,

memset(a,42,sizeof(short)*N);

should always work.

Of course it works. You end up with every element of the array set to 10794, but no errors occur, which I assume is your definition of the word "work".

memset() assigns a value to every byte in the referenced memory, and your "sizeof short" *looks* like a clue but it's not. The function receives the address of the array, a value, and the number of bytes to fill, period . . . so instead of
002A002A002A002A002A002A
the memory will look like
2A2A2A2A2A2A2A2A2A2A2A2A

Jim:

As A C novice, I keep wondering why ++i is used instead of i++. Wouldn't that overflow the array at the last iteration, and keep the short with index 0 uninitialized??

for(expr_1; expr_2; expr_3)

{

  statement;

}

is equivilent to

expr_1;

while(expr_2)

{

  statement;



  expr_3;

}

The ++i or i++ is evaluated entirely in expr_3, it doesn't change *when* expr_3 itself is evaluated.

The difference between ++i and i++ is what value it evaluates to... which in the case of the for loop the value the expression evaluates to is never used.

Here's an example with behavior analogous to the for loop... notice how the choice of i++ or ++i doesn't matter... j matches i.

int i = 0;

int j = 0;

j = i; // j = 0, i = 0

i++; 

j = i; // j = 1, i = 1

++i;

j = i; // j = 2, i = 2

Here's an example of when it would matter.

int i = 0;

int j = 0;

j = i++; // after this is evaluated j = 0, i = 1

j = ++i; // after this is evaluated j = 2, i = 2

And here's another example where it matters.

int i[N];

int j = 0;

i[j++]; // this is i[0]

i[++j]; // this is i[2]

Hope this helps!

Jay:

..."What is your greatest weakness?"...

Answer: My greatest weakness is that I have little patience for incompetence... If I have to explain something more than 3-4 times to someone, I tend to insist that they make more of an effort.

Jim:

  short a[N];



    for (size_t i = 0; i < N; ++i) {



        a[i] = 42;



    

As A C novice, I keep wondering why ++i is used instead of i++. Wouldn't that overflow the array at the last iteration, and keep the short with index 0 uninitialized??

Not much difference in C, the difference is in C++. The "++object" form is more efficient when dealing with real objects. Using "object++" instead would require that a copy of the object be made before incrementing the real one. The copy is then returned instead of the original. With "++object" a reference to the real one can be returned.

Not important when you're dealing with ints, or where the value is not being used, but just a good practice to get into, especially with poorly written code that includes dynamic allocations in the object (which you don't want to have to check for). I believe there is a section in Effective C++ about this. The rule is: if you have pointers in your object, you need a destructor, an assignment constructor and a copy constructor (once again, if I remember right).

This is also an area where different compilers may produce different behaviour -- one may produce a copy of the object, another may not. It's done behind the scenes for you, or *against* you when things go awry. You want to avoid that difference in programs you want to be portable.

The Enterpriser:

All good coders use vim.. didn't you know?

Fixed that for ya.

I used gVIM all the time, even in windows. VIM has had syntax highlighting for years...

Russ:

Russ:

diaphanein:

Russ:

Ytram:

...and get the trick questions wrong, as did most people...

What's the point of asking a trick question? Is it so you can see how people deal with trick requirements? Or trick designs?

No so people know how to find bugs in code. For example

x=3;
if (x=5)
cout<<"5";
else
cout<<"not 5";

What is the output?

5. Next?

I really hope that was sarcasm

Actually my bad.. haven't had my morning coffee yet.

The answer should be 5. It is a bit of a trick question, as some junior developers might not know the difference between

if (x==5)

and

if (x=5)

By "junior developers", I assume you mean high-school students?

Seriously though, when I first looked at teh codez above, I didn't see the missing "=" either. Of course I know the difference, but "trick" questions like that are retarded.

In this case ++i is the only op being done so its irrelevant.
However dont do "a[++i] = 42;".
"a[i++] = 42;" would be OK though... :D
Search google for «C unary prefix posfix». First hit will get you:

"The increment/decrement operators can be applied before (prefix) or after (postfix) the operand. The code result++; and ++result; will both end in result being incremented by one. The only difference is that the prefix version (++result) evaluates to the incremented value, whereas the postfix version (result++) evaluates to the original value. If you are just performing a simple increment/decrement, it doesn't really matter which version you choose. But if you use this operator in part of a larger expression, the one that you choose may make a significant difference."

If you test candidates for

x=3;
if (x=0)
cout<<"0";
else
cout<<"not 0";

*and* ask for a verbose explanation of the result than you may start getting some pretty explanations: "0 is diferent of 3; therefore «not 0»!"

I must say I love these esoteric discussions of the C spec. Every time I think I know the language someone knocks me down a peg.

But it's how I learn. Thanks guys.

K.D. you did not make me laugh. Why don't you just accept that the brilliant guy has never got a project wrong? As surprising as it may be, skilled and smart developers can get things always almost right (or fixed them on the go) and not let a project failed by incompetence.

I, for one, admire his honesty. He probably knew that what he was going to say could hurt him. I think *he* tested *you*. Something like "Let's if my (potential) boss can cope with a guy like me".

Flavio:

As surprising as it may be, skilled and smart developers can get things always almost right (or fixed them on the go) and not let a project failed by incompetence.

"Always almost right". 2+2 = 3.99999, but consistently so.

He probably knew that what he was going to say could hurt him.

And he ended up saying something dumb that hurt him. Zero points awarded.

I think *he* tested *you*. Something like "Let's if my (potential) boss can cope with a guy like me".

I wouldn't want someone on my team who had to be "coped with". Why can't you play well with others?

The Enterpriser:

Edward Royce:

*shrug* personally I'd be wondering why the IDE and/or compiler hadn't picked up on an assignment in an if() statement.

All good coders use vi.. didn't you know?

I'd rather use UltraEdit frankly.

Not a huge fan of vi. Or of emacs.

eryn:

FredSaw:

real_aardvark:

FredSaw:

OedipusPrime:

I REALLY hope that even the juniorest guy in the room can tell you the difference between assignment and comparison operators.

Depends on the language. In VB they are the same.

*Ahem* No they are not. They happen to be represented by the same symbol (which is idiotic) and are thus lexically the same. Unfortunately, and invisibly, they are syntactically distinct.

Mind you, this would make for a whole 'nother set of useful interview questions if, for some obscure and twisted reason, you are seeking to hire a VB programmer.

RA, I respect you more than to say, "What a dumbass reply." So I won't.

i've lost count the number of times this topic has come up for discussion. wrt the = sign in vb, it's context sensitive.

hmmm... what's that on ur face? oh it's just egg.

Hmmmm. Counting coup, nerd-style.

That's why an experienced programmer will always write.
if ( 5==x ) {
}
We had this arguement on here before:
"An expert programmer shouldn't rely on the compiler to find his mistakes" vs "An expert programmer uses all the help he can get"

(I'm the original poster/interviewer in the story)

Yes, that in fact, I believe, was what he meant. He didn't believe in ever going back to refer to previous work (of his or anyone else's) but rather wanted to start every single project with a clean slate. Admirable in a sense, but why on earth would you want to re-invent simple common elements over and over?

And to the person who said that asking someone to point out their weaknesses is a flawed interview style -- well, actually, it's worked very well for me. This candidate was horrible flawed, and by opening a door, he pointed it out himself.

dpm:

snoofle:

morry:

I'd like to come up with some trick questions to ask a company in an interview some time.

For any established organization: {...}

That's a good list, but the one I always ask is "what do you use for source code control?"

There are some good answers and some poor ones, depending on the scale of the projects involved. But the two that always raise red flags are "none" and "we use a system we developed in-house". Danger Will Programmer!

Heh, the job I am about to leave gave the latter as an answer when I asked. Actually, they volunteered it as if it were a source of pride. Gah.

Bonus points if said in-house "source control" is written in VB6.

I was about to say the same thing. To the best of my knowledge, most university classes do not discuss namespaces. I feel like many C++ programmers just know that they need to put using namespace std; at the top of their files.

Additionally, I have to wonder how important it is that a job candidate understand namespaces on the day that they start if they show overall competence. First, namespaces are easy to understand, so, it wouldn't take long to explain to explain if your organization really is making use of them. Second, I think that maybe half of all organizations actually take care to use them in any meaningful way.

Some Interviewer:

1. Sometimes you need a warm body; this is where the best of the worst is still better than nothing. (Sadly.)

At least there's one valid reason.

2. Legal reasons. If a candidate is immediately turned down, they may assume it was because of their gender, race, religion, etc. and not because they failed a test.

Fields that involve physical activity (electrician, plumber, etc.) failure is pretty obvious to spot. The light doesn't turn on, the faucet leaks all over, etc. Fields like software development aren't quite so easy. The candidate didn't even understand the test; how will they comprehend their failure?

Because you could tell them that they failed and if they ask why, you could say you don't have time to teach them. If you did tell them, you aren't opening up a legal battle if you are right. The HIGH cost of legal battles will keep most from even attempting. People have been graded since early childhood and are going to accept it (if mentally sound and if not then you might have a valid reason.) If you ARE rejecting based on personal attributes, "not a good fit" is used a lot or you could cop out but that wasn't WhiskeyJack's point.

3. It's how the game is played. Don't whine.

Great argument for status quo lovers. I hope people that pick #3 get LOTS of annoying calls asking.

Flavio:

K.D. you did not make me laugh. Why don't you just accept that the brilliant guy has never got a project wrong? As surprising as it may be, skilled and smart developers can get things always almost right (or fixed them on the go) and not let a project failed by incompetence.

I, for one, admire his honesty. He probably knew that what he was going to say could hurt him. I think *he* tested *you*. Something like "Let's if my (potential) boss can cope with a guy like me".

Honestly I'm shocked at the number of pple that posted stuff similar to this. Nobody has ever put out 100% perfect work. If you can't accept your own faults, then you'll never improve.

Yes your projects may all have been completed successfully ... that doesn't mean there weren't decisions you made that you had to go back and change, or in hind-sight wished you could have changed.

I hope I get asked that question at future interviews. Then at least I'll know that I'll be working with people that grow ... instead of stagnate in the knowledge that everything they produce is perfect.

Anon Fred:

I must say I love these esoteric discussions of the C spec. Every time I think I know the language someone knocks me down a peg.

But it's how I learn. Thanks guys.

Yes, I agree. This is the perfect kind of question I want my company to be asking in an interview.

Why worry about actual coding ability when they can rattle off obscure facts about the C language specification that are rarely applicable to modern architectures? After all, as we all know, everyone who is worth their salt has been coding in C since the days of segmented memory.

Furthermore, I think it goes without saying that people who enjoy picking apart trick questions are the very kind of people I want designing my algorithms. Sure, its one thing if the algorithm *works*, but is it *optimized*? No doubt we would all agree that all algorithms we write should exhibit the same kind of cleverness as these questions. Cleverness = maintainability.

To extend this idea a bit, I think I will ask interview questions about real-mode programming and maybe pepper in a few questions about the ALGOL specification.

alegr:

"Oh, that..." she said, "I didn't know what this 'std' means."

That's what you get for unsafe hex!

OK, that was just very silly. And very funny. Thanks.

I was in Jonestown, Tanzania once and saw a strip mall shop sign announcing Kinko-like services and more. The shop was also offering typing services. The name, written in bold letters in front of the shop, was "Helen's Secretalrial Services".

I didln't enquire about their serlvices.

Anonymous Coward:

Anon Fred:

I must say I love these esoteric discussions of the C spec. Every time I think I know the language someone knocks me down a peg.

But it's how I learn. Thanks guys.

Yes, I agree. This is the perfect kind of question I want my company to be asking in an interview.

Why worry about actual coding ability when they can rattle off obscure facts about the C language specification...

I actually agree with you that posing trick questions about obscure trivia is not a great interview technique, but it can be a good learning technique. If you're not interested in understanding or learning why something like underflow on pointer arithmetic might result in undefined behavior, then you might want to stay away from C/C++ because those languages love to stick you with runtime bugs that result in rare instances of that undefined behavior biting you in the ass. Without a doubt, this is a major drawback of C/C++; other languages let you largely stop worring about such details.

So, while maybe being able to pick out the obscure potential bug is not something to look for in a potential hire, I'd certainly like anyone who I'm working with on a C/C++ project to at least *want* to understand or learn about these pitfalls if someone's pointing them out.

Yes, I agree. It makes me wonder if the author understands the language very well himself. There certainly are cases where a mutable value parameter is preferable.

At companies in the Seattle where I have interviewed - and worked - at (Amazon, Microsoft, Real) there is much more of an emphasis placed on higher level design than on basic language semantics. When I have interviewed for our team I always focus on finding out what the candidate can do well and how they would be able to contribute. Often intellectual horsepower is a better measure of a candidate than language specifics anyway.

brazzy:

David Schwartz:

Highly-experienced C++ programmers might have little to no familiarity with the standard library functions. This is especially true for people who have been programming C++ for a very long time and maintain codebases that still have to run on machines whose standard library support is somewhat lacking.

Not being familiar with details of the standard library is excusable, but not even knowing what it is is not.

There is a difference between not knowing what a standard library is, and not knowing what its namespace is, or that it has one, since some implementations let you call the entire standard library (or what parts of it are implemented) without it.

WhiskeyJack:

Some Interviewer:

1. Sometimes you need a warm body; this is where the best of the worst is still better than nothing. (Sadly.)

2. Legal reasons. If a candidate is immediately turned down, they may assume it was because of their gender, race, religion, etc. and not because they failed a test.

Fields that involve physical activity (electrician, plumber, etc.) failure is pretty obvious to spot. The light doesn't turn on, the faucet leaks all over, etc. Fields like software development aren't quite so easy. The candidate didn't even understand the test; how will they comprehend their failure?

3. It's how the game is played. Don't whine.

Hey, I ain't whining - I got my job already. Every place that had me for an interview gave me an offer. I'm just thinking that it would be so much more practical (albeit less funny stories for sites like this) if people who are obviously unqualified, or have extreme quirks, to be told so. Might actually be an incentive for them to improve.

Like the guy in the first story, the interviewer was ready to hire him until he said his last bit. It would be nice if the interviewer could have actually told him "I was ready to hire you until you said that last part. That's not how it's done in the industry, so, sorry..." The intent is to have these people walk out of the room thinking "Have I got it wrong? Do I need to change my way of thinking?" rather than "Bah, another jerk company that won't recognize me for the programming God that I am!"

Granted you'll always have a few that think that way and nothing will change them, but for the rest, finding out WHY you didn't get the job should be a good teaching experience.

The policy "Can't tell them why they're not hired for legal reasons" has always translated in my mind to "Some of our reasons for not hiring people are illegal".

Kuba:

If sizeof(char)==sizeof(short)

This is never true on a normal programming environment (it may be true for some exotic embedded systems) - the reason: sizeof(char) always == 1. sizeof(short) is ALMOST NEVER going to be that, because a short has to be at least 16 bits, and a char is _normally_ eight bits.

snoofle:

Jay:

..."What is your greatest weakness?"...

Answer: My greatest weakness is that I have little patience for incompetence... If I have to explain something more than 3-4 times to someone, I tend to insist that they make more of an effort.

I'm sorry, I wasn't really paying attention. What did you say your greatest weakness was, again?

Fresh out of uni my CV was short on content so I decided to employ a "professional" CV writer to rewrite it for me using all the tricks of the trade. I filled in her questionnaire and sent off the results, a couple of weeks later I received the finished article. There were _numerous_ typos including the following:

"Accurate and eloquent in witten communications."

FredSaw:

Velko:

Never make any mistaeks.
-- Anonymous, in a mail discussion about to a kernel bug report.

Wow, what a dumbass! Can you spell "looser"?
-- Not anonymous, in the middle of a forum confrontation, but I will keep him so anyay, bless his uneducated little heart.

Anyay?

Mrs. Applicant:

I didn't know what this 'std' means.

It's what you get when you're screwed, and you certainly are...

This is obviously engineered (poorly).

情趣用品情趣用品情趣用品情趣用品情趣情趣情趣
情趣按摩棒跳蛋充氣娃娃
情境坊歡愉用品[/url[url=http://www.show688.net/shop/index.php?wid=twjason]情趣用品情人節禮物情惑用品性易構免費A片AV女優美女視訊情色交友免費AV色情網站辣妹視訊美女交友色情影片成人影片成人網站A片H漫18成人成人圖片成人漫畫情色網日本A片免費A片下載性愛成人交友嘟嘟成人網成人電影成人成人貼圖成人小說成人文章成人圖片區免費成人影片成人遊戲微風成人愛情公寓情色情色貼圖情色文學做愛色情聊天室色情小說一葉情貼圖片區情色小說色情寄情築園小遊戲色情遊戲情色視訊情色電影AIO交友愛情館言情小說愛情小說色情A片情色論壇色情影片視訊聊天室免費視訊聊天免費視訊視訊美女視訊交友視訊聊天免費視訊聊天室AIOA片下載AV[url=http://www.ing.net/042]AV片A漫AV DVDAV成人網聊天室成人論壇本土自拍自拍A片

北京seo
加拿大留学
配音
广告配音
专题片配音
课件配音

&nbsp;&nbsp;
货架racking.&nbsp;&nbsp; 仓储货架
南京货架设备要产品包括:重型货架
,阁楼货架,超市Shelf,重量型货架,横梁式货架,驶入式货架... 仓储笼
货架的形式与材料 · 立体仓库 · 货架厂
物流规划设计的步骤与程序（货架的设计... 中国物流行业呈现三足鼎立抢市场 · 亚洲第三方物流的现状和发展 ... 托盘
抽出式货架系列 · 重力式 货架/推入式货架钢托盘
移动式货架 · 阁楼式货架 · 悬臂式货架
系列 长件物料储存货架&nbsp;货架公司。

http://www.tiffanysale.co.uk/
http://www.jewelrygucci.com
http://www.ustiffanyjewelry.com
http://www.bestguccishoes.com/
http://www.gucci-stores.com/
http://www.uktiffanyjewellery.co.uk
http://www.handbagon.com/
http://www.louisvuittonfr.com/
http://www.tiffanygifts.co.uk
http://www.wmbags.com/
http://www.chanel-jewelry.com

Oh, please, who can remember what all those acronyms mean? The question is, does she know how to -use- std? (What does it mean, anyway? Standard? And whenever I see stdio and want to pronounce it as "studio"... Talk about poor naming conventions...)