• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

194 Neutral

About zoggo

  • Rank
  1. Worst Book Ever Awards

    Electric Circuits by James W. Nilsson, Susan Riedel For want of a less crude way of putting it, this book is quite simply piss poor! The authors clearly wrote a bit of each chapter at a time not finishing one before moving on to the next. Concepts are regularly used in earlier chapters without any explanation despite the fact that they are not introduced until much later in the book. Also, the worked examples are all ludicrously simple yet the problems are much harder and only numerical answers are provided. Unfortunately circuit theory generally requires generating and solving a rather nasty set of simultaneous equations so the probability of messing up is quite high even if you have got the method right. As if that wasn’t enough, the follow on course to this one required a different book. Fortunately the next book sucked a whole lot less but, irritatingly, covered the previous semester’s stuff much more clearly.
  2. The Cost of Music Piracy

    The title of this thread is actually misleading I think, but here goes... I assume there are many reasons why people feel that music piracy (or any other type of piracy) isn't theft. However, one of my big problems with the record industry in particular is that 10 pounds (give or take) for a CD seems like quite a lot. Perhaps I wouldn't mind but I have a nasty cynical suspicion that a large portion of my cash is paying for things unrelated to the production and distribution of music, fat cat wages for example! I don't know if the facts bare this out or not but I suspect it is a perception shared by others. My questions boil down to these: Is this a common perception? Do people think that piracy would decrease if publishers were more open about what their true costs were? (Or are other factors more important?) Does anybody have any credible sources to establish whether the suspicion is justified?
  3. Which Window to render to

    OpenGL windows should have the CS_OWNDC class style. With this style, you never need to release the DC for each window. ReleaseDC is specified as not doing anything with private DCs anyway, so short of destroying the window, you can't release private DCs at all.
  4. Very often, DCs returned by GetDC do not need to be released at all. In particular, on the ReleaseDC MSDN page: Quote:Class and private DCs do not have to be released. I would strongly suspect that being an OpenGL windows, your DC is private. A private DC is one from a window with class style WS_OWNDC specified. In fact, if it's a top level window then it is highly unlikely to be using WS_PARENTDC which is the only one that needs releasing. Also, bare in mind that ReleaseDC returns a status code, not an error code. It merely says whether the DC was released or not. It might not be released for perfectly harmless reasons. Actually, releasing a private DC qualifies as a harmless operation because it is well defined as having no effect. Unfortunately, this is just one in a long line of irritating semantic inconsistencies with the Win32 API.
  5. edit box inserting return

    The Windows edit box ignores new lines on their own. You may need to insert a carraige return/line feed pair. Basically, you need to include a \r as well. There are a few reasons why Windows may be jerking you around, but I have certainly come across this one before. It's the root cause as to why Notepad can't hack Linux or Mac formatted text files.
  6. Great News!!!! (Pics on page 2!!!)

    For the rest has been said already... One small step for man... One giant leap for nerd-kind!!!
  7. What Major??

    Or u could do the "almost CompSci" choice which I fell for: Electronic Engineering Masters.
  8. NT services

    You can use policies to do this sort of thing which means there is probably a registry entry you can tweak. That could easily be made into a per user thing.
  9. Interesting C++ Case

    Quote: Quote:I am assuming this is permitted because the two variables are of different types...correct? Correct This ain't quite right. For example, the following code is perfectly legal: struct A { int val; }; struct B : A { int val; }; Both variables named val have the same type and the same name. If val is accessed via a B object, the val variable within B (not A) will be unambiguously found because the compiler never looks within A to find the name. Searching the class itself and searching base classes for names happen in separate steps. If it finds a name when searching the class itself, it stops looking; thus the val variable in A is not considered. It doesn't matter what type the variable is or how you use it.
  10. Is MFC good?

    MFC created a fair few of its own problems too. I mean, the damn thing throws pointers! Ok, when MFC was designed exception handling theory as we know it was yet to be thrashed out, but still, hardly a point to commend it. I have to say I would go for wxWidgets any day.
  11. Interesting C++ Case

    It's perfectly legal because of strict application of name lookup rules. Names are looked up in the enclosing class before being looked up in super classes. If a viable name is found in the enclosing class, lookup never progresses beyond the class itself and thus names in superclasses are never considered. It's worth, I think, mentioning that this applies to names within classes in general, not just variable names. For example: struct A { int val; }; struct B : A { void val(); }; B b; b.A::val = 1; // Ok b.val = 1; // INVALID: b.val is a function. This illustrates an important point that C++ looks up names before it checks whether they are valid in a given context. Even if changing b.val to b.A::val implicitly would fix the problem, the compiler won't do it because firstly, it never sees the name, and secondly this leads to interestings bugs if you mistype something and the wrong name gets chosen silently. Name lookup before validation causes the following code to fail too. struct A { int val; }; struct B : A { private: int val; }; B b; b.A::val = 1; // Ok b.val = 1; // ERROR: b.val is private. B's val is found thus lookup stops. It isn't untill afterwords that the compiler realises that the calling code hasn't got access to the variable. A related issue and its associated fix exists for function overloaded in a derived class. I wont explain it here or this post is going to be huge but that topic has been covered in numerous articles.
  12. 64 bit integer types

    I am hardly an authority on this but my readings suggest this is the current position: "long long int" is a gcc extensions to C++ and a standard part of C99. VC7.1 (Dunno about prior to this) supports this syntax as an extension. VC7.1 also supports sized types using the __int## syntax. Thus __int64 works and is usable pretty much as any other primitive type. Both the above support all normal arithmetic ops including comparison. I can't speak for VC6 because it has been a long time since I have used that heap of crap. LARGE_INTEGER is a struct representing a 64 bit int made from two 32 bit types. You have to use special windows api function to manipulate them. To add to the confusion on 64 bit systems the "long int" family of types have mostly become 64 bits. The C++ standard is particularly unhelpfull on the subject. It basically says: sizeof( char ) == 1 sizeof( char ) <= sizeof( short int ) <= sizeof( int ) <= sizeof( long int ) It suggests that unadorned int should be the machine word size but even this ceases to be true on most current 64 bit implementations where sizeof( int ) remains 4. This is why the commitee is considering making stdint.h (presumably as cstdint) available in standard C++ as it is in C99.
  13. Beer for the beginner

    Quote:Can < Bottle < Draft I second that. Canned beer usually has a distinctly metalic taste to it. Unless it's Fosters, in which case it will taste of can if it's draft (if it can so be called) and I don't know what if it's canned. Just out of intrest, what beers do people in Austrailia drink? I assume it can't be Fosters of Castlemain 4X because they taste so damn bad. I have heard good things about Victoria Bitter, but as just proven I am an idiot.
  14. Beer for the beginner

    Well I guess I'm an idiot. Alas.
  15. Beer for the beginner

    Quote:What's the matter lagerboy, afraid you might taste something?. Slight difference Yea yea, alright. Reading a t-shirt whilst drunk is hard!
  • Advertisement