You got it... the real purpose was to have a Range<0, 9>. That's something I can easily do in C++ templates... and it would avoid enums altogether... and also classes that act as enums.

The real class implements IEquatable and IComparable. I simply didn't want to make the code to huge for this discussion. And, even though Marshal methods aren't marked as unsafe they are, by definition, unsafe. In fact, reflection itself is not called unsafe, although you can create empty instances of classes that do not define default constructors and the like...

Question... if I have an array of my struct... the array itself is readonly... yet I can modify the contents of the array... should I mark the class readonly because I never replace one array by another, or not, as there are mutator methods to change the contents of the inner array?

Thanks, I forgot I can make the entire struct final. Yet, I wouldn't get rid of the backing field... I don't like to make a class/struct use property getters instead of using their fields directly... that's really a personal choice. In any case, I will mark the struct as readonly. Thanks for reminding me of that!

The title os this message might look like a joke, but it is actually very serious. The other day I wanted to implement my own BigInteger class, and I was using bytes as the backing fields. Yet, I would only use values from 0 to 9 for each digit. Bing AI suggested me to create an enum with values ranging from D0 to D9 (I think their actual values are obvious). Yet, using an enum like that doesn't forbid users from doing things like (DecimalDigit)56 and pass 56 to an enum that was only supposed to support values ranging from 0 to 9. Of course I can validate the values at run-time... but the entire purpose of using an enum was to avoid mistakes like that. So, my solution was to create a class (in fact, a struct, but a class serves the same purpose) that has a private constructor, and has public static readonly fields ranging from D0 to D9. This way, users outside of the class, except if they really want to mess up (like using unsafe reflection) cannot pass values that aren't in the 0-9 range. This also reminded me of a job where we had one enum with like 20 values... and then, many, many, many switches to get the many different traits of those enums. Wouldn't it be better to just have classes, with all the traits, and use the classes? Aside from the use of the enum in switch statements, they work the same in most cases, work even easier in cases where we usually had to use helper methods... and if a new trait is added, we have a single place (where the enum values are declared) to fix... with no chance of "forgetting" a case in a switch somewhere else. What do you guys think? Example:

public struct DecimalDigit
{
public static readonly DecimalDigit D0 = new(0);
public static readonly DecimalDigit D1 = new(1);
public static readonly DecimalDigit D2 = new(2);
public static readonly DecimalDigit D3 = new(3);
public static readonly DecimalDigit D4 = new(4);
public static readonly DecimalDigit D5 = new(5);
public static readonly DecimalDigit D6 = new(6);
public static readonly DecimalDigit D7 = new(7);
public static readonly DecimalDigit D8 = new(8);
public static readonly DecimalDigit D9 = new(9);

private DecimalDigit(byte value)
{
_value = value;
}

private readonly byte _value;
public byte ByteValue
{
get => _value;
}
}

// vs

public enum DecimalDigit:
b

That's an API problem, not really related to null or not null, but the fact that .NET DB drivers assume "null" as unset, and DBNull.Value as real null (WPF did it a little better, as we have Unset as a separate item, and null really means null). You can probably create a helper/extension method that converts null to DBNull.Value and it should work fine. I also consider it very bad that IDataParameter always box value types. It shouldn't need to do it, as I can clearly tell by working on C++ drivers that primitive types can just be primitive types and never "boxed" or similar there.

You can debug exceptions when they are thrown. This means you stop even if there's a catch block that's going to "eat" the exception. Or, you can debug only exceptions that are uncaught or are rethrown. In this case, if there's a catch clause, you will not see the exception until it is rethrown (if it ever is rethrown). Usually on the second case, an exception that kills the application will not give you a chance to debug it. On the first case, you usually have that option (and for an exception throwing another exception, throwing another exception you would be bothered thousand of times before the app is killed).

Would be a handy feature, if it stops hittings trees on the way to the hospital.

Are you catching exceptions when they are thrown or only after they are dealt with? If it is the latter, I think that even if you want to catch StackOverflowException's, it will not work because there's no more stack to let you do anything and it is probably using something like Environment.FailFast(). [Environment.FailFast Method (String) (System)](https://msdn.microsoft.com/en-us/library/ms131100(v=vs.110).aspx)

I completely agree with you. In fact, there are ORMs that allow set based operations (the WHERE part of a LINQ select can very well be used in an update).

C++ is far from a safe language. Specially if you need to deal with many DLLs, maybe compiled by different C++ compilers. Most of the safety features of C++ are only safe in the context of a single binary or maybe different binaries built by the same compiler. In fact templates in general (used by all kinds of "safe pointers") suffer a lot of optimizations that may break across binaries. So, is it safe now? Well, it has much more safety features than in the past. But those are not 100% guaranteed in all scenarios and, well, you can ignore them at any time.

1. On Mac/Chrome, if I go slowly from a menu to the items, the menu disappears. I need to move fast enough to make the precision lose some pixels... which is becoming harder with more high resolution mouses etc; 2. There's a warning that I have a message.. but when I click on it, I see a page saying: No new messages. (or notifications... I don't care about the word)

It's actually different. Some bad articles get lots of good votes (it doesn't matter if by friends or because some people really like bad articles). But in this case the article has really BAD votes.

Why Type = 'Produce' became item.Type.Contains("Produce")? Shouldn't it become item.Type == "Produce" ?

Hehe... OK. I thought I was another coding horror... you know, complete lack of testing.

I thought he copied the code and changed what he wanted to preserve identity... So, it must be part of the real one. I think.

Did you notice this?

List.Add(N1 + "," + N2 + "," + N3 + "," + N3);

N3 is added twice. N4 is never added.

Actually that's quite possible. Maybe it shouldn't be and they shouldn't be called engineers, but there are lots of self-called "Engineers" that actually barely know how to code, yet they are able to talk a lot on how to write maintainable code, unit tests etc... but somebody else probably needs to write the code for them if they are doing anything more complex than a "Hello world" application.

B.S. programming degrees vary a lot according to university, region etc... Today there are many universities that tell all about OOP, SOLID principles etc and yet the teachers themselves don't know much about algorithms... so you cant assume one is self-taught and the other isn't.

It is not a matter of calling Dispose or Close in the catch. The problem is that you have an eternal loop and, inside the loop, you have a try/catch accessing an object that may be disposed. That means: You start running it OK. As soon as the client disconnects, you receive an exception, you catch it, maybe you close/dispose objects, it doesn't matter, the loop runs again, you try to access a disposed object, you get a new exception, you catch it, you dispose again (nothing changes) and you run again... infinitely. So, with a while(true) and a try/catch inside the while, you will always make the application consume 100% CPU when you have as many disconnected clients as you have CPUs (that is, on a 4-cpu machine, the CPU will go up to a total near of 100% as soon as 4 clients disconnect, as you simply don't allow the code to exit the eternal loop).