You are welcome.

It is not very difficult to get rid of this 2D array. 1) replace it with a vector m_bitmapData; 2) Replace any reference to the old BitmapData array as follows: BitmapData[x][y] should be replaced by m_bitmapData[x + m_PixelNumberX*y] 3) In SetBitmapDataSize allocate the new array by m_bitmapData.resize (x * y); Change the function interfaces accordingly. Should be really easy.

I would neither store nor return the bitmap data in that way. What you are creating here is a so-called "ragged" array, in which each row can have a different length. In a bitmap this luxury is not needed, all rows are of equal length by definition. Therefore a one-dimensional array is good enough and in some regards even superior. a) A one-dimensional array can be allocated in one chunk (whereas your ragged array needs N allocations, N being the number of rows) b) A one-dimensional array does not incur the overhead that comes with a ragged array, which is easily 3 x 64bits per row. To access the members of the one-dimensional array in a 2D fashion, simply use the algorithm:

index of pixel (x, y) = x + y\*pixelsPerRow

As a return value for your access function I would suggest you use a simple pointer (const COLORREF*). For the caller to know how to access that 1D array you should provide addition access functions for the number or rows and number of columns.

Two things: You are not really adding noise, but just setting a pixel to black here and there. The idea of noise is to modify all color components of all pixels by adding a random value (plus or minus). So, start off by using a random number generator like rand(), scale its return value to the amount of noise you want and add the outcome pixel by pixel. You may think of it as computing a noise image and adding that image to your original image. If you want to refine that, don't use equally distributed random numbers, but gaussian distribution or others. And you may apply filterind (low-pass, higo-pass, etc) to the noise image before adding to modify the spectral distribution of noise.

Nice find!

I guess so. And you guys certainly get even more of the subtle points that we non-native speakers miss out on. It was definitely this subtle humor that made it so much more attractive than many of today's comedies. If they are ever going to do a remake I hope they can transport that fine kind of humor.

I doubt they can re-do this in our times. This series was simply too funny and one of my favorites -- although (or because) I am not from the UK.

I think the real little brother to pair programming is called peer reviews. While in car racing it is important to get the job done in record time, in programming we have a more relaxed schedule. So why not let one person start the job and bring the other in when the first one thinks he/she has everything in place. For some really critical parts of code that are extremely hard to test, we have experimented with pair programming -- without even having a name for it. And the results were not bad at all. It's just a little expensive for every-day code.

You might also consider working with a vector and storing the index values. Vectors are not all that bad as their reputation. See this recent article for an interesting comparison to linked lists: Number-crunching-Why-you-should-never-ever-EVER-us With an index value you definitely know that it will always fit into the data cell of a list box.

Sounds very intelligent. But isn't it the same as saying: Nobody want to learn how to drive. People just want to learn how to get somewhere?

Eventually you will have to learn all of them, at least to a certain depth. On which ones you will need more depth depends on where you are going to end up in the industry. So you can as well start with any of them, as long as you find it fun to work with them. When you like a subject and are well motivated your learning process will be a lot faster. So start with the things you like most and try find a job in which you can play these cards well. In the course of your life you will detect that you might like some of the other subjects as well and pick them up. New technologies will show up, and some of the existing ones will turn out to be no longer a factor. One general tip: No matter which area you will work in, good software design work is always a big advantage. That doesn't necessarily mean that you should learn UML first. It is more your the attitude towards software design than the tool you are working with. Good luck!

This article: The Art of Win32 Shellcoding is in my opinion a tutorial about how to write malware. I think that such articles do not belong into a forum like this, where people are looking for productive solutions to real world problems. Perhaps an administrator of this site can look into this.