Visual C++ should be given way more attention and real developers, who know and understand it, won't be forgetting about C++ for a long long time. VC++ needs to support WPF & WCF, support writing web applications with Visual C++ code-behind and support the Data & DataSource support the VB.NET and C# have thoughout the life-cycle of VS.
Additionally Visual C++ needs InteliSense enabled when working with /CLR not just native based work! Truly, this is atrocious in its current state. C++ should always be kept on the forefront, because it will always be the best, until C# re-writes and mimics everything C++ already could do and will do. Visual Studio/.NET should have the languages in this order, Visual C++, Visual C#, VB.NET / F#.

Make an option that will have the garbage collector (GC) when moving/freeing up memory clears out the memory location with a string of 0s, 1s, or random bits to remove the contents from memory.

Another option would be to have a SecureObject attribute that would tell the GC that this object needs its contents cleared in memory when collecting/moving it.

This would help out with the processing of sensitive information, especially when working with immutable strings.

I do understand that these options would produce a performance hit, but this would not be the default action of the garbage collector and is an opt in functionality.

I find it very useful arraySegment, but I need a class "sister" to extend its usefulness. It allows me to use an array without copying data.

The current Absolute ArraySegment:
it's Aboslute. If Array have 20 items, If offset it's 5 and count it's 10, Still I have to tell you the absolute pointer when working with him.
To indicate the element 7, I have to write Myas(7).

The proposing Relative (new) ArraySegment:
When I point to the 7th element in the array and since the ArraySegment, Offset was 5, I should indicate this Myas (2) not as Myas (7).

To complete this class should also to permit to the property offset to be of reading and writing. Currently, It is defined only when the instance is created.

When overriding GetHashCode, best practices say to use inmutable object properties or else collections using GetHashCode to improve performance on searches won't work properly. That is of course, understandable.
But the facts of the matter are:
1. Performance is not in the semantic nature of a collection. Believe me, I love good performing collections, but they are not there to perform wonderfully, they are there to collect, to allow searches and comparisons among collected objects, etc. And, the point is comparisons between objects is not semantically restricted to inmutable objects, comparison (equality or any other) guaranties a result on the moment when the comparison occurs, not before, and certainly not after. So, a constraint to gain on performance, that is, HashCode must be inmutable, turns into a constraint on Collection Semantics.
2. Some (most I would not say, I also like totally or partialy Imutable objects) objects are completely mutable in nature, there is no patch free manner in which to make them at least partly inmutable!!!! And sometimes I want to collect some of this objects, and perform semanticly correct collection operations whit them.
3. You may say, when using totally mutable objects, don't use good performing collections but instead use poorly performing collections. And hey, you are right, if it were up to me, I'd do it, I'd sacrifice a litle performance for some semantically correct application. But, if I'm using, lets say, EntityFramework? What collections does EntityFramework uses to keep track of entities? What about other frameworks shipped with or around .Net Framework. I've been debuggin some code that relies on EF and GetHashCode actually gets called on entities, so I'm asuming entities are stored on good performing collections that rely on object inmutability. You cuold say, "Wel then don't use EF or any other framework", but hmph, that actually would be a litle bit of a problem, no?

So, my proposed solution would be this:

Define a way in which an object notifies anyone interested every time it's hash code changes like this one (or any other, it is not that important):

delegate void HashCodeChagendEventHandler(int oldHashCode, object hashCodeOwner);

Add an event to Object like so

public class Object
{
......

public event HashCodeChagendEventHandler HashCodeChanged;

protected virtual void OnHashCodeChanged(int oldHashCoge)
{
if(HashCodeChanged != null)
HashCodeChanged(oldHashCode, this);
}
}

and then define the next two best practices:

1. Any class (Collection or similar) relying on GetHashCode to store elements, should liste to the HashCodeChanged notifier. When it gets signaled, it should inmediatly remove the object from the old bucket (with oldHashCode parameter) and place it in the new bucket whith hashCodeOwner.GetHashCode().
2. Any class overriding GetHashCode and basing its implementatios on mutable properties should raise HashCodeChanged any time a change on this properties (provoking a change on GetHasCode()) occurs.

.Net, of course, should follow its own best practices.

