|
Fabulous. I'll get to reading. Thank you very much!
|
# ? Jun 17, 2009 00:57 |
|
|
# ? Jun 7, 2024 01:16 |
|
Ignore him. http://codepad.org/zwtgx7UU
|
# ? Jun 17, 2009 01:01 |
|
Mustach posted:Ignore him. Iterators are awful. And he never mentioned that any of the other array classes met STL container requirements.
|
# ? Jun 17, 2009 01:04 |
|
Thanks, Andrei.
|
# ? Jun 17, 2009 01:05 |
|
Mustach posted:Thanks, Andrei. Oh also, your code is not appropriately generic since my example allows you to take advantage of overload resolution to do the following: code:
|
# ? Jun 17, 2009 01:08 |
|
Thanks, Larry.
|
# ? Jun 17, 2009 01:13 |
|
Iterators are really a pain to work with, and at least other languages encapsulated the begin and end iterators into one thing, though they almost universally ignored anything but ForwardIterators. One day, I will write the STL++, which will use ranges and concepts and just generally be totally k-rad. Also it will have matrices and trees and and and a pony!! Avenging Dentist fucked around with this message at 01:26 on Jun 17, 2009 |
# ? Jun 17, 2009 01:21 |
|
floWenoL posted:If your intention is to work with an integer and a double containing the same integer value, a union is most definitely not what you want. No, that wasn't my intent. I've got a class my predecessor wrote that stores one of either a numeric variable or a std::string, but instead of using a union (since you can't put std::strings in a union I guess) he just made one member variable for each type (int, short, char, long long, unsigned variants, and float/double) and zeroed out all the others when one got set, with one get/set for each type. Sort of annoying to work with, so I was panning for ways to rewrite it.
|
# ? Jun 17, 2009 15:07 |
|
Yikes.Ledneh posted:(since you can't put std::strings in a union I guess)
|
# ? Jun 17, 2009 15:55 |
|
Dijkstracula posted:Yikes. Yeah, it's not pleasant, given how irritatingly coupled this stupid thing is with the rest of the project. (not that I have any right to bitch, I've written far worse ) Thanks for the suggestion on using a pointer instead. I also have had boost::any and/or boost::variant mentioned, but I know nothing about those so I guess it's readin' time. There's so much I don't know
|
# ? Jun 17, 2009 17:16 |
|
What's the class being used for? It sounds like there's gotta be a nicer way to do that.
|
# ? Jun 17, 2009 19:47 |
|
It's used for reading bits from a file buffer, with the type of data represented by those bits being known in advance (so we know bits 16-31 represent a 16 bit integer, 32-105 is a string of ascii characters, so on and so forth). I thought about templatizing the class in question, but later there're vectors of objects of this class, and so far as I know you can't stuff a Foo<int> into a vector< Foo<float> >, for example. (Unless there's some trick that WOULD let me do that.) Closest I've been able to figure so far is paring it down to three types--int64, float64, and string--and three get/sets. Which is only a less lovely solution and it bugs me that I can't think of anything else
|
# ? Jun 17, 2009 20:09 |
|
Re: unicode, I've spent some time the last few days implementing a tiny, working UTF conversion library and I'm interested in hearing some thoughts on the design/functionality. Again, this is something I'm writing primarily for my own needs, but if people are interested I could kick it into better shape and release it at some point. The library currently concerns itself solely with conversion; it ~gives no poo poo~ about normalization, collation et al. The central notion is a templated transcoder iterator and several charset codecs, all exposed through views that model the range concept. Basically, to convert from charset X to Y, you can just write Y_view_of<X_source>(iterable-range) and get an iterable range that performs lazy, on-the-fly conversion with no dynamic allocation and also transparently handling the number of resulting characters. code:
Any thoughts?
|
# ? Jun 17, 2009 20:46 |
|
Ledneh posted:since you can't put std::strings in a union I guess
|
# ? Jun 17, 2009 20:47 |
|
For some reason fstream isn't doing what I want it to do. I want it to add the string "0:1:2232:pirt" at the beginning of a file I open in truncate mode. We have:code:
Substitute std::cout for m_file above, it prints fine. What's special about "0:", and where is it documented?
|
# ? Jun 18, 2009 02:53 |
|
This works fine. What are you using to look at the file?
|
# ? Jun 18, 2009 02:57 |
|
Chuu posted:What's special about "0:", and where is it documented? Nothing. You are probably using a stupid editor. Open the file in a hex editor or something.
|
# ? Jun 18, 2009 02:57 |
|
The Red Baron posted:I'm currently working on getting support for dynamically chosen sources without this impairing inlining capabilities for non-dynamic sources. Here's what I did. You might want to add in block encoding/decoding for rt_facet so that vtable lookups don't murder you (you'd hope that consecutive calls to the same virtual function would be optimized, but I doubt it). ct is short for "compile-time" and rt is "runtime": code:
|
# ? Jun 18, 2009 03:42 |
|
Lets say I have a file descriptor array (fd is used as an index in the array). I can guarantee that I won't be writing to a specific fd from different threads. Is it safe to use that table from multiple threads without locking?
|
# ? Jun 18, 2009 08:29 |
|
Just because you won't be writing to a specific fd more than once at the same time doesn't mean the array won't be modified by more than one thread.
|
# ? Jun 18, 2009 10:39 |
|
Every thread has it's own set of file descriptors and they are used only within that thread. Multiple threads can use that same array, but naturally every fd is different and belongs to only one thread.
|
# ? Jun 18, 2009 12:59 |
|
Rapsey posted:Lets say I have a file descriptor array (fd is used as an index in the array). I can guarantee that I won't be writing to a specific fd from different threads. If the "array" is truly an array and not some kind of container like a vector, then yes, you can access it without locking so long as you are sure that only one thread will ever try to access any single array element. Arrays are just contiguous allocations of multiple values, so if two threads never use the same array index, the only thing shared is the address of the beginning of the array, which is constant. If, however, you are using some sort of managed container (such as a std::vector) then this may or may not be safe depending on how you use it, and what guarantees are provided by the container. For example, if one thread performs an action that causes a vector to re-size, it may invalidate an iterator held by another thread.
|
# ? Jun 18, 2009 13:22 |
|
Does anyone have a good resources on thread and how to use them? I've never done a whole lot with them and I find myself in the need of one Should I use a separate library or just the standard thread stuff that comes with VS 2008?
|
# ? Jun 18, 2009 22:50 |
|
Sweeper posted:Should I use a separate library or just the standard thread stuff that comes with VS 2008? What standard thread stuff? TR1?
|
# ? Jun 18, 2009 22:53 |
|
Avenging Dentist posted:What standard thread stuff? TR1?
|
# ? Jun 18, 2009 23:15 |
|
Download TR1.
|
# ? Jun 18, 2009 23:23 |
|
Avenging Dentist posted:Download TR1.
|
# ? Jun 18, 2009 23:31 |
|
Sweeper posted:I downloaded it with the feature pack for VS 2008, is that the right place to get it from? I'm pretty much a giant noob when it comes to this stuff. Probably. I just use the Boost implementation.
|
# ? Jun 18, 2009 23:32 |
|
Avenging Dentist posted:Probably. I just use the Boost implementation. Do you have a link to any good resources on multi threading before I go scour the internet in hopes of finding something useful?
|
# ? Jun 18, 2009 23:43 |
|
Threading is trivial. Synchronization is hard. The Little Book of Semaphores discusses (one way of) synchronization.
|
# ? Jun 19, 2009 00:14 |
|
Avenging Dentist posted:Threading is trivial. Synchronization is hard. The Little Book of Semaphores discusses (one way of) synchronization.
|
# ? Jun 19, 2009 00:30 |
|
What is going on here? I wrote a bitmap scaler and it reads the colors of the pixels to draw from the bytes of the bitmap it loaded. code:
Is this some kind of bizzaro compiler optimization gone horribly wrong? This only happens under Release. slovach fucked around with this message at 00:04 on Jun 20, 2009 |
# ? Jun 19, 2009 23:52 |
|
Be careful when using bitshifts. The order of precedence they use CAN be weird. Put the stuff in >> completely inside of parenthesis ( ) See if that helps slovach.
|
# ? Jun 20, 2009 02:31 |
|
I know it's from the previous page, but:Otto Skorzeny posted:Why are you looping through your array indices starting at 1 instead of 0 Post you quoted posted:The top/bottom rows and side columns of Ex and Ey are to remain unchanged.
|
# ? Jun 20, 2009 21:50 |
|
slovach, can you post some code? Give an example of a value that you assign, and the garbage that get written in, and the code that does it? There's not much to work with here.
|
# ? Jun 20, 2009 23:29 |
|
Dijkstracula posted:slovach, can you post some code? Give an example of a value that you assign, and the garbage that get written in, and the code that does it? There's not much to work with here. In the end it turned out to be my alpha blending routine that I tried to rewrite in assembly that mysteriously dies under Release. I thought the compiler doesn't touch inline asm? edit: And I figured it out. More like debug was actually saving me from my own mistake. slovach fucked around with this message at 06:09 on Jun 21, 2009 |
# ? Jun 21, 2009 05:58 |
|
I was trying to create a bunch of MyObj objects on the heap, and push pointers to those objects into a vector<MyObj*> vec . I was (incorrectly) doing this by iterating: code:
code:
I *think* what was happening was that new was only creating temporary objects, so at the next iteration it went looking for another block of heap memory of the same size and found the same block as with the previous iteration. Is my guess right? Edit: doing this didn't actually fix anything. See my post three posts down. DoctorTristan fucked around with this message at 17:16 on Jun 22, 2009 |
# ? Jun 22, 2009 15:53 |
|
DoctorTristan posted:I was (incorrectly) doing this by iterating:
|
# ? Jun 22, 2009 16:14 |
|
DoctorTristan posted:I *think* what was happening was that new was only creating temporary objects, so at the next iteration it went looking for another block of heap memory of the same size and found the same block as with the previous iteration. Is my guess right?
|
# ? Jun 22, 2009 16:23 |
|
|
# ? Jun 7, 2024 01:16 |
|
Okay, the change I posted above didn't actually fix the problem, just moved everything around a bit, so I'm back to where I started.Mustach posted:What was in the for? No for, just a sequence of method calls that run a few test cases (sorry if this is an incorrect usage of `iterating'). The whole thing's actually wrapped up in several layers of classes and structs; I simplified a lot of this above since I assumed it wasn't important, but what's actually going on is the following: Big templated container class I'm pushing stuff into, with irrelevant members snipped out. The console output I've included comes from the member function at the end of this block (sorry for the very long names): code:
code:
code:
code:
code:
edit: table breaking DoctorTristan fucked around with this message at 17:47 on Jun 22, 2009 |
# ? Jun 22, 2009 17:14 |