Search Results

Search found 3 results on 1 pages for 'ashleysbrain'.

Page 1/1 | 1 

• 2D object-aligned bounding-box intersection test

  - by AshleysBrain

  Hi all, I have two object-aligned bounding boxes (i.e. not axis aligned, they rotate with the object). I'd like to know if two object-aligned boxes overlap. (Edit: note - I'm using an axis-aligned bounding box test to quickly discard distant objects, so it doesn't matter if the quad routine is a little slower.) My boxes are stored as four x,y points. I've searched around for answers, but I can't make sense of the variable names and algorithms in examples to apply them to my particular case. Can someone help show me how this would be done, in a clear and simple way? Thanks. (The particular language isn't important, C-style pseudo code is OK.)

  Read the article

• Why don't stacks grow upwards (for security)?

  - by AshleysBrain

  This is related to the question 'Why do stacks typically grow downwards?', but more from a security point of view. I'm generally referring to x86. It strikes me as odd that the stack would grow downwards, when buffers are usually written to upwards in memory. For example a typical C++ string has its end at a higher memory address than the beginning. This means that if there's a buffer overflow you're overwriting further up the call stack, which I understand is a security risk, since it opens the possibility of changing return addresses and local variable contents. If the stack grew upwards in memory, wouldn't buffer overflows simply run in to dead memory? Would this improve security? If so, why hasn't it been done? What about x64, do those stacks grow upwards and if not why not?

  Read the article

• Turning temporary stringstream to c_str() in single statement

  - by AshleysBrain

  Consider the following function: void f(const char* str); Suppose I want to generate a string using stringstream and pass it to this function. If I want to do it in one statement, I might try: f((std::ostringstream() << "Value: " << 5).str().c_str()); // error This gives an error: 'str()' is not a member of 'basic_ostream'. OK, so operator<< is returning ostream instead of ostringstream - how about casting it back to an ostringstream? 1) Is this cast safe? f(static_cast<std::ostringstream&>(std::ostringstream() << "Value: " << 5).str().c_str()); // incorrect output Now with this, it turns out for the operator<<("Value: ") call, it's actually calling ostream's operator<<(void*) and printing a hex address. This is wrong, I want the text. 2) Why does operator<< on the temporary std::ostringstream() call the ostream operator? Surely the temporary has a type of 'ostringstream' not 'ostream'? I can cast the temporary to force the correct operator call too! f(static_cast<std::ostringstream&>(static_cast<std::ostringstream&>(std::ostringstream()) << "Value: " << 5).str().c_str()); This appears to work and passes "Value: 5" to f(). 3) Am I relying on undefined behavior now? The casts look unusual. I'm aware the best alternative is something like this: std::ostringstream ss; ss << "Value: " << 5; f(ss.str().c_str()); ...but I'm interested in the behavior of doing it in one line. Suppose someone wanted to make a (dubious) macro: #define make_temporary_cstr(x) (static_cast<std::ostringstream&>(static_cast<std::ostringstream&>(std::ostringstream()) << x).str().c_str()) // ... f(make_temporary_cstr("Value: " << 5)); Would this function as expected?

  Read the article

1