Brother Bob

I believe it would be like this.

int (x::*mypointer)[10] = &x::arr;

x xObj;
int *p = xObj.arr;

It will pass the check for five of a kind, because you don't check if the three's are different from the two's. That may not be a problem if the rules allow for five of a kind to also be used for a full house, but keep that in mind.

You can also merge the two statements by checking if the first two are equal, the last two are equal, and finally if the middle one is equal to either the second of the other values. This allows for an easy check that the three's and the two's are different.

if(
    dice[0] == dice[1] && // first pair
    dice[3] == dice[4] && // last pair
    (dice[2] == dice[1] || dice[2] == dice[3]) && // middle must be equal to either pair
    dice[2] != dice[4] // exclude five of a kind where first and last pair are equal
) {
    ....
}

But I would try to code some general pattern matching method so that you don't have to hand code this at all.

Ultimately, you have a fixed depth buffer precision that has to be distributed over the full Z-range from the near clip plane to the far clip plane. The further away you put the clip planes from each other, the smaller the depth buffer precision and consequently the ability to distinguish objects close to each other.

However, the way the precision is distributed, it is the ratio of distances that matters. In practice, if the far clip plane is sufficiently large, then everything is determined by the relative of the distance to the near clip plane alone. So often the far clip plane doesn't matter much, but the near clip plane is extremely important to get correct.

So in practice, it often doesn't matter much for situations such as in your example, but there is a tiny difference in that a larger far plane distance is worse.

Rattenhirn is probably overlooking the mistake you likely made in your code where Some_Other_Class(first); does not create an unnamed temporary object, but a default constructed named object called first. I don't believe that is what you intended, and what Ratthenhirn assumed.

Under the assumption that you intended to create a second object with a reference to the first object, then his explanation is correct.

Your string is not null terminated and so the stream is printing whatever follows the last element until the first null character. Add a '\0' at the end to mark the end of the string.

It's difficult to help "optimize" code when you don't know what the code is doing and what the dimensions of the variables are. Make a complete example with actual values, but with manageable sizes, such as just 10 rows instead of 200000.

It is undefined. The -> operator is defined in terms of a dereference and the . operator, so you are clearly dereferencing a null pointer which is undefined behavior.

From a practical implementation point of view, no actual memory access may be performed to actually cause a crash, but your code is nevertheless ill-defined.

afaik the initial value is compiler related and not defined in standard. so you can't be sure 100%, but basically most compilers do it this way.

No, empty values in containers are value initialized, and value initialized primitive types (such as pointers, integers, floating point values and such) are required by the standard to have a zero value. This is different from default initialized values, which is undefined for primitive types.

From what I can decipher, it processed 8 consecutive 3x3 blocks per iteration. Therefore, you move left by 8x3=24 bytes, the width of 8 blocks, per column-iteration, and down 3 rows, or 3x width bytes, per row-iteration.

Let's just take a small image with some sensible numbers. Here's a 10x10 image, and the numbers represents the indices into that image.

     0     1     2     3     4     5     6     7     8     9
    10    11    12    13    14    15    16    17    18    19
    20    21    22    23    24    25    26    27    28    29
    30    31    32    33    34    35    36    37    38    39
    40    41    42    43    44    45    46    47    48    49
    50    51    52    53    54    55    56    57    58    59
    60    61    62    63    64    65    66    67    68    69
    70    71    72    73    74    75    76    77    78    79
    80    81    82    83    84    85    86    87    88    89
    90    91    92    93    94    95    96    97    98    99

In this case, width=10 and height=10. As you can see, no matter which pixel you are at, if you add width to its index, you get to the next pixel below it. Similarly, if you subtract width from any index, you get to the pixel above it.

Take the pixel at coordinate (5, 4) which has the index 45. If you want to go down one pixel to the coordinate (5, 5), you add 10 to 45 and you get to index 55, which is the index at coordinate (5, 5). If you thus have a pointer p=&image[45], then p[width] references the pixel width units from p, and thus reaching the pixel below it.

Use std::vector::back().

MatStack.back() * differentMatrix

One constant belongs to the core API, and one belongs to an extension due to the ARB-suffix. They are probably defined to the same value, but that does not mean that you should mix them. If you're using the vertex buffer functions from the core API, then you should use the standard constant. If you're using the ARB-variant of the vertex buffer object extension, then you should use the one with the ARB-suffix.

On a second thought, the derivation of an optimal solution could have been much easier, so I'll just throw in another point of view just for the sake of it.

Given the notations from my last post, treat v_n as a sample of a three-dimensional random process. Its distribution is dictated by the covariance matrix C and can be estimated by C=V*V^T. You want to find the direction of least energy of the distribution, which is the direction that is perpendicular to the plane where the random samples are located. As in my previous solution, that is the eigenvector of V*V^T with the smallest eigenvalue.

If vertices is an object of type std::vector, then &vertices is a pointer to the std::vector object and not the data the std::vector stores. To get the pointer to the data, you need to use &vertices[0], or, if you're on a C++11 compiler, vertices.data(). Same with the color array, of course.