- This way, the inmutable constraint on properties involved in calculating GetHashCode is removed, and Collections ara always semantically correct and good performers.
- Really, good performers? What about the extra remove and add operations execution any time a property changes?
- Well, this executions really does not affect Collection operations, but properties change operations, so the collections are still good performers.
- But what about the change operations, do they perform poorly then?
- No, no really, at least usually. A property change on an object should trigger both a remove and an add opperation on every collection that contains it. But usually, on collections using GetHashCode to store objects, this operations are O(1), without taking into account the cost of the GetHashCode operation per se. So, if your GetHashCode operation is not a costly one, there is really no impact on performance.
- And if the GetHashCode operation is a costly one?
- Then you, as a programmer, must decide. You'll be here in the presence of a tradeoff between good performance of object's properties changes or semantic correctness of Collections. If you choose the latter, simply follow best practices and raise the HashCodeChanged event every time a property changes (causing a change on HashCode). If you choose the former, then do not follow best practices, dont raise the event on properties changes. You have control at least, and may decide depending on the scenario.

¿Is this to difficult to implement?

Most of our program works great in 64bit mode, and a few areas must be run in 64bit on 64bit computers. However, once in a while a 3rd party library (Quickbooks SDK for instance) has to be run in 32bit mode in order to work. So I either have to convert the whole thing to x86 only, or I have to write a completely separate program just to interact with the 32bit only libraries.

It would be nice if I could just designate a chunk of code and tell Visual Studio "this area is run in 32 bit mode" so that lazy companies with out of date drivers aren't holding back the move to 64bit.

This could either be the equivalent of a 32bit class library, or a special function type:
Public 32bit Sub StupidDrivers()

- I write a Windows form application in C# for editing colors that I publish it and I like to allow the users to acquire colors from anything on the screen with just a couple of clicks.
The simple and the elegant way in my vision is to create a transparent top level window where the user can select the desired area from which the application can extract the average color, but Unfortunately when the form "TransparencyKey" is used, the mouse input is redirected to the window bellow. Anyway I built this facility for testing by exploiting a bug and it work beautiful but the bug don't work on any computer...
- I also build for my self a "digital" clock with the digits painted on a transparent background. The window has no borders and the lines of the digits are difficult to be aimed with the mouse so the window must be griped for dragging around the digits and again due to the input redirection this is not possible.
This are two examples of genres of applications that can take advantage from not redirecting the input in case of using the "TransparencyKey"
I ask my self if it is not possible to be introduced by Microsoft a switch to enable or disable the mouse input redirection. I believe that This will facilitate many other applications...

The currently existing remainder operator behaves the following way: the remainder may be negative if the dividend is negative. While this corresponds to the way it's taught in the school, this way is not particularly useful when using this operation in real-world applications.

The more useful way would be to have an operation (Math.Modulus?) which behaves the following way: the modulus is always a non-negative number not greater than the absolute value of divisor.

This function would have advantage over the traditional % operator.

Example 1: the check (x mod 2 == 1) would be true for all odd numbers whereas (x % 2 == 1) is true only for positive ones.

Example 2: f(x) mod N is a good hash value (guaranteed to be in 0..N-1 range), so one can use it as an index into an array without checking for negative values. In general, the suggested behaviour of mod is consistent with the array index behaviour in C# and other popular languages.

Example 3: the x mod N function is periodic on x, so it's useful in for e.g. normalizing argument for trigonometric functions and so on.

There are sources in Internet suggesting the advantage of the modulus operator:

* http://blogs.msdn.com/b/ericlippert/archive/2011/12/05/what-s-the-difference-remainder-vs-modulus.aspx about equivalence relation the mod operator would introduce
* http://social.msdn.microsoft.com/Forums/en/xnagamestudioexpress/thread/f68c05bd-9822-4c88-b56c-ed9de837b2c7 about using as array index
* http://stackoverflow.com/questions/478721/in-c-how-do-i-implement-modulus-like-google-calc-does for calculation of a canonical angle (in the range [0..360))
* http://stackoverflow.com/questions/10065080/mod-explanation for using as index
* http://stackoverflow.com/questions/9083189/i-need-positive-modulus-for-array-index-iteration again about array index