Jump to content
  • Advertisement

mcfly

Member
  • Content Count

    89
  • Joined

  • Last visited

Community Reputation

151 Neutral

About mcfly

  • Rank
    Member
  1. mcfly

    wierd warning :O help

    Quote:Original post by Zahlman Sorry, that's nonsense. This isn't Java; adding short + short doesn't require a promotion to int.Nonsense my ass. Look up section 6.3.1.1 in the standard and see for yourself. Quote:If an int can represent all values of the original type, the value is converted to an int; otherwise, it is converted to an unsigned int. These are called the integer promotions.48) All other types are unchanged by the integer promotions. 48) The integer promotions are applied only: as part of the usual arithmetic conversions, to certain argument expressions, to the operands of the unary +, -, and ~ operators, and to both operands of the shift operators, as specified by their respective subclauses.
  2. mcfly

    wierd warning :O help

    Quote:Original post by Bregma At no time should there be an integral promotion in the original poster's expression. Yes there should. They will be promoted to either int or unsigned int depending on the implementation. Since INT_MAX > USHRT_MAX in this case, the output is the following: s123 = (unsigned short) ((int) s123 + (int) s123);
  3. mcfly

    int or short/long?

    Quote:Original post by Conner McCloud I'm not convinced that range is correct, but even so who's to say one byte isn't large enough to store it?CM Sorry, didn't think clearly. If CHAR_BIT happens to be 16 or higher, one byte would be able to hold it indeed. The range is covered in the standard but I can't back it up with a quote right now. The -32767 and not -32768 specification is to honour other complement implementations besides 2's.
  4. mcfly

    int or short/long?

    Quote:Original post by CTar You can't be promised how big it's, it might be 1 byte or 255, No, one byte wouldn't be enough. An int must be able to represent numbers in the range of -32767 to 32767.
  5. mcfly

    OS Support for DirectX 9

    Quote:Original post by jollyjeffers From a quick scan, everything except Win95 and WinME makes the list. Looks like WinME is supported after all: Quote:DirectX (December 2005) improves the graphics, security, and performance of your operating system. Download and install this update for your Windows 98, Windows ME, Windows 2000, Windows Server 2003, or Windows XP-based system.
  6. I did some more tests and found out that the D3DPRESENTFLAG_LOCKABLE_BACKBUFFER flag was causing the vsync slowdown for me. A bummer really, as I need that flag for supporting menu and dialog boxes in fullscreen.
  7. Have you tried using ::timeBeginPeriod(...)/::timeEndPeriod(...)? Even though the SDK documentation states they are called internally when D3DPRESENT_INTERVAL_ONE is set I never noticed any difference between that and D3DPRESENT_INTERVAL_DEFAULT at all in my application. Both performed vsync horribly until I increased the ::Sleep() resolution myself.
  8. Here's the division function from my own u64 class. Only reason I wrote the damn thing was to maintain portability. void Divide(u64& dividend,const u64 divisor,const bool wantQuotient) { u64 remainder(0); u64 quotient(0); if (divisor < dividend) { unsigned int bits = 64; do { remainder.hi = (remainder.hi << 1) | (remainder.lo >> 31); remainder.lo = (remainder.lo << 1) | (dividend.hi >> 31); dividend.hi = (dividend.hi << 1) | (dividend.lo >> 31); dividend.lo = (dividend.lo << 1); --bits; } while (remainder < divisor); for (;;) { u64 tmp(remainder); tmp -= divisor; quotient.hi = (quotient.hi << 1) | (quotient.lo >> 31); quotient.lo = (quotient.lo << 1); if (!(tmp.hi & 0x80000000UL)) { quotient.lo |= 0x1; remainder = tmp; } if (!bits) break; --bits; remainder.hi = (remainder.hi << 1) | (remainder.lo >> 31); remainder.lo = (remainder.lo << 1) | (dividend.hi >> 31); dividend.hi = (dividend.hi << 1) | (dividend.lo >> 31); dividend.lo = (dividend.lo << 1); } } else if (divisor == dividend) { quotient = 1; } else { remainder = dividend; } if (wantQuotient) dividend = quotient; else dividend = remainder; } // operator examples u64& u64::operator /= (const u64& v) { Divide( *this, v, true ); return *this; } u64& u64::operator %= (const u64& v) { Divide( *this, v, false ); return *this; }
  9. When you say the width and height are valid values does it mean you also include this conditional check: (WindowClientRect.right - WindowClientRect.left) > 0 && (WindowClientRect.bottom - WindowClientRect.top) > 0 before you attempt to reset the device?
  10. Quote:Original post by Deyja It sure is a pointer. Specifically, it's a const pointer. Also; here is a working example which proves that arrays are pointers: *** Source Snippet Removed *** And here's an example which proves they're not: template<typename Object,size_t N> void AcceptsIntPointer(Object (&object)[N]) { // do stuff with ARRAY } template<typename Object> void AcceptsIntPointer(Object& object) { // do stuff with POINTER } void foo() { int an_array[100]; AcceptsIntPointer(an_array); }
  11. Quote:Original post by MaulingMonkey If you're using C++, it's my opinion that code snippet should never be used. For this I use industry::size_of : *** Source Snippet Removed *** As shown, industry::size_of will return the size of the array if declared as an array, the .size() if a standard container, or produce an error if attempted upon a pointer. Of course, you don't have this option in pure C... Here's the compile-time version: template<typename T,size_t N> char(& array_count(T(&)[N]))[N]; .. sizeof(array_count(array_)) Can be wrapped into a macro: #define ARRAY_COUNT(array_) sizeof(array_count(array_))
  12. It's __INTEL_COMPILER.
  13. Quote:Original post by Anonymous Poster Quote:Original post by mcfly It seems most compilers are pretty conservative regarding this optimization. I've never seen one doing it. Here's what could have been... *** Source Snippet Removed *** Two things: 1) That's not the trick being discussed, but it is probably the most optimized version for your case 2) The standard doesn't consider the union trick portable, either The code was just an example of a trivial case where a compiler could disregard the lazy evalution rule. None of the compilers I've tested did and it seems it's the same problem with all conditionals that have logical sub-expressions within them, i.e yours !(a||b) <-> !(a|b). As for the union trick. Can you elaborate (integer sizes aside as I put the typedefs in there to show I only assume platforms where sizeof(short or int or long)=4)? Endianess won't be any problem since we're only testing for a non-zero bit pattern and I don't think the standard allows the type with the more relaxed alignment requirement to be placed anywhere else than at the same spot as the other. In any case, your response somewhat proved my point. I hope compilers will start taking advantage of this optimization opportunity someday so one can avoid non-portable C++ hacks.
  14. Quote:Original post by Anonymous Poster The compiler can optimize this under the "as if" rule. Since there are no side effects in any of the expressions, there's behavioral no difference between the early out version and the check everything version. Whether or not any given compiler does optimize this is another issue. It seems most compilers are pretty conservative regarding this optimization. I've never seen one doing it. Here's what could have been... typedef unsigned char u8; typedef unsigned int u32; .. u8 foo[4]; .. if (foo[0] || foo[1] || foo[2] || foo[3]) { bar(); } // Here, without any help from the compiler, more efficient // but non-portable (unless you use the union trick). if (*reinterpret_cast<u32*>(foo)) { bar(); }
  15. The reason a compiler may produce more efficient code when dealing with const objects is because it can assume there's no aliasing between them and non-const variables. It cannot make the same assumption for variables later marked as const however, so for code output, it's unlikely it'll make any difference at all whether you put 'const' into your function parameters or not.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!