|
hooah posted:I'm just now running across char* objects, and am somewhat confused. The book says they're pointers, but unlike (all?) other pointers, you can assign a string directly to the pointer, rather than to the dereferenced object. Are char* objects different just because, or is there an explanation for this difference? String literals are little more than a quick way of telling the compiler, "Hey buddy, statically allocate this sequence of chars somewhere, I don't care where, and put a zero at the end while you're at it."
|
# ? Jul 6, 2013 21:41 |
|
|
# ? May 13, 2024 18:00 |
|
Spatial posted:It's because string literals aren't objects, they're pointers to null-terminated arrays of char primitives.
|
# ? Jul 6, 2013 23:10 |
|
what signifies an object?
|
# ? Jul 8, 2013 17:44 |
|
The C FAQ has a whole section on Arrays and Pointers that pedantically and obsessively explains the difference between the two types. Honestly though, the most practical difference is how the sizeof operator works:code:
code:
There's an idiom you'll sometimes see in C code, "(sizeof(foo) / sizeof(foo[0]))" that returns the number of elements in an array. Of course, this only works for array types, not pointers. It's also worth pointing out that, unlike structs, arrays are not first-class types in C, and can't be passed directly into functions, so you must use a pointer here. This is why array types can always degrade to a pointer to its first element. This also means that any function that takes an "array" (really, pointer to the array's first element) as a parameter needs some way to determine where the array ends, either by a second "count" parameter, or termininating the array with a sentinel.
|
# ? Jul 8, 2013 19:07 |
|
While you can't pass arrays by value (or even have an array be an argument without it auto-decaying to a pointer), you can use pointers/references to fixed size arrays and get some sweet type checking.code:
|
# ? Jul 9, 2013 00:06 |
|
Ok, I did not know that.
|
# ? Jul 9, 2013 01:24 |
|
FamDav posted:While you can't pass arrays by value (or even have an array be an argument without it auto-decaying to a pointer), you can use pointers/references to fixed size arrays and get some sweet type checking. Also a (dumb) C99 feature: C code:
|
# ? Jul 9, 2013 01:49 |
|
FamDav posted:what signifies an object? Objects are class types (which includes structs), unions, arrays, and scalar types. Scalar types are arithmetic types, enum types, and pointer types. Things that aren't object types are reference types, void types, function types, etc.
|
# ? Jul 9, 2013 03:50 |
|
C++ code:
|
# ? Jul 9, 2013 17:01 |
|
tractor fanatic posted:
If the der being called is definitely a der and the compiler can infer that from the code, then the compiler would be able to inline it.
|
# ? Jul 9, 2013 17:07 |
|
tractor fanatic posted:If I were to call der::use_a_thing() in a tight inner loop, where the full definition would be visible to the compiler, would I need to worry about the virtual? Would the compiler (specifically MSVC) be able to inline the whole thing?
|
# ? Jul 9, 2013 17:31 |
|
Any reasonably competent compiler should be able to do this devirtualization just from memory analysis, since both the constructor call and virtual call site are exposed. However, if there are any difficult stores or opaque uses of the local between the construction and the virtual call, devirtualization might be blocked. On one level this shouldn't be true, because the language makes various guarantees that basically amount to "you can't drop a non-X on top of an object of type X and still access it through the original name". These guarantees are supposed to make devirtualizing calls on local variables fairly easy. And most compilers do indeed take advantage of this by devirtualizing calls made directly on objects (as opposed to via a reference or pointer). Unfortunately, the forwarding rules for this guarantee are really arcane, surprising, and poorly-specified to boot. It's bad enough that I've had multiple extended discussions about how we could exploit this (beyond syntactic-level devirtualization) in clang and never really come up with anything reasonable. So while I can't actually speak for MSVC, I'd be pretty surprised if they did anything extra here. You could in theory get this by virtue of a generic optimization to subclass-specialize base::use_a_thing, but I don't think MSVC does that optimization (nor do any of the other major compilers).
|
# ? Jul 9, 2013 17:50 |
|
Am I missing something or what. I'm trying to write a RGBA8888 to RGB565 conversion. My test input is: 0xAAFF00FF 10101010111111110000000011111111 Well ok, I want to mask the most significant bits off, so I come up with 0x00F800F8 00000000111110000000000011111000 pixel = pixel & 0x00F800F8; And I get 0x00C800C8 00000000110010000000000011001000 I expected 0x00F800F8... how did it end up like that?
|
# ? Jul 9, 2013 22:51 |
|
slovach posted:I expected 0x00F800F8... how did it end up like that?
|
# ? Jul 9, 2013 23:10 |
|
God loving dammit I actually had a typo I kept glancing over. I missed it like 5 times and didn't catch it until just now. Oops.
|
# ? Jul 9, 2013 23:15 |
|
I have a really basic conceptual question. In this snippet: code:
|
# ? Jul 10, 2013 02:18 |
|
I basically have some code that iterates data, and several different simple payload functions that I want executed on them. I don't want to switch operations midstream, and I also don't want the overhead of making a function call. I basically just want to stick each payload into the function, compile it in turn, and give it a defined name, but without having the redundancy of the same iteration code being everywhere if I just copied and pasted five times. So basically I want: code:
e: Perhaps prototype the payload and iteration functions, and then #define the deploy function? Would that inline it properly? Paul MaudDib fucked around with this message at 02:37 on Jul 10, 2013 |
# ? Jul 10, 2013 02:24 |
|
OctaviusBeaver posted:I have a really basic conceptual question. The integer that you add to a pointer is always implicitly in units equal to the size of the pointed-to type. In other words, adding 1 to the pointer in your example moves by sizeof(int) bytes. Adding sizeof(int) increments by sizeof(int) * sizeof(int) bytes.
|
# ? Jul 10, 2013 02:31 |
|
That Turkey Story posted:The integer that you add to a pointer is always implicitly in units equal to the size of the pointed-to type. In other words, adding 1 to the pointer in your example moves by sizeof(int) bytes. Adding sizeof(int) increments by sizeof(int) * sizeof(int) bytes. Ah, gotcha that makes sense. Thanks!
|
# ? Jul 10, 2013 02:41 |
|
Paul MaudDib posted:I basically have some code that iterates data, and several different simple payload functions that I want executed on them. I don't want to switch operations midstream, and I also don't want the overhead of making a function call. I basically just want to stick each payload into the function, compile it in turn, and give it a defined name, but without having the redundancy of the same iteration code being everywhere if I just copied and pasted five times. Example: code:
|
# ? Jul 10, 2013 03:32 |
|
C++ code:
edit: probably not since an array of some_type would be unaligned so iterating a some_type* wouldn't work. tractor fanatic fucked around with this message at 20:12 on Jul 10, 2013 |
# ? Jul 10, 2013 20:09 |
|
tractor fanatic posted:
Pretty much the only guarantees for struct memory layout you get are that &foo == &foo.a and &foo.a < &foo.b.
|
# ? Jul 10, 2013 23:54 |
|
tractor fanatic posted:
Formally, it is arguably not legal under the standards to get from one object to another with pointer arithmetic unless they're in an array. Even if you ignore that, the specific assumption that the pointer past the end of a field points to the next field is not strictly guaranteed to be portable, even if they have the same size and alignment. But in practice, yes, you are not going to have any problems, regardless of what packed attributes you might have on what. (Except for the standard thing that forming a pointer to a member of a packed structure can leave you with an inadequately-aligned pointer.)
|
# ? Jul 11, 2013 03:22 |
|
This might get sent me straight to the coding horrors thread but does goto'ing out of an exception block to some common error logging then rethrowing work?
|
# ? Jul 11, 2013 19:15 |
|
Is there a reason you can't just call a common error logging function?
|
# ? Jul 11, 2013 19:52 |
|
Jerry SanDisky posted:Is there a reason you can't just call a common error logging function? I could. It's just poorly structured code in a terrible object model and I probably shouldn't have even asked the question because if I were to suggest a fix other than a rework of the object model it'd just be piling a horror on top of another horror.
|
# ? Jul 11, 2013 19:59 |
|
Dren posted:This might get sent me straight to the coding horrors thread but does goto'ing out of an exception block to some common error logging then rethrowing work? No. Operand-less throw rethrows the (latest) exception currently being handled. If you leave the catch handler for an exception without rethrowing it, the exception is no longer being handled and is destroyed.
|
# ? Jul 11, 2013 20:43 |
|
rjmccall posted:No. Operand-less throw rethrows the (latest) exception currently being handled. If you leave the catch handler for an exception without rethrowing it, the exception is no longer being handled and is destroyed. Unrelated to the above question, but I was under the impression that you can have an exception live past the catch by getting an exception_ptr to it via std::current_exception. Is that the case? Posting Principle fucked around with this message at 21:02 on Jul 11, 2013 |
# ? Jul 11, 2013 20:57 |
|
Jerry SanDisky posted:Unrelated to the above question, but I was under the impression that you can have an exception live past the catch by getting an exception_ptr to it via std::current_exception. Is that the case? I was glossing over that intentionally, but yes, C++11 lets you capture exceptions, pass them around outside of the exception mechanism, and throw them on multiple threads. Although some of the behavior, like whether and how often the exception is copied, is hilariously unportable, which I consider my greatest achievement in the committee process.
|
# ? Jul 12, 2013 01:01 |
|
rjmccall posted:No. Operand-less throw rethrows the (latest) exception currently being handled. If you leave the catch handler for an exception without rethrowing it, the exception is no longer being handled and is destroyed. Thanks for the answer, I wasn't sure if goto would count as leaving.
|
# ? Jul 12, 2013 05:45 |
|
Diving into C++ since I figure it's about drat time I finally learn it. Is CMake an okay build system? More generally, any tips for how to write and run code effectively? I'm thinking of using Vim with YouCompleteMe (which is a module that uses LLVM to do completions), but I have no beef with Eclipse. I'm on a mac, so Visual Studio is out.
|
# ? Jul 13, 2013 08:27 |
|
Doctor w-rw-rw- posted:Diving into C++ since I figure it's about drat time I finally learn it. Is CMake an okay build system? Anything can work but I would recommend just using XCode - it's easy to set up and you don't have to wonder if the tool is working correctly. There is a learning curve to C++ and you probably don't want to throw "did I really set everything up correctly" questions on top of actual issues with the language.
|
# ? Jul 13, 2013 12:10 |
|
Can XCode compile a file individually yet? I found it unusable due to that alone.
|
# ? Jul 13, 2013 15:10 |
|
Doctor w-rw-rw- posted:Diving into C++ since I figure it's about drat time I finally learn it. Is CMake an okay build system? You can just use XCode and keep the same process you've been using all along. We mix C/C++/Obj-C/Obj-C++ on our projects all the time.
|
# ? Jul 13, 2013 15:20 |
|
I love YCM but you have to like vim for it to be a remotely enjoyable tool. Xcode can use standard Makefiles if you want to go that way; CMake can also generate XCode projects now. But I'm not sure I would bother with CMake unless I was doing a big project with lots of dependencies that had to be cross-platform. It's definitely an additional layer or complication, not abstraction.
|
# ? Jul 13, 2013 15:57 |
|
I don't know how XCode is in recent versions but I have found the code completion and general navigation around in your source to be far superiour in Eclipse (for C++), despite it's other faults.
|
# ? Jul 13, 2013 18:03 |
|
Well, I hate the poo poo out of making Makefiles, and for the project I have in mind, I want to make something that I know will compile a static binary and run a server on Linux boxes. To that end, XCode probably won't add much over anything else with decent autocomplete, and I don't have an workflow for that which I'm particularly attached to. Sounds like there's nothing horribly bad about CMake. I don't mind too much about writing project definition files, I'm doing it to learn so if it's the tool of choice for writing big, cross-platform projects with lots of dependencies, that's worth the trouble to me. Also, I like vim, so I got that covered. --- So about the language itself - assuming familiarity with most languages, what are the things fairly unique or uncommon in C++ that I should read up on?
|
# ? Jul 13, 2013 18:31 |
|
C++ is a big language. It's gigantic. There's more in the language and library than any other language in the world. You cannot learn all the different features and styles of C++ if you casually play around with it. If you don't know C, I recommend learning that first. C++ is a lot easier to take in once you know C.
|
# ? Jul 13, 2013 18:38 |
|
Doctor w-rw-rw- posted:So about the language itself - assuming familiarity with most languages, what are the things fairly unique or uncommon in C++ that I should read up on? Constructors/destructors/RAII, templates (this is a huge one and includes lots and lots of things), unqualified name lookup, pointers, references, move-semantics, lambda functions, operator overloading, how to write exception-safe code, the standard libraries (and probably be at least a little familiar with the boost libraries). Probably more that I'm leaving out.
|
# ? Jul 13, 2013 18:43 |
|
|
# ? May 13, 2024 18:00 |
|
I am aware of its humongousness, and am very comfortable with C. I just figure it's about time, since large or very interesting projects that need native-level speed are likely going to have to touch C++ sooner or later. Cool, thanks!
|
# ? Jul 13, 2013 18:55 |