- Random Device initialization is platform dependant? - 1 Update
- User-defined access operator? - 1 Update
| ram@zedat.fu-berlin.de (Stefan Ram): Dec 08 11:13PM >OK, but that was very far from clear. I tried, wherever possible, to >show general solutions in the classroom so it seemed to me you might be >showing this because you think it is generally a good idea. ::std::rand can be a good solution when one is writing a simple game or simulation for fun. But in my course it serves first and foremost as an example of a library function. The section where it is used is *not* about random numbers, but about how to call functions from the standard library. (Maybe I should have made this clear earlier.) However, since participants kept asking about how to make the obvious correlations disappear, I am showing it to them. And ::std::srand and ::std::time also serve as examples of functions. Each of these functions has specific properties: ::std::rand returns a value and has an effect and has no parameter ::std::srand does not return a value; it has an effect; it takes an argument; it seems to share a state with ::std::rand ::std::time returns a value, but this value is not determined by the argument's value; it does not have an effect The section is about library functions and their respective properties (such as determinism, results, parameters, and effects). It does intentionally *not* discuss random numbers deeper than necessary; the point of teaching is to show how to call (use) functions from the library. "The key to understanding complicated things is to know what *not* to look at and what *not* compute and what *not* to think." -- Gerald Jay Sussman, 1986 The key to teaching the basics of how to call functions from the library to absolute beginners is not to distract the course participants with details about random number generators. >One should not used rand if it's that bad. There's nothing wrong with >using it if your library has a good implementation. Each algorithm has its specific properties, and one algorithm might be good for cryptography, while another one might be good for Monte-Carlo simulations, and another one might be good for the first steps of beginners. >obvious correlation with a non-obvious correlation. In some situations >the latter is more dangerous because it might hide the use of bad >generator. That's a good point indeed, but for a section about random-numbers. In my beginner's course ::std::rand appears in the section about calling functions from the library and serves as an example of a library function. And *sometimes* one just wants to make the obvious correlations disappear. |
| bitrex <bitrex@de.lete.earthlink.net>: Dec 08 05:53PM -0500 Suppose I have a class wrapper which allocates POD objects of some type T to a memory pool. And I have a static factory function which takes a temporary object from the stack and a reference to the pool, and returns a user-defined type alias for that class, say pool_object_t<T>, which has a member variable that holds a pointer to the newly allocated block of memory in the pool on the heap containing the persistent object. I know I can define a conversion operator which will allow me to use this type as say, the argument to a function which is expecting type T. I also know that I can overload the * and -> operators to work with the underlying pointer. Am I correct in understanding that there's no way to treat this pool-allocated wrapper type as if it were a "regular" object instantiated on the stack? That is to say, something like: struct MyPODStruct { int x; int y; int z; } MemoryPool<MyPODStruct> pool; pool.resize(10); //create 10 blocks on the heap big enouh to fit the struct auto obj = pool_object<MyPODStruct>::make_pool_object(pool, MyPODStruct()); obj->x = 7; //okay, if operator "->" is appropriately overloaded void my_func(const MyPODStruct& obj) { ... my_func(obj) //okay, if user-defined conversion operator for that obj.x = 7; //not okay, pool_object_t<MyPODStruct> has no member named "x" Maybe I should just make the pool_object_t more like a smart pointer, and return managed references to the blocks on the heap, rather than try to return wrapped objects by value? |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment