Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I know that pointers increment by the number of bytes that sizeof(type_i_am_using) returns. However, is there anyway to make a pointer increment bit by bit?
However, is there anyway to make a pointer increment bit by bit?
If you meant "byte by byte": No, because there is something called alignment. Addresses that are not aligned cannot be addresses of valid objects, hence a pointer containing an unaligned address is invalid. Most operations with invalid pointers invoke undefined behavior. If you want to e.g. access array subobjects of a standard-layout class where that array is the first member, cast the pointer to the element type of the array and work from there. There is no direct point in what you describe.
If you meant literally "bit by bit": There are well-known methods of iterating through all bits in an object representation using a simple for loop.
Most computer architectures don't let you address individual bits. If you need to, say, iterate through a sequence of bits, you need to iterate over the bytes instead (using a char *, or a pointer to a larger, unsigned integral type) and extract bits through bit shifting and bit mask operations. (value >> x) & 1 will extract the bit at index x from the right; value |= 1 << x will set it to 1, and value &= ~(1 << x) will set it to 0.
Note that vector<bool> is specialized to pack its values into individual bits.
A pointer can't be incremented bit by bit because a char is the smallest amount of addressable memory. This is mandated in the language specification. If you need to start looking inside individual bits then you most likely will want to use the bit shifting/masking operations.
For example to look inside a character you might want to do something like this:
bool get_bit_n(unsigned int n, char x){
return (1 << n) & x
}
Also you might want to look into std::bitset.
No. Character is the smallest thing that machine can address. You can however traverse all bits in machine using bit operations. In C++ you can use std::bitset or std::vector<bool> specialization, or bit fields.
Related
Given an integer type IntT such that sizeof(IntT) == sizeof(void*), and a variable of said type i, is it guaranteed that reinterpret_cast<IntT>(reinterpret_cast<void*>(i)) == i? This is similar to this question, but that question was looking at any arbitrary sized integer so the answer was a straight forward no. Limiting it to integers of exactly the same size as a pointer makes it more interesting.
It strikes me as though the answer would have to be "yes," because the specification states that there exists a mapping to any integer large enough to hold the pointer value. If the variables are the same size, then that mapping must be bijective. If it's bijective, then that also means the conversion from int to void* must also be bijective.
But is there a hole in that logic? Is there a wiggle word in the spec that I'm not accounting for?
I don't think this is guaranteed. The Standard guarantees that a pointer converted to a suitably large integer and back will have its original value. From this follows that there is a mapping from pointers to a subset of the suitably large integers and back. What it does not imply is that for every suitably-large integer value, there is a corresponding pointer value…
As pointed out by DavisHerring in the comments below, this means that the mapping is injective, but does not have to be surjective and, thus, bijective. I believe what the standard implies in mathematical terms would be that there is a left-unique and left-total relation between pointers and integers, not a bijective function.
Just imagine some weird architecture where, for some reason, every third Bit of an address must be zero. Or a slightly more reasonable architecture that uses only the lower 42 Bits of a 64-Bit value to store an address. Independently of how much sense that'd make, the compiler would be free to assume that an integer value being cast to a pointer must follow the pattern of a valid address and, e.g., mask out every third bit or only use the lower six Byte respectively…
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
In a C++ program I am writing for fun there are frequently numeric values being used that will absolutely never be greater than 255, and I am therefore storing them as unsigned chars to save on memory used (as an unsigned char only uses a byte, as opposed to the 4 bytes of an int). Is this a good idea? Are there any downsides to doing this?
I appreciate tips and insight anyone can give.
It's a trade-off.
Given that you are using unsigned char to represent non-negative (presumably) values that don't exceed 255, you will save on memory usage for storing the particular values.
If your code does arithmetic operations on those unsigned char, then the values may be implicitly promoted to int, the operation done using ints, and then the result converted back. This is consistent with the fact that quite a few real-world machines do not have machine registers that work directly with char types, but do have registers and instructions that are optimised for a larger "native" integral type i.e. int. Such to-and-fro conversions can mean that code which does a sequence of operations on unsigned chars can have measurably lower speed than coding to use variables of type int. (Notionally, an implementation might "optimise out" such to-and-fro conversions, if analysis shows there is no change of observable result from a sequence of operations, but it is not required to)
Generally speaking, for representing numeric values, I would suggest not using unsigned char and to default to using int (or another suitable integral type if the range of values you need to represent goes beyond the range that an int is guaranteed able to represent). Get the code working first and, if you decide to optimise your code to save on memory, do testing/profiling on representative target systems to determine the extent of any performance impact of using unsigned char. If using C++11 or later, you might also consider using uint8_t (on implementations that support it) but bear in mind there may be similar trade-offs with that as well.
There isn't really any downside but you might not use lesser memory depending on the order of your member variable definitions because of padding bytes(this only applies to classes).
This question already has answers here:
C/C++ Bit Array or Bit Vector
(5 answers)
Closed 7 years ago.
So, I was reading a question in Cracking the Coding Interview: 5th Edition where it says to implement a bit vector with 4 billion bits. And it defines a bit vector as an array that compactly stores boolean values by using an array of ints. Each int stores a sequence of 32 bits, or boolean values. I am sort of confused in the above definition. Can someone explain me what exactly does the above statement mean?
The marked question that has been attached as duplicate, I couldn't really understand since their is no associated example. The second answer does have an example but it's not really understandable. It will be great if any of you can add an example, albeit for a small value only. Thanks!
The bool type is at least 1 byte. It means it's at least 8 bits.
In a 'int' type, on a 32bits system, it's 32 bits.
You then have 32 booleans in 4 bytes with int, instead of 32 bytes minimum if you use bool type.
In an int you can store 32 booleans by basic bit operations : &, | and ~
I have a vector of bits, and I want to copy a slice of it to another vector (say, for simplicity, to the beginning of another vector). Note that all the bits may need to be shifted (or rather, rotated) in some direction, not just the first element, since the alignment of bits within each byte changes.
Suppose, for clarity, that the signature is:
void *memcpy_bits(
char* destination,
char* source,
size_t offset_into_source_in_bits,
size_t num_bits_to_copy);
And that data is stored in bytes, so no endianness issues, and the lower bits come first in the vector. We could make the signature more complex to accommodate for other assumptions but never mind that for now.
So,
Is there some hardware support for doing this (on x86 or x86_64 CPUs I mean)?
Is there some standard/idiomatic/widely-used implementation of this function (or something similar enough)?
First you have to define how the data is stored. Is it stored in an array of uint8_t, uint16_t, uint32_t or uint64_t? Is bit #0 stored as a value 1u << 0? You should probably not use void* but the underlying type that is used for storing the data.
Second, you can obviously assume that offset_into_source_in_bits is less than the number of bits in the underlying data type (if it's not, what would you do? )
Third, if that offset is 0 then you can just call memcpy. That's an important thing to do, because the following code won't work if the offset is 0.
Fourth, as long as num_bits_to_copy >= number of bits in the underlying type, you can calculate the next unit to store into destination using two shifts.
Fifth, if 0 < num_bits_to_copy < number of bits in the underlying type, then you need to be careful not to read any source bits that don't actually exist.
You'd probably want to be careful not to overwrite any bits that you shouldn't overwrite, and personally I would have an offset into the destination bits as well, so you can copy arbitrary ranges of bits. I might implement a memmove_bits function as well.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
static CBigNum bnProofOfWorkLimit(~uint256(0) >> 32);
That statement is filled with all sorts of magic. What exactly is it doing?
What does >> mean in C++ code?
For integer types, it's the binary right-shift operator, which takes the binary representation of its first operand, and moves it a number of places to the right. a >> b is roughly the same as a / pow(2,b).
That statement is filled with all sorts of magic. What exactly is it doing?
uint256 isn't a standard type or function; I'll assume it's a big-number type with 256 bits, with suitable operator overloads so that it acts like a standard numeric type. So uint256(0) is a 256-bit number with value zero.
~ is the binary negation operator; it zeros all set bits, and sets all zero bits. So ~uint256(0) will contain 256 bits, all set.
Finally, the shift moves those bits 32 bits to the right. So the top 32 bits will all be zero, and the remaining 224 bits will be set.
Assuming uint256 is a 256 bit unsigned integer type and the operators are defined as for the built-in types, this will:
initialize a 256 bit unsigned integer with 0
bitwise invert it (operator ~)
right-shift it by 32 bits (operator >>)
See Wikipedia on C / C++ operators
My guess is a shift. It's shifting the bits to the right, possibly by 32 bits. We can't say for sure without seeing the uint256 class due to c++ operator overloading.