imi

Members
  • Content count

    51
  • Joined

  • Last visited

Community Reputation

154 Neutral

About imi

  • Rank
    Member
  1. If you don't understand the purpose and structor of classes, I strongly recommend you get yourself a beginners book to C++ and read it from the beginning. Classes (aka user defined types) is probably THE core feature of C++ and without deep understanding of its role in the language, you won't be able to grasp almost any of the concepts from advanced C++ books. My recommendation "Accelerated C++" from Koenig: http://www.amazon.com/dp/020170353X If you really just want the essence and don't care about fluffy nuffy text blabla, then Stroustrup "C++ Programming Language" is what you are looking for: http://www.amazon.com/dp/0201889544 http://www.gamedev.net/columns/books/ lists tons of more references to browse. Ciao, Imi.
  2. Quote:Original post by jpetrie you end up having to work in something that resembles the lowest common denominator of the functional space those environments share -- and that is a very small space. There are changes in the behavior of the "C++" aspect of the language (delete, how templates interact with types, Hm.. I only read about how delete and garbage collecting works for managed objects in CLI. And I have to say, that it convinced me quite a lot. If I had to design a memory garbage collector for C++ and still want to keep the RAII-idiom (which I think is superiour to the try/finally approach advertised by other languages), then I would probably come out with exactly what C++/CLI did: Keeping the destructor that is guaranteed to be called (and as soon as possible) where I can free everything that I allocate. And the runtime take over the left-over memory part at any time in the future. This may not suitable for applications where memory is just as scare as .. say.. file handles, but for the stuff I write so far, this would put less burden on the developer while still enables to write good and robust libraries. So for me it did not look like the lowest common denominator but rather "the combined advantage of both worlds". Said that, I haven't looked at anything else except the destructor semantic. What is with the "how templates interact with types"? Does C++/CLI shun the C++ approach of using templates as a compile-time code generator engine and instead use the (IMHO inferiour) runtime code generation of C#? Ciao, Imi.
  3. Quote:Original post by jpetrie C++/CLI is a pretty horrid language to deal with Why? Ciao, Imi.
  4. Hi, I think I'll look into CLI. It looks hot, right? Any recommendation for resources like "CLI/C++ for intermediate C++ programmer"? Ciao, Imi. BTW: I've no background in Managed C++.
  5. How do the different implementations of your BasicVec differ? Are they different dimensions of a vector? Then you most probably want a compile time error anyway if you use two different vectors in an equation. IVec* v2d = new My2DVector(5,5); IVec* v3d = new My3DVector(2,2,2); IVec* v = (*v2d) + (*v3d); // I bet you would like to get this caught by the compiler If that's your design, you should go for templates (or better, have a closer look into the STL to reuse code). If you only have different implementations for the same mathematical vector (say... one in polar coordinates, an other in carthesian) but both versions could be used together in any equation, then your design is not the worst to start with. In this case, I recommend you put your implementation into a common (and concrete) Vector class. (That's the "adding one indirection solves many problems in computer science" - thingie ;) class MathVector { IVec* impl; MathVector(double x, double y, double z) : impl(new CarthesianVec(x,y,z) {} ... }; MathVector operator+(const MathVector& rhs, const MathVector& lhs) { ... } You should consider making the member "impl" a shared pointer (std::tr1::shared_ptr) so you don't have to implement copy constructor and assignment operator of MathVector. Ciao, Imi.
  6. pointers usefulness

    Quote: Important note: Even though a reference is often implemented using an address in the underlying assembly language, please do not think of a reference as a funny looking pointer to an object. A reference is the object. It is not a pointer to the object, nor a copy of the object. It is the object. Quite misleading, to give such a last sentence in a FAQ like this. I suggest it should be changed. Nobody ever doubt that there is a huge difference between a reference and an object. Just read through this thread to get a couple of the 1001 differences their exist. I have another one: cout << sizeof(double) << " " << sizeof(double&); Edit: That's stupid. Scratch this. If it differs for your compiler, your compiler is wrong. My fault, sorry. Thanks to DevFred for pointing this out. He can spend hours to argue whether references are more like objects or more like pointer. But in fact, they are not the object. Ciao, Imi. [Edited by - imi on March 29, 2010 2:36:42 AM]
  7. pointers usefulness

    Quote: Quote: Imagine that I HAVE to store it on the heap (e.g. because of polymorphism). The question is, should I store it as a pointer or reference? (1) Polymorphic behavior does not require storage on the heap. It requires a pointer or a reference to the polymorphic object, which may be on the stack, et cetera. Yes, you (and Zahlman) are right. All I wanted to say with this sentence is, to set the frame of my question. It's not about polymorphism nor about whether to use value-semantiv for function parameters or when slicing occurs. It's only about "use reference or pointer". I see a lot of advice in the direction of: "Use always reference if possible." (Again: when the question is about "pointer or reference". NOT about value semantic or reference semantic!). Or in more words: "Always use reference if its non-null or has to be initialized. This way you are saving for null-check and can't accidently access uninitialized pointers.". I wanted to questioning this kind of advice. (You didn't said it like that. This is only an example) Quote: (2) You should store it as what is, and refer to it with what is natural and idiomatic for the scenario. ... then you allocate it with new and continue to refer to it as a pointer, because this is a scenario where you have to use a pointer. ... No, the "have to" clause overrides the secondary clause (that's why it is specified first). Since you have to allocate it with new, you have to use a pointer. Then there is probably only a misconception about the use of "have to". My assumption as a reader is that "have to" are about syntactic language restrictions whereas you put semantic meaning like "natural and idiomatic" into it. If you give the advice to "do this and that if you have to and use other thing when possible", people who are thinking like me may use the first case only when they are forced by syntactical language restrictions. Clearly, from a language syntactic point of view, it is not necessary to use pointers together with new (I assume you don't pass std::nothrow). From a "natural and idiomatic" looking point of view, I am with you. ;) (Uhm.. no offense meant here, really. Maybe I can't express myself too good. I am not native english. And I don't want to weigh every word.) Quote: Quote: Edit: My personal feeling is, that in C++ references are usually seen as "don't have to care about memory management. I'd never ever free that one." and pointers as "I have to be careful. This' most probably involve some memory stuff. I better look in the docs whether I have to call delete." So my question could also be rephrased as: Is this feeling true? Basically, but that does not validate your dereference-immediately advice, in fact it does exactly the opposite. Yes, it's an argument against "Avoid pointer. Use references whereever possible" and in favour of "Use references only when people won't be confused about it". And I totally agree that "delete &f" looks scary. (I put it in one scaryness box together with "delete this" ;). But on the other hand, I see clear advantages of using references (precisely because they can't be 0 and uninitialized) and I didn't do C++ for a couple of time and started only recently again, so I wanted to check whether people already got used to using references whereever possible. Ciao, Imi. PS: I probably should have started a new thread for the topic. Sorry for the confusion.
  8. pointers usefulness

    Quote:Original post by jpetrie Quote: I have a question about this topic too, hitting into similar areas: Is it generally wise to immediately convert a pointer to a reference, if I am not going to change it anyway? // why store as pointer? I'm not going to let f to point something else Foobar* f = new Foobar; No, why would you do that? Why not just do Foobar f; or Foobar& f = ... if you need referential semantics? Uh, I think I've been misunderstood. I don't want to tackle the question of whether I can store a value on the stack or on the heap. Imagine that I HAVE to store it on the heap (e.g. because of polymorphism). The question is, should I store it as a pointer or reference? Quote:Original post by jpetrie Quote: Foobar& f2 = *new Foobar; This is a terrible idea in general. You cannot delete f2, you must remember to take it's address and delete that, and there is a good chance that (if you're using pointers and dynamic allocation properly) the delete site will be far enough from the allocation site that the variable will look entirely like a reference and thus you will forget. Well, of course the delete would look like "delete &f2;". And the second part about the distance of delete is true for plain pointers as well, so I don't see any impact on the question "reference or pointer" here. Quote:Original post by jpetrie All the advice regarding pointers can be summed up quite neatly: use pointers (and their associated concepts like dynamic allocations, et cetera) when you have to, and use something else at all other times. But that is exactly the recommendation to use a reference and not a pointer. A reference would do in my case, as 1) I don't want to change the location my object points to and 2) it can't be 0 anyway. Maybe I rephrase the question a bit to steer to my original problem: References are like pointer, except the can't be 0 and are always const (the reference itself - not the object it referrs to). So a lot of people recommend 'Use references, if you have objects that can't be 0 and won't change anyway'. (e.g. Scott Meyer, Effective C++) This recommendation would include, that you should derefer any "new Foobar" immediately, if you don't plan to change the variable which receive the object pointer/reference. (And if you don't pass nothrow). Hence, you should prefer "Foobar& f = *new Foobar;" instead of "Foobar* f = new Foobar;". By the way: Another thing are for example object factories. If the factory can't return 0 then - following the above advice - I should strive to return references and not pointer. "Foobar& createFoobar();" instead of "Foobar* createFoobar();" ? So my final question is: Is the recommendation above really a good idea, or should I prefer pointers in some cases just because they feel "more normal"? Ciao, Imi. Edit: My personal feeling is, that in C++ references are usually seen as "don't have to care about memory management. I'd never ever free that one." and pointers as "I have to be careful. This' most probably involve some memory stuff. I better look in the docs whether I have to call delete." So my question could also be rephrased as: Is this feeling true? Or see C++ people references as: "Ah, a non-null const pointer. Let's look in the docs whether I have to free that." and pointer as: "Ah, a pointer. I better check for null and look in the docs whether I have to free that."
  9. pointers usefulness

    I have a question about this topic too, hitting into similar areas: Is it generally wise to immediately convert a pointer to a reference, if I am not going to change it anyway? // why store as pointer? I'm not going to let f to point something else Foobar* f = new Foobar; .. // should I strive for this, every time I want something like "Foobar* const"? Foobar& f2 = *new Foobar; Or does it just look too weird and uncommon? Ciao, Imi. PS: I hijacked, because I think it might interest the OP as well..
  10. C++0x question

    Quote:Original post by cache_hit int mystery(int n) { double sqrt5 = sqrt(5.0); double phi = (1.0 + sqrt5)/2.0; double numerator = pow(phi, (double)n) - pow(1.0-phi, (double)n); return (int)(numerator / sqrt5); } Nice one :-D. And you're right. My head explode when I think how this should be meaningfull for negative or complex numbers. Ciao, Imi.
  11. Quote:Original post by TxkunThere is an advantage if you can store all your particles and their processing on the GPU using a vertex shader. No locking of buffers, no CPU doing stuff on them. Not all particle systems can be done in this way, but can be a nice thing to have. Shader programming is something on my Todo list, but actually I plan to use DirectX10 for this (in my next project. Promise! ;-). As I read somewhere, DX10 introduce some metalanguage for shader programming, so I don't have to learn the strange nvidia-assambly, is that right? Still, wouldn't it give me an time advantage if I edit everything already in an Vertexbuffer-like memory format and do just a memcpy during render()? Or is this advantage so puny and laughable compared to the time it takes to sync & lock the buffer, shovel this stuff over to the GPU inside memcpy and unlock everything? (I didn't do profiling yet.. storing it in FVF-compatible structs just seemed natural to me. Allthough now, I regret it a bit, as I can't work with my helper classes like Vector..) Edit: While writing this, I recognized that that's not true. My helper don't have virtual functions, so nothing prevents me from just storing them as data instead of the separate floats. So.. nevermind. ;) Quote:Original post by Dom_152 Couldn't you just initialise your particles normally (All bunched around the emitter as you put it) and then just add to their their position: Velocity * 5 seconds? Maybe I'm missing something here. Yea, that's where I started. Then I spot that I was missing the fact, that not all particles live for 5 seconds, but they live for randf()*5 seconds (random from 0 to 5). So I would get the particles a lot wider spread out than they would be normally. It would be as if the emitter spit out only 5-second-living particles for the first 5 seconds of his existence.. Ciao, Imi.
  12. Hm.. thinking of it, I could eliminate the "maxLife" instead and only store the life, velocity and position. I don't see a huge advantage yet of *not* storing the position yet, as I need this anyway when it boils down to put values in the vertex buffers. At the moment, I keep the position storage in exact the format of the vertex buffer, which means I just do a memcpy in my render-code to copy the stuff into the vram. I would loose this possibility if I calculate the position "on the fly", right? Or did I get your idea wrong? (I'm kind of new to all this stuff) Ciao, Imi.
  13. Quote:Original post by tori Why not just implement a classic particle system and hide the actual particle geometry until its elapsed life is greater than 5 s? Well, I could also just loop the update a couple of times with 100ms each until they are "advanced enough" or something similar. But actually all this sounds terrible hackish for a problem where I think I am just like one missing minus away from solving. ;) It surely must be easy to start an particle animation "from the middle" instead of hiding it and dummy-simulating for a couple of seconds. Especially if its that easy. It's not that I have hundrets of cross dependencies to other variables here ;) Ciao, Imi.
  14. Ok, sorry - described the wrong effect (made a typo). It's not crowded at the emitter, but spread too much over the place. Maybe I let a bit of code speak, C++ can probably explain things better: // initialization Vertex() : x(randf()*gGame->width()-70) , y(500) // that's the original "position" , z(0) { } ... FireParticle() : maxLife(randf()*5.0f) // my particles "maxLife" , life(maxLife) , velocity(randf()*70, randf()*randf()*60-70) { } // That's the loop I use to spread the particles at startup for (size_t i = 0; i < fire.size; ++i) { FireParticle::Vertex& v = fire.vertex[i]; // here, I move the particles into the future FireParticle np; // gets random life and velocity v.x += np.life * np.velocity.x(); v.y += np.life * np.velocity.y(); } Ciao, Imi.
  15. Hi, I have a particle engine that should simulate a fire effect. I model it with 8192 flame particle that get emitted from a source. They have a position, a velocity and maxLife until they are respawn. Maxlife is set to randf()*5, velocity=(randf()*70, randf()*randf()*60-70). This way, they are living for 0-5 seconds flying to the up-left in a random fashion. Now, my problem is the "position". I don't want them to crowd at the emiter at startup. So I want them to be "like 5 seconds in the future", so the animation starts by looking as if it already ran for 5+ seconds.. But when I try to figure out how I have to initailize the position, I get a headache.. So that's what I figured: 1) maxLife will be still the same random distribution - regardless how many time I go ahead, so no change here. 2) velocity is also a random pointer that doesnt change its distribution, so no change here either. The initial random stuff should work as well for a distribution "as if 5 seconds have passed". 3) position is random place from the start until maxPos, where maxPos is the place a particle can go if it lives for 5 seconds with the maximum velocity. However, the distribution is not uniform distributed random, as I am multiplying two random variables here. Instead, it is rand(maxLife)*rand(maxPos) or in my syntax above: "randf()*5 * randf()*70" (for x coordinate) and "randf()*5 * randf()*randf()*60-70" for y-coordinate. I tried, but it looks still like a burst of particles (not every particle, but noticable a lot) that are coming out of the emitter at startup. Is there a mistake in my reasoning? :-( Ciao, Imi.