It's hard to tell from the lack of context, but it appears as if your user is asking for feedback that the operation is over and that they should not repeatedly execute the event (such as push a button) to attempt to make your software work. Modern software is asynchronous and with the limited context, it seems like a very reasonable request to know when your operation has completed. I guess back in the day the UI thread would block while you were running your database update code on your UI thread and the fact that the application is now responsive again would tell you that the operation has completed and just didn't do anything.

As you learn more languages, you start to see where the C# developers copy all of their "innovations" from. They do it if it fits or not and if it makes sense or not. Sometimes they adopt the concept, but need to tweak the implementation in such a way, it loses a significant bit of the value it had in the original language. Global usings predefined by project type are my current favorite example. It seems like a matter of pride that C# has practically every feature they have seen in another language that they could make "work". The "magic" they add to the language allows someone to write far more logic in fewer strokes and a reader of the code has to understand exponentially more about the project type, all referenced libraries, and the code in every file if it looks relevant or not. With "global using" statements and extension methods, reading C# code snippets on line or even complete files can be somewhat meaningless without significant additional documentation describing the code.

I used to criticize MSFT. Then I built a few projects with NPM libraries and felt the true pain of uncoordinated independently maintained software tools and libraries from everyone wanting to contribute a weekend project and then move on. Suddenly MSFT seemed like the best thing every. One company to address security and ensure all of your dependencies are upgraded at the same time and work together is heaven compared to the past several years of "free" libraries. Who am I kidding, I still criticize MSFT. But a lot less now.

Greg, thank you for the reply. It looks like the reason auto makes this more efficient that I was recalling was wrong. Although my conclusion is somewhat the same. Rereading the AAA article, I picked out the point:

Quote:

It is efficient by default and guarantees that no implicit conversions (including narrowing conversions), temporary objects, or wrapper indirections will occur. In particular, prefer using auto instead of function<> to name lambdas unless you need the type erasure and indirection.

The same is true of C# if one uses implicit conversions as can be seen in the following code:

public class T1 {
int m_count;

public T1(int cnt) 
{
    m\_count = cnt;
}

public static implicit operator T2(T1 t1) {
    return new T2(t1.m\_count.ToString());
}

}

public class T2 {
string m_count;
public T2(string count) {
m_count = count;
}
}

public class Class1
{
T1 GenerateValue() {
return new T1(22);
}

void temp() {
    
    // The following creates an instance of T1, converts it to T2 and 
    // leaves T1 for the GC to clean up.
    // Is it clear to a developer that they just created this overhead?
    T2 t2\_implicit = GenerateValue();

    // The following creates and holds an instance of T1
    T1 t1\_explicit = GenerateValue();

    // The following also creates and holds an instance of T1
    var t1\_implicit = GenerateValue();
}

}

This means my original statement was in error. The reason we "benefit" from not using var has little to do with us not using structs. It is because we don't use implicit conversions on the vast majority of our classes/structs. So the potential "mistake" of accidentally forcing an unnecessary type conversion is minimal and is outweighed by putting type information at the developers fingertips.

Quote:

Although I haven't used C#, I'd be surprised if best practices for when to use the heap versus the stack weren't the same in both languages.

The thing that makes C# different from C++ in this case is that all memory created to hold instances of a class cannot be placed on the stack. Class instance memory is always placed on the heap and managed by the garbage collector (GC). On the other hand, a struct is always considered a value type and storage follows the same as it would for

Quote:

var is like auto in C++, right?

I used to think that. But I am not so sure anymore in terms of the net effect in each language. In our C# code, I demand that the type be determinable by reading the line the type is defined on. I.e. if a variable is initialized by a value returned from a method, you best not use var. The reasoning is not that a developer can't determine the type with enough effort. It is the time it takes someone reading the code to KNOW what the code is doing and meant to do. At the end of the day it is about developer productivity. Experienced developers aren't questioning if they can make something work or focusing on the time it takes to key in their code. It is how effective they are at solving problems and maintaining volumes of code. Using var is optimizing the writing of code at the expense of the total cost of the code over the life of the code. But, when moving over to C++ and understanding the design best practice of (Always Use Auto), I had to step back and evaluate why someone would recommend a coding pattern that made code take longer to understand and would drop developer productivity. In the end, I came to the conclusion that the C# patterns that we tend to use don't use structs, almost always use classes, and as a result, put the memory on the heap. In these scenarios there is no runtime benefit the compiler can help you with that makes your code more effective since all non primitive variables are just references. var only gives an opportunity to save time typing code at the expense of maintaining it. C++ on the other hand appears to prefer patterns where local variables do not use the heap and the compiler is both optimizing the implicit type conversion and if it can use a reference instead of a copy with every variable use. In the patterns I am aware of, it is minimizing the copying of data and the running of class move/copy/ctor/dtor methods for you. Without using auto here, the compiler's hands have been tied. All of that being said, I would like the input of those who have written a lot of modern C++ to see if I am missing anything. I also believe that if our C# code used structs that had implicit type conversions more, the reasoning of not allowing var may be misguided. Although I have not pulled on this thread and do not know much about the C# compiler optimization in these cases.

Packt is very inexpensive if you get their annual membership. But I have found you get what you pay for. I had the membership for 1 year and read many of their books. But they are nowhere close to the value of college textbooks despite being 1/20th the cost (per book). I found that most of their books appear to be written by "non-experts" who look to be sharing what they have learned so far on their journey and mistakenly believe that they have an understanding of the scope to properly create such material. An easy mistake to make since we don't know what we don't know. On the other hand, I am currently working through a college textbook. The book I am reading now cost more than the entire year of packt unlimited reading. BUT, it is many times the value and taking far longer to read and work through the assignment to ensure I have mastered the material. I had read a book claiming to cover some of the same material from Packt. At the time I thought I was learning this material. But in the end I was left with tidbits of knowledge I didn't have before but zero mastery over the domain I had read the book for. In the end, if you are attempting to master a topic that others have mastered, I think you need to get material and a curriculum from an organization that both has mastery of that topic and taken the time to work through how to get someone from a starting point to an ending point. Most Packt books I have read are equivalent to having a long lunch with someone who presumably knows more than you about a subject, but is not necessarily an authority on the subject, and having them give you bits of advice that may improve your skills in some way, but not give you expertise or a plan as to how to become an expert. On the other hand, it is a lighter experience for those not motivated enough for university level learning but who do want to improve. i.e. better than doing nothing. You might also decide to read RFCs. These can be long and dry, but will leave you with expert knowledge.