Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I was sticking on Unity for a while, without knowing much about Computer Science/Performance management.
Now, I took some C++ experience, with some concerns on IO/performance/etc some "Computer Engineering" stuffs.
Then I got back to my old Unity project, which had no concern about those thing at all, and found out that there is ref(or out) keyword for call-by-reference, as I could do in my C++ project.
Is it common to use ref(for call-by-reference purpose) of C# on 'business level'?(maybe game companies with Unity?)
If you come from C++ then you have this thought in your head that you need to pass references, because if you don't, the whole object will be copied and most likely that is bad (tm).
In C#, types are either reference types or value types. Reference types are passed by reference automatically. If you pass a class, it can be null, so it must already be a reference to the actual class instance (or in C++ terminology a "pointer", because references in c++ cannot be null).
All classes are reference types. You don't need ref or out for performance reasons ever. If you find yourself using ref or out for performance reasons on a struct, that should be your clue that it should be a class instead.
So no, using ref or out is not common in C# at all. It is only used sparingly, in the places where you would not get the desired result without it. Those keywords are not meant for performance considerations.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have been working on a project in Unity, and was trying to figure out how to abbreviate a large number into a more readable format. I found somebody who asked the same question and got some code, but the person who gave that code had 2 classes in the same C# script. I am new to Unity and C# in general, so this was not something I had seen before.
What I would like to know is when to put classes in different scripts, when to put multiple classes in the same script, and if I do put multiple classes in the same script how that affects that script and other scripts in the project.
From a C# logical point of view, it does not matter where a class is. From the practical perspective, it is usual to put every type (class, struct) in its own code file. I often make an exception for enums and put enums belonging to the same realm into the same file, e.g. things like DisplayStyle, SortOrder, Visibilty could be in a file named AppearanceEnums.cs. Enums are mostly small and don't contain logic.
for Unity, see: How to architect code as your project scales
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I am an experienced C# developer, and I just started asking myself something.
I've read a lot about differences between C++ and C# in game development.
Almost everyone said that C++ is better in game dev because it can directly access memory through a pointer. As far as I know, C# can also use pointers if the unsafe keycode is used.
So, that means that C# can also directly access memory. And then the question comes again, what is the difference between the C++ pointer and the C# pointer? Is one better then the other? If there are no differences, why would C++ be better than C#?
(I know from my own experience that I've had problems with the C# garbage collection, so I thought that this might be the reason C++ is preferred)
I'll say that the weak point of C# is that, given a void* pointer, you can't always cast it to a MyStruct* pointer, and surely as hell you can't cast it to a MyStruct[] or a byte[] (and the array type is one of the basic types of .NET, and is used pretty much everywhere). This makes interop quite difficult and slow, because often you have to first copy from a void* to a newly created MyStruct[] just to be able to use the data in .NET.
The alternative clearly is working everywhere with pointers in C# (you can probably do it) and minimize the use of arrays [], but the languages isn't built for that. For example the generic subsystem (List<T>) doesn't accept pointers (you can't List<int*>). You can clearly use IntPtr... but then you have to cast it to int* when you need a int*... it is a pain.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I want to use a c++ project to do some calculations for a c# project and return the results.
I was wondering if I would benefit a more efficient calculation speed in c++ if I do so?
Would still be efficient if I wrapped the native code in c++/cli?
Are there any examples out there?
Just as simple example say you have two double values A and B in C#, how would you have c++ project to receive A and B and a string value "plus" or "times" to calculate and return A + B or A * B?
Use Process.Start(); to spawn your optimized program. You will be able to pass parameters and even read the output. Start here: https://msdn.microsoft.com/en-us/library/53ezey2s(v=vs.110).aspx
You've got two separate issues in your question: "How do I", and "Should I".
If you're having problems with the "How do I", please post a question with the specific code you have, and what problems you're having.
"Should I" is somewhat of a nebulous question: It depends a lot on the type of calculations you're trying to do. These questions often have no one right answer. (Also note that this type of question is often offtopic for Stack Overflow for that very reason, so this question may be closed.)
For some types of calculations, the C++ compiler might produce more efficient code than the .Net Jitter. For some types, it won't make a difference. C++ would also let you do things like using the GPU to perform the calculations.
Also, consider how long it will take you to write this optimized code, and how often you're going to run it. If this needs to run overnight once a month, maybe a couple hours to run is fine.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm learning C# recently with a strong C++ background, and there is something about C# that I don't quite understand, given my understanding of and experiences with C++.
In C++, people do care a lot about uniformity, otherwise it would be impossible to write generic code using template meta-programming. In C#, however, people seem to care little about uniformity. For example, while array types have a Length property, List<T> uses Count. While IndexOf, LastIndexOf, and alike for array types are static methods, their counterparts for List<T> are not. This gives me the impression that instead of being uniform, C# is actually trying hard to be nonuniform. This doesn't make sense to me. Since C# doesn't support template meta-programming, uniformity is not that important as in C++. But still, being uniform can be beneficial in many other ways. For example, it would be easier for humans to learn and master. When things are highly uniform, you mater one, and you master it all. Please note that I'm not a C++ fanatics nor diehard. I just don't really understand.
You've got a conceptual issue here.
List<T>, and the other collection classes with it, aren't C# constructs. They are classes in the BCL. Essentially, you can use any BCL class in any .NET Language, not just C#. If you're asking why the BCL classes differ in certain ways, it's not because the designers disrespected or didn't want uniformity. It's probably for one of (at least two) reasons:
1) The BCL and FCL evolved over time. You're likely to see very significant differences in classes that were introduced before and after generics were added. One example, DataColumnCollection, is an IEnumerable (but not an IEnumerable<DataColumn>). That causes you to need to cast to perform some operations.
2) There's a subtle difference in the meaning of the method. .Length, I believe, is made to imply that there's a static number somewhere, where .Count implies that some operation might be done to get the number of items in the list.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Can anyone tell me what would be more efficient: A large program is written in visual-C++ years ago is now intended to be written in C#. What would be better, re-writing the whole code of visual-C++ in C# or write C++ DLLs to be used in C# program via DLLimport?
I guess it depends on how data-centric your code is. If you can easily separate out the functionality that does not require an interface, then you'd most likely be better off writing a DLL to utilize this functionality, and then re-writing the interface in C#.
If the program is rather interface heavy, and you do not want to go through separating out all of the data functions, then I'd just go ahead and re-write the whole thing in C#, although I'd expect to lose some performance.
VisualC++ is still a very widely used language - is this your only reason for wanting to move to C# (i.e. finding it hard to recruit people, lacking skills to continue development)?
There is only a single answer to this: "it depends". We cannot possibly know this, it's something you must decide.
Check what you need in terms of time and other resources for both. Check what benefit your gain from both. Weigth cost against benefit. Decide.