joanusdmentia

Members
  • Content count

    2464
  • Joined

  • Last visited

Community Reputation

1060 Excellent

About joanusdmentia

  • Rank
    Contributor
  1. "1" vs "1.0f" - makes a difference?

    Quote:Original post by dmail Quote: dmail@x1-6-00-11-2f-24-88-81:~/gcc_warning> gcc -ansi -pedantic -pedantic-errors -Wall -Wextra float_double.c float_double.c: In function ‘main’: float_double.c:5: warning: unused variable ‘f2’ float_double.c:4: warning: unused variable ‘f1’ float_double.c:3: warning: unused variable ‘f’ dmail@x1-6-00-11-2f-24-88-81:~/gcc_warning> cat float_double.c int main() { float f = 1.0/3.0; float f1 = 56355465468487.3; float f2 = 1e50; return 0; } dmail@x1-6-00-11-2f-24-88-81:~/gcc_warning> Why would I be being stupid? you can see the error and warning flags I am passing to the compiler. I also get the same behaviour with gcc-4.2.3 using C++, which I was little surprised about. I tried to poke it but without any luck... philpalk@innerchild:~$ g++ -ansi -pedantic -pedantic-errors -Wall -Wextra main.cpp philpalk@innerchild:~$ cat main.cpp double dostuff(float f) { return f; } int main() { float f = 1e50; double d = 1e50; f = d; f = dostuff(1e50); } philpalk@innerchild:~$
  2. Vista and access denial...

    Yep, that's about right.
  3. Software Guy needing a new PC build

    Well, from the sounds of things RAM and harddrive are going to be your biggest factors here. I would say go 4GB of RAM (it's dirt cheap) and run 64-bit XP or Vista (you want 64-bit to be able to use all 4GB). I'd lean towards Vista64 as I believe it's driver support is better than XP64, although it shouldn't be an issue with a new system. For movie editting you'll probably want a RAID0 (splitting) array of some decently sized drives (size depending of course on just how much movie editting you'll be doing, how much source footage, etc.), but be aware that the more drives you have in your RAID0 array the more likely it is a drive will die and you'll loose everything, so keep backups. If this bothers you then take a look at RAID1 (mirroring), you still get a (smaller) boost in read speeds but with the benefit of redunancy so if all but 1 of the drives dies doesn't matter. You can even go RAID0+1 or RAID1+0 (there's a difference, check Wiki for a quick overview), but they require at least 4 drives. Since gaming isn't that high on the list the other compenent don't matter all that much. Typical mid-range components should cover you.
  4. Who wants a Quantum Sleeper?

    Looks like an oversized coffin with all the modern conveniences.....
  5. std::ifstream on 64-bit OS

    You could have problems with the S_MD2Header structure, odds are that type sizes and/or alignments have changed. Having said that, that wouldn't cause the contents to be all 0's, you'd get garbage data. Try calling gcount() to see how many bytes were successfully read in the last operation.
  6. Please Help, Strange request.

    Quote:Original post by The-Moon Quote:Original post by joanusdmentiaAs for using VB, those arguing against it are doing so purely from the point of view that you *cannot* write a device driver in VB. If you decide to do the custom hardware then you could use any language you like, serial comms are easy. I had no idea vb was able to make drivers... : Ive always assumed that was a asm/c/c++ thing... However i've been know to be wrong... :) When nvida starts using vb to makes its drivers, ill believe you tho :D You've misread. I was saying doing serial comms is easy in any language, not that you could write a device driver in any language.
  7. Please Help, Strange request.

    To do what you want you really do need some custom hardware (see here for an idea of what's involved). In that link they use an HC11, but you should be able to get away with a PIC and a bit of support circuitry running on a breadboard. It will work like this: * You'll communicate with the custom hardware via serial port, issuing the various commands using some arbitrarily chosen protocol (*forget* using USB, it's way too complicated for a hobby job like this) * The PIC (which you'll obviously need to program yourself) will generate the appropriate signals that the PSX will understand. The reason you need to do it this way is that unless you're writing a device driver you wont be able to get the timing granularity required to get a stable clock signal or to keep your other lines in sync with the clock line (and even then you'll probably have trouble). A PIC or micro-controller on the other-hand would be dedicated to the task and timing is typically done on a timer interrupt or by counting cycles, and the time taken can be calculated to within the accuracy of the oscillator driving your processor (ie. very accurately, external crystal oscillators are better than the internal RC oscillators, but the internal would easily be good enough for what you want). As for using VB, those arguing against it are doing so purely from the point of view that you *cannot* write a device driver in VB. If you decide to do the custom hardware then you could use any language you like, serial comms are easy. EDIT: Oh, and for setting up the hardware you'll first need to drop in to your local electronics store and get a PIC programmer (either pre-built or as a kit you can assemble yourself). This will allow you to load the executable onto the PIC. BTW, you won't be using VB to on the PIC, assembly and C are your only choices [evil] EDIT2: Of course, if you're feeling really adventurous you could get a development board for something like a ATmega MCU and drop the PC completely. Have your board take the controller in and spit out the signals (with macros inserted) to the PSX, it could run off the VCC from the PSX. To change the macros, have a serial connection which you could plug into the PC and have a couple of commands for setting up the macros. EDIT3: This looks like a nice little board for you: http://hubbard.engr.scu.edu/embedded/avr/boards/avrminiv4/quickstart.html EDIT4: OK, so I lied about assembly and C being your only options on a PIC. Some (like the PICAXE) have a BASIC interpreter. [Edited by - joanusdmentia on April 1, 2008 8:43:01 AM]
  8. Depending on your employment agreement odds are any work you do on that laptop, regardless of when it's done, will be the property of your company. You'd probably only get a slap on the wrist (unless your employer is looking for an excuse to fire you) but it could be much worse. There's really no need to take the risk anyway, you can get Microsoft Visual Web Developer 2008 Express for free and I'd be surprised if you really need anything it doesn't provide for a small business website.
  9. There's a couple of reasons to use initializer lists instead of assigning in the constructor's body: 1) Clarity, it's clearer and more concise that you're perform initialisation and you don't have to worry about prefixing everything with 'this.' if your parameter names are the same as your member variable names (eg: IvVector3::IvVector3(float x, float y, float z) : x(x), y(y), z(z) { }) 2) Performance, assigning in the constructor's body means that the member variables are first default constructed, then assigned (using IvVector3::IvVector3() and IvVector3::operator=(const &IvVector3& v) respectively). With builtin types this won't make any difference, but for custom types with non-trivial/expensive constructors this double initialisation can hurt you performance-wise. There's also reason the not use the initialiser list: 1) You cannot initialise arrays in the initialiser list, the syntax just doesn't exist in C++. 2) If you want to pass 'this' to a member variable's constructor. While allowed you can run into problems if the member's constructor tries to use the 'this' pointer immediately as your object may not have finished initialising yet. 3) If you want to pass a member variable into another member variables's constructor. Member variable's aren't constructed in the order they appear in the initialiser list, but rather in the order they're declared in the class. So again, while this is allowed it's usually a good idea to avoid it. For example: class MyClass { C c; B b; A a; public: MyClass() : a(), b(this), c(b) { } void Func() { a.Func(); } }; This might seem OK by looking at the constructor, but the order of initialisation is really c(b), b(this), a(). C's constructor will be getting passed an uninitialised 'b', and if B's constructor tries to call this->Func() it'll end up calling A::Func() with an uninitialised 'a'.
  10. [SlimDX]Usability questions

    I've not used SlimDX yet, but from what I've read on here it's meant to act as a *very* thin layer between managed code and DirectX. Looking at it from that angle, I'd say they're aiming to keep all functions/constants/etc as similar as possible to the DirectX equivalents. This has a couple of advantages: 1) Someone new to SlimDX but familiar with DirectX should be able to pick it up and run with it without touching the documentation. 2) They can be lazy and point everyone at the DirectX documentation [smile]
  11. War.

    Quote:Original post by Ashkan
  12. Quote:Original post by c_olin So I read that post on getters/setters and it was an informative read. But what if other classes simply need the data? For example a camera class. Would its position/target/up vectors be public? And what about a scene node, surely other classes will need to get their positions and orientations, would their matrices be public aswell? Using getters only is perfectly valid as sometimes internal state needs to be read (how else do you print out a characters stats?). In your case you could provide a getter for the node's transformation matrix but you wouldn't provide a setter (since you don't want someone to be able to set random values in the transformation), you would instead provide functions such as Translate(), Rotate(), etc.
  13. Quote:Original post by frob Quote:Original post by Antheus int getFoo() const { return foo; } void setFoo(int new_foo) { foo = new_foo; }is simply pointless. You didn't achieve any encapsulation, you didn't add any new information, and new functionality, you merely increased the code clutter by a factor of 10. What?! That, by definition, *IS* encapsulation. It allows you to change the internal functionality without changing the interface. We strictly enforce it here, and for good reason. Today, I ended up modifying a few of these. Specifically: Quote:void SetLocked(bool flag) { mIsLocked= flag; } void SetBar(foo f) { mFoo=f; } The difference is you didn't really have accessors in the first place, just poorly named functions. Is the purpose of SetLocked() to set a variable called 'locked', making it nothing more than a pointless accessor (as the name suggests), or is it's purpose to provide the functionality of locking access to something? Just because the implementation only needs to mark a flag internally doesn't make it an accessor, really SetLocked() would be better called Lock() or something similar depending on what it's doing (and similar argument for SetBar(), whatever it actually does). Yes it seems minor, but conceptually it's an important distinction. You don't have accessor functions for x,y,z,w on your vector class, right?
  14. My guess is it's a manifest issue. I've had problems where the manifest created by VS2005 for an application specifies a specific version of the VS2005 C runtime, so when trying to run that on another machine it fails because it can't find the required version (major.minor of what's installed and required are the same, but build number is different). I've even had it fail because the manifest specified 2 different versions of the same runtime DLLs, 1 of which wasn't present on the system. To check if this is what's happening, check in your build directory for the intermediate manifest file and open it in notepad (it's XML). Take a look at what DLLs and versions it requires then check in the C:\Windows\WinSxS directory on your Vista machine to see if that version is present.
  15. IMHO a better way to do this would be to use a std::vector<T> and do the 2D-to-1D index mapping yourself (i=y*w+x). This allows people to take the address of index (0,0) and have a pointer to a contiguous block of memory as they would if they were using a 1D std::vector. If you do this though be wary of your resize() function. std::vector maintains its contents during a resize, so if a user of your class was to expect the same thing and they change the 2nd dimension they'll get a nasty surprise when the value at (5,6) is different before and after the resize.