|
Why not write an overload that just calls the other one and then adds the const-ness to the result before returning it? You then have the clean external api, and only one place to adjust when the mapping changes.
|
# ? Jun 30, 2015 05:34 |
|
|
# ? Jun 8, 2024 08:42 |
|
Jabor posted:Why not write an overload that just calls the other one and then adds the const-ness to the result before returning it? You then have the clean external api, and only one place to adjust when the mapping changes. You can't call a non-const method from a const one, so somewhere in here you have to use const_cast. Are member pointers really that bad?
|
# ? Jun 30, 2015 05:45 |
|
Why not use the member pointer returning method as a secret implementation detail for two public methods returning const and non-const references?
|
# ? Jun 30, 2015 06:13 |
|
Vanadium posted:Why not use the member pointer returning method as a secret implementation detail for two public methods returning const and non-const references? Ooh, I kind of like that idea, actually.
|
# ? Jun 30, 2015 06:19 |
|
If I understood you correctly, you should just const_cast away the constness internally to support both const and nonconst interface. This is one of the few cases where it is completely sane and expected to use const_cast.
|
# ? Jun 30, 2015 12:07 |
|
Xarn posted:If I understood you correctly, you should just const_cast away the constness internally to support both const and nonconst interface. Yeah, it's one less method if I just bite it and use const_cast. I just wasn't sure which of the two insane-seeming options I should be using. Thanks all!
|
# ? Jun 30, 2015 18:22 |
|
In VS2013, my solution works perfectly fine in debug mode, but in Release one of the projects fails to compile because it can't find the iostream header Apparently the error happens in one of the headers from a 3rd party library I include. I checked that all the compiler and liker include directories are exactly the same between the debug and release configurations. Any ideas what I might be missing here?
|
# ? Jun 30, 2015 19:53 |
|
I'm writing some code that involves putting a specific instance of an object into a vector, with a certain value, followed by another, and another -- as many as the user cares to input. So it'd be something like: <Mary's Ball (1), Mary's Ball (2), Mary's Ball (3), Alex's Ball (1), Alex's Ball (2), Alex's Ball (3), John's Ball (1), John's Ball (2), John's Ball (3), ...> The code that I started with is: code:
Now, I know that what I need to do is use an iterator, like a for loop, and then pass the last value of the iterator outside so that the next sequence of objects can be placed at the spot where it last left off. But I've been sort of breaking my brain on how is the best way to do this. The way I've been puttering about with this is that it solicits the user for a string to input, runs the loop and places the names, then asks the user for more. (Bear in mind that I'm pretty much a noob when it comes to C++, I've been sort of teaching myself off and on!) Thanks in advance!
|
# ? Jul 5, 2015 14:59 |
|
Well you could ask for the last element in the vector, but unless I'm missing something about what you're trying to do, this seems a bit more complicated than necessary. code:
|
# ? Jul 5, 2015 15:50 |
|
mobby_6kl posted:Well you could ask for the last element in the vector, but unless I'm missing something about what you're trying to do, this seems a bit more complicated than necessary. That ... seems a lot more concise. I'm not certain if I quite understand how "while ( get ... )" works, though. Do you have to type in something every time? Like if I wanted 3 balls with "mary" in them, would I have to type "mary" three times?
|
# ? Jul 5, 2015 16:24 |
DrSunshine posted:That ... seems a lot more concise. In that, "get nameFiller" is pseudocode. Not actual legal C++. But the emplace_back function just creates a new object at the end of an ordered container. In your original code, you have a variable "b" that isn't declared/explained. I'm not sure what it's supposed to be, so it's hard to know what you intended the code to do.
|
|
# ? Jul 5, 2015 16:48 |
|
nielsm posted:In that, "get nameFiller" is pseudocode. Not actual legal C++. Oh, "b" was the number of balls per name, "numNames" is the number of names. So for example, if you had 2 names - Mary and Jake - and put in "3", it'd create six balls - 3 carrying the string "Mary" and 3 with "Jake".
|
# ? Jul 5, 2015 16:57 |
|
DrSunshine posted:That ... seems a lot more concise. Yeah, while/get was a bit pseudo-codish for "keep reading names from stdin", you can keep what you have if that works. The other stuff (b, numNames) weren't clear from the code so I ignored that. Sorry for the confusion. I just wanted to simplify this to get to the important part, which is: code:
But this is a really strange way to do what you seem to want to do, which I understand is "add a new ball belonging to nameFiller to the vector". Depending on your ball's constructor, you can do that with the single line I posted, which creates the ball belonging to "nameFiller" in the vector. Unless you want to have the exact same ball 3 times in the vector, in which case you'd need to store pointers/references to the single instance of Marry's ball etc. Welcome to C++! mobby_6kl fucked around with this message at 20:33 on Jul 5, 2015 |
# ? Jul 5, 2015 16:58 |
|
mobby_6kl posted:Yeah, while/get was a bit pseudo-codish for "keep reading names from stdin", you can keep what you have if that works. The other stuff (b, numNames) weren't clear from the code so I ignored that. Sorry for the confusion. I just wanted to simplify this to get to the important part, which is: Oh! So instead of "ballSet[i]" it'd be like "ballset[ballSet.size()]"? That had not occurred to me! Brilliant!
|
# ? Jul 5, 2015 17:30 |
|
DrSunshine posted:Oh! So instead of "ballSet[i]" it'd be like "ballset[ballSet.size()]"? That had not occurred to me! Brilliant! That is undefined behavior (out of bounds reference) if you're using a vector, and if you're lucky it will crash. (If you're unlucky, it will post your banking details to 4chan.)
|
# ? Jul 5, 2015 17:53 |
DrSunshine posted:Oh! So instead of "ballSet[i ]" it'd be like "ballset[ballSet.size()]"? That had not occurred to me! Brilliant! No, assuming ballSet is a vector<ball> that's just an invalid access past the end, and ought to crash your program. The vector.emplace_back() function creates a new element at the end and initializes it with the constructor arguments you pass. The vector.push_back() function creates a new element at the end and copies an existing object into it. Those two functions are the main ways of extending a vector with more elements. You should only use the [x] array indexing notation on a vector when you're accessing already existing elements.
|
|
# ? Jul 5, 2015 17:55 |
|
Contains Acetone fucked around with this message at 17:32 on Jun 24, 2020 |
# ? Jul 6, 2015 05:25 |
|
This is in C, using clang on OS X 10.10 I'm parsing old 'snd' resources from classic Mac applications and one of the header fields is specified as being an 80-bit extended floating point number: quote:The sample rate at which the frames were sampled before compression, as expressed in the 80-bit extended data type representation. I'm not sure what C type I'm supposed to be using to represent this. cppreference indicates that long double might be the right type, but if that's so, then I'm not sure how I'm supposed to jam the 10 bytes I've got into a data type which is sizeof(long double) = 16 bytes on my system. code:
Any suggestions?
|
# ? Jul 9, 2015 04:18 |
|
The data is probably big-endian and so needs to be swapped.C code:
|
# ? Jul 9, 2015 05:03 |
|
csammis posted:This is in C, using clang on OS X 10.10 On x86 and x86-64, that's long double. Loads and stores of this type only touch ten bytes, but in C the sizeof is always a multiple of the alignof to simplify array calculations, and it's somewhat faster to give the type a higher alignment because it makes it more likely that the access won't straddle a cache-line boundary. On other architectures, you would be somewhat screwed, because they do not provide this type. long double on ARM is a 128-bit format. You can, of course, simulate the 80-bit format manually; just know that it has some peculiarities. Fortunately, you did say you're on OS X. csammis posted:
Stop using memset instead of memcpy.
|
# ? Jul 9, 2015 05:29 |
|
Isn't the 80-bit extended format effectively just the quad-precision format with a mantissa truncated to 64 bits?
|
# ? Jul 9, 2015 10:04 |
|
Jabor posted:Isn't the 80-bit extended format effectively just the quad-precision format with a mantissa truncated to 64 bits? 63 bits, really.
|
# ? Jul 9, 2015 10:20 |
|
Plorkyeran posted:The data is probably big-endian and so needs to be swapped. Yes! All the rest of the data in these headers is big endian and I didn't even pause to think about this type being swapped too, durr. My data turns out to be 22050.000. rjmccall posted:<< architecture information >> Out of curiousity what the corresponding C type have been on PowerPC? All the example code on Apple's legacy doc site is in Pascal but surely there was a C port for application development. I've never actually written code for a pre-OS X Mac so maybe that's just not true. rjmccall posted:Stop using memset instead of memcpy. Fortunately for my ever-vanishing sanity that was a typo in my post
|
# ? Jul 9, 2015 14:02 |
|
They might have just parsed out the 80-bit format. Or it might be the size of the largest float the old non-Intel Mac FPU could do, like the x87 FPU did.
|
# ? Jul 9, 2015 15:15 |
|
The m68k did in fact have an 80 bit FPU.
|
# ? Jul 9, 2015 16:00 |
|
sarehu posted:63 bits, really. Right, the field occupies 64 bits in memory, but the high bit is always set in what would otherwise be normalized representations. It means you can do, say, multiplication with an ordinary 64-bit multiplier; a 65-bit multiplier is actually a pain in the rear end, as I understand it. Yeah, the 68k natively supported the same 80-bit format as Intel. PPC does not; long double there is typically a double-double format, primarily implemented in software in terms of doubles, and if you've never heard about this you are probably a happier person for it.
|
# ? Jul 9, 2015 17:33 |
|
I'm writing a program that takes 2 inputs in the form of 2 characters translates them to binary, packs them together into an unsigned int and provides that translation from decimal to binary, then unpacks them. I am at a loss as to how I can utilize my pointers in the unpack function to finish this project.C code:
Modulo16 fucked around with this message at 21:13 on Jul 17, 2015 |
# ? Jul 17, 2015 21:00 |
|
Maybe C lets you do this without an explicit cast, but you probably want to cast value to char before assigning it to your char *s, and passing *bPtr to printf before you assign it is not going to give you the result you want.
|
# ? Jul 17, 2015 21:40 |
|
Dessert Rose posted:Maybe C lets you do this without an explicit cast, but you probably want to cast value to char before assigning it to your char *s, and passing *bPtr to printf before you assign it is not going to give you the result you want. I'm actually over the use of the pointers. Here's the Mark II, and it does everything I want, but it is giving me symbols instead of the characters in the printf lines inside of the main function. Why in the world is it doing that? C code:
Modulo16 fucked around with this message at 21:51 on Jul 17, 2015 |
# ? Jul 17, 2015 21:45 |
The %c format specification prints an integer as a single character. If you want to print the character code in decimal, use the %d format specifier.
|
|
# ? Jul 17, 2015 21:57 |
|
nielsm posted:The %c format specification prints an integer as a single character. If you want to print the character code in decimal, use the %d format specifier. that gives me an absurdly large number, not the character. This is kind of weird because function unpack displays the characters properly.
|
# ? Jul 17, 2015 22:00 |
Uh, oh yeah. Notice the difference between these two lines: C++ code:
|
|
# ? Jul 17, 2015 22:05 |
|
nielsm posted:Uh, oh yeah. Whoop! nice catch! Please don't judge me its been a long day.
|
# ? Jul 17, 2015 22:07 |
|
You're passing a pointer. Edit: You might run into trouble on some inputs because char is signed, also your unpack function isn't actually unpacking anything. sarehu fucked around with this message at 22:19 on Jul 17, 2015 |
# ? Jul 17, 2015 22:13 |
|
sarehu posted:You're passing a pointer. line 34?
|
# ? Jul 17, 2015 22:15 |
|
Frank Viola posted:line 34? SA doesn't have line numbers.
|
# ? Jul 17, 2015 22:20 |
|
sarehu posted:You're passing a pointer. I can't use data type unsigned for char though unless, I am mistaken. I just caught that I'm function calling display of x and y instead of having it actually display results.
|
# ? Jul 17, 2015 22:22 |
|
You're converting a "char" to "unsigned int." In C, the signedness of "char" is implementation-specific, but usually it's signed. Suppose somebody inserts a character with code greater than 127, such as é, in many character sets. It'll get a negative value. Suppose that value is "x." Then, when you convert that to an unsigned int, it'll have the value "x + UINT_MAX + 1." You probably don't want the packing behavior that your code currently gives you.
|
# ? Jul 17, 2015 23:20 |
|
I want to compare some variable against a set of numbers inside of a vector that the user can specify. For example:code:
|
# ? Jul 22, 2015 05:21 |
|
|
# ? Jun 8, 2024 08:42 |
|
If you're using C++11, std::any_of does exactly what you want.
|
# ? Jul 22, 2015 05:37 |