Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

679 Good

About TDragon

  • Rank
    Advanced Member
  1. TDragon

    understanding warnings

    [google] C4312. MSDN, the definitive reference for Microsoft's products, shows up in the second link.
  2. TDragon

    Graphic Engines

    CorelDRAW X3? ZBrush? Ogre? POVRay? Acrylic canvas and paint? "Messing around with graphics" covers a wide range of topics. Are you interested in creating graphics (digitally, I assume), in displaying graphics (2D or 3D? Realtime or static?), or in writing graphics tools to help other people do the above? Please be more specific.
  3. TDragon

    deleting pointers in c++

    Quote:Original post by Exilberliner I thought when I'm freeing the allocated memory every other pointer, pointing to the same place is set to 0 or is causing a programm-crash or something. Definitely not the case. As long as you're using C++'s built-in pointers, all you can count on after deleting the memory a pointer points to is that you shouldn't access it anymore. Quote: So my Question is: How can I make class Nr3 know that the targeted Object should have been deleted. If class Nr3 truly needs that kind of information, I recommend using Boost's weak_ptr. However, in this particular case (and in every case), you should consider carefully whether a Nr3 object should have a persistent pointer to data "owned" by your linked list, or should merely query that list for a temporary (local variable) pointer to data only when it needs it.
  4. TDragon

    deleting pointers in c++

    Quote:Original post by Exilberliner So now, when I'm deleting one of the list-entries which was targetet by class nr3 I'm still getting the value. Is this your problem? What exactly do you mean by it? Please be more specific.
  5. Aside from a few minor errors, Julian90 pretty much has it. Your problem boils down to the fact that the compiler needs two sets of information at compile time in order for your unary_predicate template function to work: the type of the function pointer, and the actual function address. Template argument deduction only works with the arguments to templated functions, but function arguments exist in the run-time domain rather than the compile-time; therefore, your options boil down to either passing the function pointer as both a function parameter (to obtain its type at compile time) and a template parameter (to obtain its address at compile time), or passing the type and address of the function pointer in separate template parameters. Had I the choice, I'd choose your current method of passing both in separate template parameters, but I have included some working code below showcasing the alternative. It's identical in principle to Julian90's, and compiles without error (using GCC 3.4.5). /// For testing purposes typedef int Variable; /// unary_predicate_type is the return type of our helper struct's get() typedef Variable* (*unary_predicate_type)(Variable*, Variable*); /// Your templated unary predicate function template< typename Context, typename PredInArg, bool (Context::*predPtr)(PredInArg) const > Variable* unary_predicate(Variable* self, Variable* args) { // do your stuff return 0; } /** The unary_predicate_helper struct provides persistence of the function * pointer's type data; it is instantiated by the get_unary_predicate function */ template< typename Context, typename PredInArg > struct unary_predicate_helper { /** This member function uses its parent struct's templated type data plus * its own templated value data to instantiate the actual * unary_predicate function */ template< bool (Context::*PtrValue)(PredInArg) const > unary_predicate_type get() { return unary_predicate< Context, PredInArg, PtrValue >; } }; /** The unary_predicate function makes use of the compiler's template argument * deduction for functions to instantiate a unary_predicate_helper struct with * the required type data */ template< typename Context, typename PredInArg > unary_predicate_helper< Context, PredInArg > get_unary_predicate(bool (Context::*PtrTypeDeduce)(PredInArg) const) { return unary_predicate_helper< Context, PredInArg >(); } struct test { bool somefunc(int somearg) const { return false; } }; int main() { // just getting the address of the function unary_predicate_type pass_me_to_api = get_unary_predicate(&test::somefunc).get< &test::somefunc >(); // actually calling the function Variable v1, v2; Variable* result = (get_unary_predicate(&test::somefunc) .get< &test::somefunc >())(&v1, &v2); return 0; }
  6. Quote:Original post by ViLiO As for the const char[15]'s to LPCWSTR conversions, you can either disable unicode (in your project settings), ... QFT. In VS 2005, this appears as the "Use Multi-Byte Character Set" option.
  7. Quote:Original post by Mizipzor Yes I could do that, but then it would loop until f is equal to begin(), but not including begin(), which I want. ...Are you serious? while (f != l.begin()) { --f; cout << (*f) << endl; }
  8. Quote:Original post by Mizipzor Do I have to do something extra in order for that to work? Not in GCC, but then it's obvious you aren't using GCC. Have you tried just decrementing the same iterator you already have? (Works for me.) list<int>::iterator f; for(f = l.begin(); f != l.end(); f++) { cout << (*f) << endl; } for(; f != l.begin(); --f) { cout << (*f) << endl; }
  9. Quote:Original post by Julian90 as well as what Illco said any static or global variables will contribure to the size of the executable. While this is true, static and global variables probably contribute the least to the size of any set of compiled code. To optimize for size, ensure that extraneous symbols are not being included. I'm not as familiar with Microsoft's compiler as I am with GCC, but I suspect this will involve turning debug information off and any available size-related optimizations on, and linking with the redistributable version of the CRT (rather than the debug version). Make sure _DEBUG is not defined, and NDEBUG is. EDIT: The fact that this is a static library we're creating here apparently didn't entirely permeate my gray matter the first time through. A static library is merely a collection of object files; no linking has occured yet and so advice about libraries and runtimes doesn't apply. Hope that helps, JohnE / TDragon [Edited by - TDragon on December 30, 2006 10:41:35 PM]
  10. TDragon

    Starting a graphics engine

    Quote:Original post by mgoldsum I want to try to build a somewhat simple graphics engine (using OpenGL) that I can use for a few games that I am planning on making. The problem is I dont know exactly where to start and what stuff needs to be in it. The best way to start something is, in fact, to simply start it. Particularly the case when you don't have an overarching view of what the structure of your code should be, it might be best for you to dive in, starting with what you know and working outward from there. Supplement your work with a book or two on game programming if at all possible, and don't miss GameDev's articles -- invaluable. Seeing how someone else did it will give you an idea of the best way to do it. As far as creating a game engine goes, I'd advise that you not try to build a complete reusable engine by itself before starting these games you're planning -- after all, how would you know everything your engine needs to provide to the game? You'll find it easier and more gratifying to build the engine and the game in parallel. Once you're ready to move on to the next game, you'll be able to clearly distinguish the parts of your code that are reusable in it, which belong in the engine, from the parts that are specific to the previous game. Quote:If anyone can help me and let me know what functions to start with and what some good ways to store things are I would be very happy. Prefer the standard library over anything you might write yourself. Be familiar with the strengths and weaknesses of the various data structures such as binary trees (std::map), linked lists (std::list), and arrays (std::vector). For each storage problem, the method for data access and the speed of data access will determine the appropriate structure. Hope that helps, JohnE / TDragon
  11. TDragon

    compiler problems

    That depends on what you mean by compiler, and what you mean by good. Seriously. By "compiler", do you mean "IDE"? Dev-C++ is one of several IDEs designed to use the MinGW compiler. I don't like Dev-C++ as an IDE very much either; I use Visual Studio and Code::Blocks. Or do you mean that you have trouble overcoming the errors that the compiler gives you when you try to compile programs you've written? This happens to all of us, even the best of us, but there are a lot of good practices and techniques out there for programming. A good reference book will help you out of many situations, and Google and the good folks here at GameDev make good backup. Do you have issues with the actual design of the MinGW compiler? It's a Windows port of GCC, the GNU compiler collection that is used on nearly every Linux OS distribution available (as well as many other OSes), but you might find Microsoft's, Watcom's, Intel's, or Digital Mars' to be friendlier. It's all a matter of what you need, and what you want. Cheers, JohnE / Twilight Dragon
  12. Such a thing does indeed exist. The Boost C++ libraries' implementation calls it a weak_ptr, and it is a "Non-owning observer of an object owned by shared_ptr", shared_ptr being your standard smart pointer. Whether and how you use this "weak" smart pointer depends on your language and the needs of the situation.
  13. TDragon

    Ownership of Objects on the Heap

    Quote:Original post by Zahlman Sometimes the most logical thing is to use smart pointers, ... This is why smart pointers are often called for. Smart pointers were the first thing that came to my mind reading through your post, GenuineXP. Granted, I haven't taken the time to fully understand your problem, and also granted, smart pointers are not the solution to every ownership problem. I think, however, if you start referencing your Sequences with smart pointers, everything else should fall into place. As far as smart pointers go, your options are pretty much std::auto_ptr, boost::shared_ptr, or creating your own implementation. std::auto_ptr has some sticky semantics but it comes with your compiler; boost::shared_ptr works like a charm but has internal Boost dependencies (i.e. you can't just copy shared_ptr.hpp), and rolling your own takes work, time and debugging but can be crafted to perfectly fit your situation and is a great learning experience. Hope that helped, JohnE / Twilight Dragon
  14. TDragon

    DirectX and MinGW

    Possibly dx80_mgw.zip, from http://alleg.sourceforge.net/wip.html? This is not by any means the full SDK, but I expect it'd be enough to get you going.
  15. I received the package two days ago, just a few days after receiving a shipping confirmation email and less than two weeks from signing up for the offer. These 500.13 errors are killing what used to be a fantastic site.
  • 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!