Anon Mike

  • Content count

  • Joined

  • Last visited

Community Reputation

1098 Excellent

About Anon Mike

  • Rank
  1. This is actually a Windows internal thing, not VC specifically. If a process starts up with a debugger attached then the Windows heap manager will put itself into debug mode. To work around it, start your app without debugging (ctrl-F5) and then attach VC to the process after it starts.
  2. why do they have to make engineering so hard?

    Everybody has their mental blocks. For my dad, like many here, it was calculus. He struggled through and went on to be an engineer anyway. I had little trouble with calculus. I was in Computer Engineering and was one of those people that never studied and still got A's and B's. I picked up a Computer Science double major because it was essentially no effort - the coursework was trivial and the projects were fun things that I would have been doing in my spare time anyway. And then came statistics. I took the hard version (meant for math and physics majors) because "hey, why not", and it kicked my ass so hard I dropped out for the reminder of the quarter (it was to late to just drop the one class). I went back later and took the basic probability for dummies course instead and still struggled but at least got through it. It's interesting. Students always complain about how hard their classes are and how it's unfair that there's such a thing as "weeding out". I do a lot of interviewing nowadays. Virtually everybody I talk to has a degree in either engineering or CS. Yet the amount of people who are complete failures at basic technical skills is staggering. We'll go through ~60 people (i.e. people who at least seem qualified based on thier resume) to fill a single entry-level position.
  3. I've given a lot of interviews and no, you probably won't have access to a compiler. In the first place every compiler and IDE is different - I'm neither going to find and install the one you like nor expect you to figure out the one the company uses in what little time is available. Second, at least for the companies I've worked for I don't really care what language you use - I expect that if you can code decently then you'll be able to pick up whatever language your current project uses - and that could easily change from project to project. As for the code itself, I expect it to real and not pseudocode, but I don't care if you make minor syntax errors. I do expect you to have a good algorithm, have at least a vague sense of good structure, and be able to mentally go through it to find the most glaring flaws. As for the simplicity of the questions in the OP, those are commonly seen in the early stages. About a third of the people can't answer them well.
  4. Is it safe to NULL an array?

    [quote name='Chris_F' timestamp='1323163628' post='4891034'] An array of zero length would be like a room with zero width, length and height. Hard to imagine and certainly not useful for anything if it could exist. [/quote] 1-dimensional arrays of length 0 are actually useful. You see them a lot when you have a fixed-sized header in front of a dynamically-sized array and you want the whole lot to be in one contiguous block of memory. e.g., when overlaying a structure on top of serialized data: [code] struct Foo { int some_header_data; size_t length; ArrayType variable_sized_info[]; // "length" elements }; [/code] Since the array is of size 0 it doesn't count toward sizeof and so you can easily get the header size. But since it's declared the structure is padded properly and you can easily access the array elements, e.g. foo->variable_sized_info[42] is legal (assuming there are indeed that many elements of course). *Two* dimensional arrays with both zero-length don't make sense though. And as far as I know not compilable with any of the standard compilers.
  5. [quote name='shurcool' timestamp='1318827715' post='4873321'] They didn't consider the consequences of their decision hard enough at the time. [/quote] [i]at the time[/i], the dominant language was C, not C++, so function overloading wasn't an option. They could have just made everyone call the W version directly, but then people would have whined about how dumb all the API names were (like you sometimes see for the unicode C-runtime functions, e.g. wcslen). Plus Microsoft was already fighting an uphill battle to get people to accept that Unicode was a good thing rather than a waste of memory (ASCII should be good enough for anybody!) And even the people who were willing to accept Unicode didn't want to have to go through their entire program changing function names - porting to NT (from Win16) was enough work already. Plus if they did that then it wouldn't compile for 16-bit anymore and that was where the real market was. The macros were a perfectly reasonable compromise [i]at the time[/i]. It is unfortunate that they don't provide a way to use overloading instead of macros for C++ nowadays, but I imagine there's little real benefit and it would very likely increase compile times in addition to making the headers simply bigger.
  6. Smaller solution to this problem?

    I'm pretty sure 0 meets the criteria for a run-around number. Here's a C version that doesn't use an intermediate digit array: [source] #include <limits.h> int isRunaround(unsigned x) { unsigned divisor = 1; unsigned first; unsigned useddig = 0; unsigned usedval = 0; while (divisor <= (UINT_MAX / 10) && x > divisor * 10) divisor *= 10; first = divisor; do { unsigned digit = (x / divisor) % 10; if (useddig & (1 << digit)) return 0; useddig |= (1 << digit); usedval += digit * divisor; for ( ; digit; --digit) divisor = (divisor == 1) ? first : (divisor / 10); } while (divisor != first); return x == usedval; } [/source]
  7. Assuming Windows again, if the goal is to write formatted number strings, you should just call GetNumberFormat[Ex]. The standards for how numbers are written vary wildly from locale to locale. Unfortunately there doesn't seem to be a corresponding function for reading numbers.
  8. I will sometimes poke at stuff to try to figure out what's going wrong. I'll never check in code that has been "fixed" that way though. It's important to know why it didn't work, both for your own educational benefit and for the sake of your program. There are some guys at work who routinely don't put in their due-dilegence. They tend to get their stuff into code review quickly. Then the code reviews drag on forever as people keeping finding problems or having questions that even the author can't answer. And the rest of us usually end up having to rewrite their stuff as it becomes clear that there are way to many bugs that just got hidden. Or the bug got created when they were poking randomly at stuff and they didn't bother to fully test everything afterwords. They also tend to be the ones that have to have stuff explained to them every month or so because they can't be bothered to get a firm mental picture of what the pieces are and how they fit together.
  9. have issue returning pointer data

    You never actually said what the problem is...
  10. Just switch to Unicode and be done with it. Saying that you are using "the Multi-Byte character set" meaningless. There are literally hundreds of them, all different. Some will support the "special" character you care about and some won't. This is exactly the problem Unicode is meant to solve.
  11. Parsing an OpenType Font File

    Quite frankly, I wouldn't worry about it. Especially not for a game. Windows [i]requires[/i] fonts to have a format 4 cmap. Font makers know this so the vast majority of fonts will have one. The more advanced stacks (i.e. DirectWrite and WPF) will use a format 12 if it's available but still fallback to format 4. You may also want to look at a symbol font as I know they're a bit special but can't remember the details offhand. Some older Mac fonts may only support format 0. If you're targeting the Mac then you might want to support this as well. The other more esoteric formats aren't worth the trouble. If you're thinking of writing your own font renderer then all I can say is good luck. [url=""][/url] should be considered required reading.
  12. [C++] WM_CHAR and the delete key

    DELETE isn't a character, it's a key. Your solution of using WM_KEYDOWN is the right thing to do. In general you need to use WM_CHAR for reading text and WM_KEY* for reading keys. For some reason a lot of people really want to use only one or the other. Resist that impulse, you inevitably run into problems like this.
  13. Raw GDI (i.e. GetTextExtentPoint32) doesn't do kerning at all. If you want kerning you have to do it yourself. GetKerningPairs is a helper function but you still need to manually adjust glyph positions. I don't know if D3DXFont supports kerning or if it's on by default. But if it is then that would explain what you're seeing. Unfortunately I don't see an easy solution short of turning off kerning in DX, assuming that's possible.
  14. Quote:Original post by simotix However, if I messed around with it a bit, and tried the following, I will get a better result Think about it - you are adding the 'A' width twice for every glyph except the first. That's obviously wrong. Your result is also clearly worse. In the top picture the first 'j' is correctly placed, the problem is that it's being clipped. Look at it in notepad at 72pt - the decender should end in a big dot. In the bottom picture it's not only clipped off but the whole glyph is shoved over way to the left. From the picture your last problem is that somewhere you are adding the 'C' width twice. My guess is that you took my code and left in this line: letterBottomLeftX += (charInfo.C * scale); Take that out, or find wherever else you've double added, fix your clipping problem, and you're done.
  15. Is the horizontal stretching expected? Assuming so, I'm pretty sure this is your problem: if(c != 0) { letterBottomLeftX += (charInfo.A * scale); } [...] letterBottomLeftX += letterWidth; letterBottomLeftX += (charInfo.C * scale); Try changing it to: if(c == 0) { letterBottomLeftX = -(charInfo.A * scale); } [...] letterBottomLeftX += (charInfo.A + charInfo.B + charInfo.C) * scale; Your version leaves letterBottomLeftX in this wierd state where it's sitting between the old and new positions. I suspect that between your placement code and your rendering code you end up using the left side bearing twice. If that doesn't fix things then it would be interesting to see the output for "njpjp"