|
Ledneh posted:A dumb question about debuggers. Are they designed to work only with executables output by particular compilers, or at least a limited set of compilers? The debugger needs to be able to understand the format of the executable and debugging symbols. You can possibly make it work since there is a gdb for executables compiled with suncc. You will then need the Visual Studio plugin which uses gdb under the hood. Expect a lot of work if you can get it to work.
|
# ? Feb 16, 2011 09:32 |
|
|
# ? Jun 8, 2024 01:16 |
|
I've always wondered. Take these two functions for example: code:
|
# ? Feb 17, 2011 10:56 |
|
Optimus Prime Ribs posted:I've always wondered. I think you would actually lose performance by using a reference in this case. If you pass the data by value, then the system just needs to pass on the 4 bytes for the integer, but when you pass by reference it needs to pass on 4 bytes for the address of the integer, which then needs to be looked up to get the actual value of the integer.
|
# ? Feb 17, 2011 11:28 |
|
And on 64-bit systems it will pass an 8-byte address of the 4-byte integer. Unless the function gets inlined.
|
# ? Feb 17, 2011 12:52 |
|
shrughes posted:And on 64-bit systems it will pass an 8-byte address of the 4-byte integer. Don't know how I never realised that. Seems I have some code to fix up then. Thanks.
|
# ? Feb 17, 2011 18:43 |
|
You should really never pass scalars by const reference; it just means more code, more memory traffic, and less pipelining. This is especially true for platforms which can pass the scalars in question in registers, but it's also true on x86, because some processors actually do some crazy pipelining through the stack, and indirection can kill that. You should also generally be passing small POD classes — e.g. two floats, an int and a pointer, or something else along those lines — by value.
|
# ? Feb 17, 2011 20:46 |
|
That's quite interesting to know, I almost always pass small structs as const references, presuming it's quicker than passing by value. You're saying it may actually be slower that way, even with optimization turned on? I'd guess that with a small, inlined function passing by reference would still be faster? Edit: Know I think about it, would compiler optimizations not say something like "Since passing by value is faster, and the reference is const, I can safely produce pass by value code instead"? I really should study compiler architecture more Gerblyn fucked around with this message at 21:01 on Feb 17, 2011 |
# ? Feb 17, 2011 20:55 |
|
Gerblyn posted:That's quite interesting to know, I almost always pass small structs as const references, presuming it's quicker than passing by value. You're saying it may actually be slower that way, even with optimization turned on? I'd guess that with a small, inlined function passing by reference would still be faster? If the function is inlined, there should be no difference. If the function is not inlined, passing a small object by value instead of by reference is generally a slight win that can also unblock other optimizations. Obviously this only applies to objects with trivial copy constructors and destructors. Gerblyn posted:Edit: Know I think about it, would compiler optimizations not say something like "Since passing by value is faster, and the reference is const, I can safely produce pass by value code instead"? I really should study compiler architecture more In general, compilers are not permitted to change function signatures like this unless they're positive they know every use of the function, and therefore relatively few compilers actually perform this optimization.
|
# ? Feb 17, 2011 21:50 |
|
rjmccall posted:You should really never pass scalars by const reference; it just means more code, more memory traffic, and less pipelining. This is especially true for platforms which can pass the scalars in question in registers, but it's also true on x86, because some processors actually do some crazy pipelining through the stack, and indirection can kill that. Makes me wonder why the school where I majored in C++ programming didn't cover this. More times I think about it the more I see dropping out was a good decision. rjmccall posted:If the function is not inlined, passing a small object by value instead of by reference is generally a slight win that can also unblock other optimizations. Obviously this only applies to objects with trivial copy constructors and destructors. Would the same be true if a pointer were passed instead?
|
# ? Feb 17, 2011 22:02 |
|
rjmccall posted:You should also generally be passing small POD classes — e.g. two floats, an int and a pointer, or something else along those lines — by value. What would you say is the cutoff where this starts becoming a performance loss? 4 floats? 16 floats?
|
# ? Feb 17, 2011 22:09 |
|
Optimus Prime Ribs posted:Makes me wonder why the school where I majored in C++ programming didn't cover this. To be fair, we're talking about nanosecond differences in performance here. If you really wanted to optimize your code, looking at this sort of thing isn't generally going to give you much return for your efforts. Good programming courses focus more on things like Order N notation to help teach optimization, since by understanding when to use a binary search instead of a linear search can cut the number of instructions an algorithm does massively, which is 99% of the time far more effective than making a function call a fraction of a microsecond faster. Not to say the information isn't useful, for example passing by pointer/reference (AFAIK they often equate to pretty much the same thing as far as the compiler's concerned) instead of value might lead to more data cache misses as the code has to do extra memory look ups, which on certain systems (like PS3s or X360s) can lead to trouble. rjmccall posted:If the function is inlined, there should be no difference. If the function is not inlined, passing a small object by value instead of by reference is generally a slight win that can also unblock other optimizations. Obviously this only applies to objects with trivial copy constructors and destructors. Ah, okay, that makes sense. Thanks!
|
# ? Feb 17, 2011 22:14 |
|
Gerblyn posted:To be fair, we're talking about nanosecond differences in performance here. Oh, I know. Just figured they'd have more comprehensive "dos and don'ts" then they did. And seemed to me like that would be a good thing to point out. e: Gerblyn posted:Good programming courses focus more on things like Order N notation Yeah for example: I had never even heard of this until I started reading this thread. That school sucked.
|
# ? Feb 17, 2011 22:17 |
|
Optimus Prime Ribs posted:Yeah for example: I had never even heard of this until I started reading this thread. Ouch, my course was teaching me that stuff in the second semester.
|
# ? Feb 17, 2011 22:28 |
|
Optimus Prime Ribs posted:Oh, I know. Just figured they'd have more comprehensive "dos and don'ts" then they did. And seemed to me like that would be a good thing to point out. If the major was literally "C++ programming" it sounds pretty lovely, all right. C++ can be pretty arcane but still doesn't really justify a whole degree.
|
# ? Feb 17, 2011 22:49 |
|
GrumpyDoctor posted:If the major was literally "C++ programming" it sounds pretty lovely, all right. C++ can be pretty arcane but still doesn't really justify a whole degree. It was specifically tailored for game programming in C++, but a lot of important gotchas and whatnot just weren't covered. Didn't mean to turn this into a discussion about the lovely college I went to though.
|
# ? Feb 17, 2011 22:55 |
|
Optimus Prime Ribs posted:Would the same be true if a pointer were passed instead? With only very rare exceptions, passing around or storing an A& has exactly the same low-level performance impact as passing around or storing an A*. There are obviously high-level semantic differences, but from a low level, there isn't much. Paniolo posted:What would you say is the cutoff where this starts becoming a performance loss? 4 floats? 16 floats? As a rough rule of thumb, I'd say anything larger than 2 pointers is something you should consider passing by reference/pointer. A lot of the specifics here come down to the platforms, though. For example, the UNIX/MacOSX x86-64 ABI will usually "break down" a struct that's <= 16 bytes and pass the elements in registers, depending on the types involved; so a struct with 4 floats will actually get passed in 2 SSE registers. x86-32 ABIs generally pass everything on the stack, so the balance is different. Gerblyn posted:To be fair, we're talking about nanosecond differences in performance here. Right, absolutely. This is definitely low-level performance. There are legitimate performance gains to be had by tweaking this kind of thing, but often those gains will be totally swamped by higher-level performance factors — choice of algorithm, misuse of concurrency, kernel abuse, poor memory locality, whatever. Gerblyn posted:Not to say the information isn't useful, for example passing by pointer/reference instead of value might lead to more data cache misses as the code has to do extra memory look ups, which on certain systems (like PS3s or X360s) can lead to trouble. Well, if you're using the data a lot, it'll probably be in cache anyway. The bigger concern is aliasing.
|
# ? Feb 17, 2011 23:03 |
|
Optimus Prime Ribs posted:Yeah for example: I had never even heard of this until I started reading this thread. You may not have heard of it because normal people call it big-O notation or refer more generally to asymptotic performance/bounds
|
# ? Feb 18, 2011 00:22 |
|
Ok, so hoping for a little homework help here. I'm very new to C++ still (only week 5 of the semester). I think I've got a lot of the basics down but I'm still having some issues with structs and objects. My code isn't compiling with a few errors it NetBeans that I can't figure out. quote:main.cpp:43: error: expected primary-expression before ')' token I marked the lines the errors relate to in the code with *************** Here is my mess of code as it stands right now, I only left in the parts relevant to the errors that someone should need to point out my mistake to me (I think). Some of the code and most of the comments were done for us on a template to begin with. Any help would be greatly appreciated! - code:
|
# ? Feb 20, 2011 04:46 |
|
Thrawn200 posted:
code:
Next, in your main function, you try to call welcome. Except, you aren't passing a variable into the function. You are passing the name of the class. Furthermore, your logic for your welcome function is wrong. The function assigns a name to the global variable player1. It then returns player1's name and sets player1's name to the returned value. That is redundant and there is no need to do that at all. What you are PROBABLY trying to do is this: code:
Nalin fucked around with this message at 05:27 on Feb 20, 2011 |
# ? Feb 20, 2011 05:25 |
|
Pretty much what Nalin said... You may want to take a look at this, it details how functions are created and used in C++.
|
# ? Feb 20, 2011 05:51 |
|
So I have a small issue. I have a vector union that consists of (partially) the following:code:
code:
|
# ? Feb 20, 2011 07:29 |
|
Theseus posted:So I have a small issue. I have a vector union that consists of (partially) the following: It's possible you're breaking aliasing rules in your test loop. Try compiling with -fno-strict-aliasing and see if that gives you the results you expect.
|
# ? Feb 20, 2011 07:51 |
|
QuickLime posted:It's possible you're breaking aliasing rules in your test loop. Try compiling with -fno-strict-aliasing and see if that gives you the results you expect. Removing the function consts and adding -fno-strict-aliasing reproduces the problem exactly as it was prior to having the consts and without -fno-strict-aliasing. Additionally, I tried removing the -O1 flag, and the problem still occurred.
|
# ? Feb 20, 2011 08:43 |
|
Nalin posted:In your prototype section, you have declared that you have a function named welcome that takes a Player structure and returns a Player structure. When you provide the implementation, you never give a name to the Player that you pass in. Thanks much, works. I'll have to look it over a few times more as I don't 100% understand all of it yet, but that helps a lot. I'll also read through that link nop posted.
|
# ? Feb 20, 2011 08:46 |
|
Theseus posted:So I have a small issue. I have a vector union that consists of (partially) the following: It has nothing to do with optimization; this is all overload resolution. Without the const, this operator is not a viable candidate when the LHS of some operation is const. Normally that would mean that this operation shouldn't compile; since that's not happening here, it must be using some different operator; since you didn't mention any other operator, I assume it's probably some builtin operator which ends up being viable because of some conversion operator on vector which you didn't mention. Also, don't pass floats by const reference.
|
# ? Feb 21, 2011 01:50 |
|
rjmccall posted:It has nothing to do with optimization; this is all overload resolution. Without the const, this operator is not a viable candidate when the LHS of some operation is const. Normally that would mean that this operation shouldn't compile; since that's not happening here, it must be using some different operator; since you didn't mention any other operator, I assume it's probably some builtin operator which ends up being viable because of some conversion operator on vector which you didn't mention. Awesome, thanks! Am I correct in my guess that the reason I shouldn't pass a float by const reference is because the reference can be as much as eight bytes on a 64-bite machine, while the float would only be four?
|
# ? Feb 21, 2011 02:25 |
|
We just had this discussion in this thread. On almost (†) any architecture you care about, floats can be passed at least as efficiently as pointers. (†) Except ARM. On most ARM platforms, it is substantially faster to write a floating-point value to memory, pass the address, and read it back out than to pass it directly. This because ARM's standard ABI does some terrible things for backward compatibility, and nobody realizes they should change it on their amazing new ARM-based platform until it's too late. rjmccall fucked around with this message at 03:27 on Feb 21, 2011 |
# ? Feb 21, 2011 03:22 |
|
I ran into a problem today with a template class, and I was wondering if someone could help. What I want to do is write a function that takes an stl vector as a parameter, any stl vector, but which can also do a couple of things with the data type that the vector is storing. Something like:code:
|
# ? Feb 21, 2011 17:44 |
|
Add template<typename _T> before the void. Also you really want to pass in vectors by const reference; passing them by value is O(n).
|
# ? Feb 21, 2011 17:57 |
|
Thanks! I'll give it a try when I get it into work tomorrow.
|
# ? Feb 21, 2011 18:00 |
|
Okay, I'm currently teaching myself C++ with a crappy "Teach yourself C++" book. So far it's not been too difficult, but I had a question. Is there an elseif in c++? This book has nothing on it. What I'm looking for is this:code:
code:
|
# ? Feb 22, 2011 21:36 |
|
No, but it doesn't need one:code:
|
# ? Feb 22, 2011 21:45 |
|
EDIT: Oh no, beaten! There is no 'elseif' statement. However, you CAN do this: code:
|
# ? Feb 22, 2011 21:46 |
|
code:
|
# ? Feb 22, 2011 21:46 |
|
So it's just whitespace manipulation then? If so, thanks, that works for me.
|
# ? Feb 22, 2011 21:50 |
|
Gothmog1065 posted:So it's just whitespace manipulation then? If so, thanks, that works for me. So if (bla) dosomething; else dosomethingelse; works exactly the same way as if (bla) dosomething; else if (bla2) dosomethingelse; or if (bla) dosomething; else for (a;b;c) dosomethingelse; ie. "else if" is not a special instruction in any way, it's treated the same as "else while" or "else for" or "else switch".
|
# ? Feb 22, 2011 21:57 |
|
roomforthetuna posted:ie. "else if" is not a special instruction in any way, it's treated the same as "else while" or "else for" or "else switch".
|
# ? Feb 22, 2011 22:13 |
|
roomforthetuna posted:The idea is that a single instruction is functionally treated the same as a squiggly-brackets-enclosed block containing a single instruction. An "if" is basically a single instruction to conditionally execute another block. Why did I not realize this before?
|
# ? Feb 23, 2011 00:17 |
|
Is there any easy way to concatenate a character to a string in C? Specifically, take a character out of another string, iterating through with a for loop. I tried strcat but apparently it needs to be a constant char for that to work. The program is supposed to check whether a string is a palindrome.code:
|
# ? Feb 23, 2011 05:20 |
|
|
# ? Jun 8, 2024 01:16 |
|
icantfindaname posted:Is there any easy way to concatenate a character to a string in C? Specifically, take a character out of another string, iterating through with a for loop. I tried strcat but apparently it needs to be a constant char for that to work. The program is supposed to check whether a string is a palindrome. If you just need to detect palindromes you don't need to shuffle any characters around. There are a bunch of examples at Rosetta Code.
|
# ? Feb 23, 2011 05:30 |