|
I'm very surprised to see this many users of .NET considering how quickly MS has changed from VS 2002 -> 2003 and now 2005 is on the horizon.
It's hard to both support existing applications written in VS6 and create products under new(er) VS 200x when changes occur this often. Granted, the change from 2002 to 2003 wasn't too extreme; yet each time there's a change it requires support on more configurations which is always a problem.
Also, the loss of intellectual property poses significant risks as bypassing license protection and just flat out reverse engineering is very easy under the .NET environment.
The 3rd party products that I've evaluated to help simplify our task (such as plotting/charting and menus) seem to run very slow (I assume because of license or license management?).
I wonder, of the 63% or so, how many of these are "internal only" and how many release to the general public?
Supporting a controlled number of internal applications is much easier than supporting/releasing to the public at large.
Internal applications do not require protection against IP loss either.
|
|
|
|
|
My 100KB program use up hundreds MB ram, really slow down the system, once a while it will drop down to 20- MB ram. Thanks to .NET GC.
eric feng
www.infospec.com
|
|
|
|
|
I use C# and don't have those kinds of problems. Have you tested the app on other machines? That sounds weird to me. 
Happy Programming and God Bless!
"Your coding practices might be buggy, but your code is always right."
Internet::WWW::CodeProject::bneacetp
|
|
|
|
|
|
Yes, I use a lot of System.String, also use a lot of sql queries, but I free the datarows right after I finish the job. My program is a server, it handles client requests, even the all the clients disconnected, the memory usage is not decrease, until some time (don't know when) system will free those memory, some time after 5 minutes. I think that is called "GARBAGE COLLECTION", right?
eric feng
www.infospec.com
|
|
|
|
|
|
There is an known issue in .NET titled "FIX: You experience high CPU usage and other problems when you run a .NET Framework 1.1 application" (http://support.microsoft.com/?kbid=828698), which might be related to your problem. I myself don't have the problems you experience, but I am sure that when you search on Microsofts web site or contact them you will find help.
|
|
|
|
|
Holy, this one is so helpful. Thank you.
eric feng
www.infospec.com
|
|
|
|
|
My 100KB program use up hundreds MB ram, really slow down the system, once a while it will drop down to 20- MB ram. Thans to .NET GC.
eric feng
www.infospec.com
|
|
|
|
|
In C++, it it fairly well known that one should never write statements like "using namespace std;". In order to reduce naming collisions, one is supposed to import specific names like "using std::cin" or "typedef std::set<CString> CStringSet". So why is it considered OK in .net to write the "using namespace std;" type statements? I refuse to accept the "It's OK to use the wrong tool because we don't have the right tool." arguement. If .net doesn't provide the right tools, it's a reason not to use .net.
Nathan Holt
|
|
|
|
|
OK, it is pretty obvious that I am a die-hard C++ fan, but let's try to be fair here 
using directives are evil in header files, because header files can be included by many different cpp files, and that beats the purpose of namespaces and can lead to name clashes. However, it is quite OK to put using directives in cpp files, because it does not affect other compilation units.
Now, if we want to have some kind of analogy with .NET, I would say that *.cpp files roughly correspond to *.cs files, and *.h files correspond to .NET metadata, which is generated by compiler(s) rather than handcoded. A C# programmer will always put using directives in a *.cs file - he cannot put them in metadata even if he wants to.
|
|
|
|
|
Nemanja Trifunovic wrote:
using directives are evil in header files, because header files can be included by many different cpp files, and that beats the purpose of namespaces and can lead to name clashes. However, it is quite OK to put using directives in cpp files, because it does not affect other compilation units.
Of course both the "using namespace std;" and the "using std::cin;" are evil in header files. My understanding is that "using namespace std;" is evil everywhere, because can import anything defined in the namespace, which can be much more than the #include statement would imply. In a cpp file, it is OK to use "using std::cin;" because that only affects the specific file. I still don't see that this would be different in .net.
Nathan Holt
|
|
|
|
|
Nathan Holt at CCEI wrote:
My understanding is that "using namespace std;" is evil everywhere, because can import anything defined in the namespace
Yep, I've heard that opinion before. For instance, Herb Sutter advocates this approach[^]. But he says Using directives should be avoided entirely, especially in header files which at least means they are "less evil" in cpp files. On the other hand, you will see that Stroustrup in his examples[^] uses using directive all the time.
In my workplace, we forbid using in header files, and that seems to be enough. In rare cases where it causes problems within a cpp file, it is easy enough to discover and fix the problem quickly.
What I really like about C++ is the possibility to put a using directive inside a function - AFAIK this is missing in .NET
|
|
|
|
|
Nemanja Trifunovic wrote:
In my workplace, we forbid using in header files, and that seems to be enough. In rare cases where it causes problems within a cpp file, it is easy enough to discover and fix the problem quickly.
I guess the using directive isn't as evil as I thought, though my instinct is still to stick with typedefs and using declarations for C++.
Nemanja Trifunovic wrote:
What I really like about C++ is the possibility to put a using directive inside a function - AFAIK this is missing in .NET
I can certainly understand missing that!
Nathan Holt
|
|
|
|
|
Nathan Holt at CCEI wrote:
though my instinct is still to stick with typedefs and using declarations for C++.
Stick to your instict by all means. I never said it was bad. The bad thing would be exactly the opposite thing: to become too relaxed about using directive and start putting them into header files. All I want to say is that using directives in cpp files (especially within a function) are not nearly as bad as the ones in header files.
|
|
|
|
|
If you don't like it, never use using
and always use complete name like System.String, that's not a problem 
although much cumbersome.
Also the C# compiler would warn you if there is any ambiguity, in fact ambiguity is a compilation error
|
|
|
|
|
There are two issues involved here.
1. Code readibility
2. Making the compiler happy
Both are needed but the first one is IMHO, much more important. When I code, I prefer to use "string" rather than "std::string" or "System.String" anyday. And of course, the same as when I read/debug someone else's code. I see that as the main objective behind the using directive. So I use it all the time, in both C++ and .NET. If there's a problem, such as a name collision, the compiler will let me know and I'll take care of it. I just prefer to make the compiler work to make me happy rather than me work so the compiler is happy (by avoiding the using directive in the remote chance that there's a name collision).
Now, on the C++ side, I've always added "using namespace std;" at the highest level the compiler has allowed me (with no fuss). If I can stick it inside the precompiled header, great! It's one line of code in one place and I never have to repeat it again -- how liberating! I know it goes against the "norm", but, like I mentioned, I prefer to let the compiler do the work of figuring out if there are naming collisions instead of me worrying about avoiding them in the first place. That's just me. If you look at my programs, you rarely see shtuff like "using std::string;" or "std::blah" anywhere. It keeps the code clean and very readable.
Regards,
Alvaro
Give a man a fish, he owes you one fish. Teach a man to fish, you give up your monopoly on fisheries.
|
|
|
|
|
Alvaro Mendez wrote:
When I code, I prefer to use "string" rather than "std::string" or "System.String" anyday
std::string is more readable than just string, because it removes any ambiguity where this name comes from. The same holds for System.String. It is easier to type without namespace prefixes, I'll give you that, but readability gets hurt.
Alvaro Mendez wrote:
Now, on the C++ side, I've always added "using namespace std;" at the highest level the compiler has allowed me (with no fuss).
 I just hope I'm never going to use any C++ library you write.
|
|
|
|
|
Nemanja Trifunovic wrote:
std::string is more readable than just string, because it removes any ambiguity where this name comes from. The same holds for System.String. It is easier to type without namespace prefixes, I'll give you that, but readability gets hurt.
I suppose you can argue that the longer name is more readable because it removes ambiguity, but tell me what you'd rather read:
1. Marcio Lopez enjoys CP. Marcio Lopez visits the site many times a day. Marcio Lopez ...
2. Marcio enjoys CP. Marcio visits the site many times a day. Marcio ...
The ambiguity is only a problem when you first come across Marcio, but after you know him, you'd rather see him mentioned only by his first name. The same with programming. The vast majority of the types you come across when read or write code have unique names. So why code as if the majority of the types don't have unique names? Besides, if you really need to know the full name of a type, many of today's IDE's will tell you when you put the cursor over it.
Nemanja Trifunovic wrote:
I just hope I'm never going to use any C++ library you write.
 An expected reaction. But it's not as bad as you think. I've only done this when coding actual programs, not libraries. My libraries don't bring in any external namespaces.
I just find it very convenient when developing an actual program to bring in all the namespaces I need at the highest possible level, to avoid repeating the same code in multiple places. It's made life a lot easier and I haven't had any of the horrible problems people scream about.
Regards,
Alvaro
Give a man a fish, he owes you one fish. Teach a man to fish, you give up your monopoly on fisheries.
|
|
|
|
|
|
I am a C++ programmer for 10+, when I learn C# and found many intersting features that I ever want. but some important features are missing. Like: OpenPrinter("report"), CreateFile("com2:"), SetWindowHookEx(WH_KEYBOARD) for switch credit card. Can any one give me some idea how C# suppose to handle these?
Thank you.
eric feng
www.infospec.com
|
|
|
|
|
[DllImport("kernel32", SetLastError=true)]
public static extern IntPtr OpenPrinter(string pName);
read the interop chapter of the documentation
ms-help://MS.NETFrameworkSDKv1.1/cpguidenf/html/cpconinteroperatingwithunmanagedcode.htm
|
|
|
|
|
Thank you.
I did use OpenPrinter("printername"). when i call the StartDocPrinter, it failed once every 3000+ times. it never happen with C++.
anyway, do you have a sample how to use SetWindowHook?
eric feng
www.infospec.com
|
|
|
|
|
Code Project is full of resources !
a search
http://www.codeproject.com/info/search.asp?cats=3&searchkw=global+hook
I while suggest you the second result
http://www.codeproject.com/csharp/globalhook.asp
otherwise, for your problem, you probably pass around some other managed data (which might be moved in memory), to some unmanaged code which expect the data to stay in place.
that's sometime a problem with Interop.
you should analyze your data to see what data might be faulty and pin them. granted this problem is not correctly advertized (but it's stil uncomon)
little more info:
ms-help://MS.NETFrameworkSDKv1.1/cpguidenf/html/cpconcopyingpinning.htm
ms-help://MS.NETFrameworkSDKv1.1/cpguidenf/html/cpconmemorymanagement.htm
+ the following (reading in the doc)
fixed (keyword)
GCHandle, Marshal (class)
and look the web for resources on this topic ...
|
|
|
|
|
I got it, thank you very much for useful advice.
eric feng
www.infospec.com
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
