|
aViR posted:That approach should work, and yes you would cast the pointers to unsigned integers, do your math, and cast back, e.g. (untested): There's no need for any of those casts.
|
# ¿ Oct 9, 2008 20:16 |
|
|
# ¿ Apr 29, 2024 18:17 |
|
Ledneh posted:That reminds me. For some reason, as soon as I started my sun studio 12 project it allowed me to do just that: put template class declarations in a .hpp and their implementations in a .cpp that includes the .cpp, just like a normal class. And it worked fine. It was only later that I remembered that this has never worked for me before and I still haven't found out what I did to the project settings to make it go Ok, I've re-written this post several times now, and I think I've got the stupid stuff straight in my head. What I was finding in my test case was just the effects of the stuff I linked below. If you have implemented the template in a cpp file, and *used* it in that same cpp, then for all the combinations of templates parameters that you have used, it will be available to the rest of the code. If you try and use it for a combination not used in that cpp file, you will get unresolved externals. You could however, implment it in another cpp file with those other template paramters and everything would work fine for them, and you could have totally different implementations, I assume this just comes from template specialisation. Now, what's slightly more odd, and I'm less clear on, was that Visual Studio lets you implement the template multiple times, using the same template paramters, and it wont give linker issues about multiply defined symbols, though it only seems to use one of the implementations. EDIT: duh, this is the normal usage case, except normally they would all be defined with the same code. EDIT: Jesus, I'm just getting more and more convinced that VS is just doing weird and crazy stuff. You will only be able to use the functions you have actually called, as otherwise it won't have actually compiled them into the translation unit. So, if you really want to use this crazy way of making templates, use explicit instantiation, doing it any other way seems like a lesson in pain. In conclusion, I'm pretty sure what I originally typed was correct, you should only be able to use templates if they have been defined in the same translation unit, unless you use explicit template instantiation. Explicit Template Instantiation: http://publib.boulder.ibm.com/infocenter/lnxpcomp/v7v91/index.jsp?topic=/com.ibm.vacpp7l.doc/language/ref/clrc16explicit_instantiation.htm digibawb fucked around with this message at 00:10 on Dec 10, 2008 |
# ¿ Dec 9, 2008 23:09 |
|
Subotai posted:I came across this in some code today and wondered if it actually does anything? It should make no difference at all.
|
# ¿ Dec 10, 2008 00:20 |
|
Avenging Dentist posted:The second cast is superfluous, but the first one allows addressing at the byte level for the struct. He asked whether there was any point in casting back and forth, I was just answering that question Avenging Dentist posted:MSVC defers member function instantiation of template classes until they are referenced. I don't know if it actually violates the standard, except in that it won't diagnose errors of non-referenced methods, but eh. I'm not sure if it breaks standard compliance either, but I actually like the "feature". It can be handy for having things where the code for a specific function will only work for a certainly type, or class of type, say a pointer, but you will only use that function for that type/class of type. Having said that, I have to deal with 4-5 different compilers at work, so don't get to make use of it, but eh, whatever. digibawb fucked around with this message at 00:42 on Dec 10, 2008 |
# ¿ Dec 10, 2008 00:38 |
|
Avenging Dentist posted:Well, here's a good reason why not to do this: segfaults code:
EDIT: Obviously the parameter passing could be handled better, likely with some boost trickery, but you get the idea. digibawb fucked around with this message at 23:29 on Dec 11, 2008 |
# ¿ Dec 11, 2008 23:24 |
|
Avenging Dentist posted:The semantics of new/delete are among my least favorite parts of C++, and except for placement new (which has awful syntax in my opinion) Agreed. I re-wrote all of our memory allocation handling earlier on this year so we could use a custom allocator for everything, and it was a lesson in pain. Not helping matters were that MFC has a nice bug where they new stuff in one place and call free on it later. wxWidgets wasn't a huge deal better, they have a nice part in their style guide which says to not do any allocation during static init, so that people can use custom allocators easily, then they go ahead and just break that rule left, right and centre. *shakes fist* EDIT: Oh, and the new call in MFC is in a header, so you pick up that call yourself, but the free is in the dll... grrr
|
# ¿ Dec 12, 2008 01:37 |
|
hexadecimal posted:
If you didn't dereference this in bar, then on many compilers, you would get away with doing the call with no harm done. However, it's obviously not good practice, as it's compiler specific, but most compilers (read: the 4-5 that I use anyway)behave the same way for this case.
|
# ¿ Dec 15, 2008 17:38 |
|
Staggy posted:Alternatively you could use a Switch-Case. Yes, let's teach people the for-case paradigm. You'd be better off writing a function which deals with printing the statement, and fetching the input, then calling it 5 times, either via a loop and an array of ints, or just by calling it 5 times explicitly. EDIT: or, since it's a relatively small amount of logic, just shoving it inline with the array digibawb fucked around with this message at 20:57 on Jan 11, 2009 |
# ¿ Jan 11, 2009 20:54 |
|
honeymustard posted:Tell me more? Our programming lecturer guy seems to encourage switch-cases. There's nothing wrong with switch-case, it's awesome. Doing it inside a loop based on the iterator is just silly however (in general anyway). With a small case like this it might not look all that crazy, but once you go down the road, you get to places like http://thedailywtf.com/Articles/The_FOR-CASE_paradigm.aspx
|
# ¿ Jan 11, 2009 21:01 |
|
schnarf posted:I'm betting the union isn't 4 bytes as you'd expect. How much you willing to bet? It will be the vtable, as has already been covered.
|
# ¿ Apr 7, 2009 19:58 |
|
Use a const_iterator for the const object.
|
# ¿ Apr 9, 2009 14:30 |
|
You can declare it inline in the implementation file as long as that is the only place you use it, as it won't be visible to the linker.
|
# ¿ Apr 24, 2009 13:09 |
|
I have used Memory Validator ( http://softwareverify.com/cpp/memory/index.html ) many times with great success. It isn't free, but there's a 30 day trial iirc. The interface is rather clunky, but if you can get past that, it has a lot of good features.
|
# ¿ May 6, 2009 19:45 |
|
fprintf writes to a file, you haven't given it a file to write to (though I suspect you wanted printf, not fprintf) digibawb fucked around with this message at 20:18 on Oct 27, 2009 |
# ¿ Oct 27, 2009 20:16 |
|
Red Alert posted:can't you use sizeof? On what exactly?
|
# ¿ Nov 23, 2009 11:29 |
|
Lexical Unit posted:I have never programmed in Windows before and Visual Studio is making me feel dumb. Where is the dll placed? The working path is likely different when running from visual studio.
|
# ¿ Jan 14, 2010 21:11 |
|
If you add to a pointer, you offset it by (a multiple of) the size of the type it points to, not by the value you added. So q + 16 will be a memory address 16 * sizeof( int ) bytes further along, not 16 bytes further along. When you shove the pointer into an int, and add to the int instead, all you are doing is increasing the value of the int. (Ignoring the fact that shoving a pointer into an int isn't the best thing in the world to be doing.) digibawb fucked around with this message at 18:35 on Feb 6, 2010 |
# ¿ Feb 6, 2010 18:32 |
|
cronio posted:XNA is a *lot* slower than direct access to the graphics card citation required. Seriously, of all the things for XNA to be slow at on the 360, I really can't see why it would be the rendering. Do you have evidence for this? (Same applies for on Windows tbh)
|
# ¿ Apr 10, 2010 10:27 |
|
Yeah, unless you are writing your own command buffers, which you don't have access to in XNA, then it's going to be pretty much identical. No VMX support seems like a much bigger deal, to me anyway. EDIT: And the limited control of memory... digibawb fucked around with this message at 12:48 on Apr 10, 2010 |
# ¿ Apr 10, 2010 12:40 |
|
cronio posted:Looks like I was partially wrong -- the Direct3D implementation on the 360 is much lower-level than on Windows. In the native API you do get direct access to the hardware though, i.e. you can bypass the Direct3D API or even write directly to the command buffer (and many do). I can't cite anything but this is directly from people who work on the 360. I work on both the 360 and PS3! I was making the assumption that most 360 developers don't actually end up bypassing the API and rolling their own command buffers, perhaps this is a faulty assumption however. I can certainly see where you are coming from on the PS3 though The Windows comment was based on this assumption, in that the managed wrapper around D3D is unlikely to be a bottleneck. cronio posted:Yeah, I was assuming the difference was more along the lines of OpenGL vs. libgcm on the PS3. Since that's not the case the differences for the average coder are less, but game developers still do a lot of asm-level optimization (even if they're not writing assembly, analyzing the assembly generated by the compiler). I'd like to think I'm quite open to change, thank you very much :P I'd certainly like to see C# in use for game code, though I don't think it's quite practical yet (for us anyway). I muddle around with XNA at home, and not being able to see what it's doing under the hood will probably become a pain for me at some point, though I haven't hit that yet. Knowing that the JIT will never generate VMX output annoys me, more so than the fact that I just can't write it in intrinsics in the first place. The instruction set for SSE is rather different though, so I can see why this isn't practical either. Vinterstum posted:Interpreted languages tend to rely on JITting for their speed but that doesn't work on consoles (all executable code must be signed, and statically compiling them (like Unity for the iPhone does) is pretty variably supported (Unity's solution is very customized and specialized). I'm pretty sure XNA is JIT'ed even on the 360, fairly certain I saw a post by Shawn Hargreaves stating it was only a couple of days ago in fact. We might be getting a little off topic here though
|
# ¿ Apr 11, 2010 14:48 |
|
ultra-inquisitor posted:It's almost certainly a cyclic dependency, you need to forward declare one of the classes. You can't forward declare a type you are using as a base.
|
# ¿ Jun 3, 2010 14:52 |
|
Pivo posted:Hello kind folks Grab a trial version of vtune. EDIT: Assuming you are running on Intel anyway, otherwise AMD have their own profiler which I can't remember the name of. There's also http://www.codersnotes.com/sleepy though it's kind of on the basic side. digibawb fucked around with this message at 09:38 on Jun 9, 2010 |
# ¿ Jun 9, 2010 09:32 |
|
Does the add function need to modify the state parameter?
|
# ¿ Jun 22, 2010 10:23 |
|
If you have performance problems, profile, don't guess. The most obvious answer would be that you just end up with less entries being pushed into the stack => less work to do. Simple test would be to just log how many items you push onto the stack with both the right and wrong versions.
|
# ¿ Aug 26, 2010 09:59 |
|
Sounds like you are looking for _mm_set1_epi32, that's just a compound operation as well, similar to your initial code. _ps is just for floats. EDIT: Though it may still be a better implementation... digibawb fucked around with this message at 13:37 on Dec 10, 2010 |
# ¿ Dec 10, 2010 13:32 |
|
|
# ¿ Apr 29, 2024 18:17 |
|
I missed the fact that your ultimate goal was to perform a fabs, sorry. You could also look at: _mm_max_ps( _mm_sub_ps( _mm_setzero_ps(), xyz ), xyz ); as that doesn't require any loads at all, but it depends how your register congestion is I guess! EDIT: I've been stuck in PPC land for a while, so I'm a bit fuzzy on SSE and its general bottlenecks though, but it might help
|
# ¿ Dec 10, 2010 21:40 |