|
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
|
|
|
|
|
what Do you think why Microsoft does not just include the .NET Framework in their service packs?
I use .NET myself and I am very happy with it. But everytime I have to deploy an application I have to worry about the .NET Framework being available on the customers machine.
And to fear the size of the service pack by adding the .NET Framework is strange... 20MB is about 15% of the current size of the SP, so why bother. Having to download 150MB instead of 130MB is not that worse... (for example)
So what Do you think why MS is not pushing .NET the same way we are?
Greetings,
Stephan Eberle
hawke@deltacity.org
|
|
|
|
|
Perhaps they're afraid of lawsuits?
|
|
|
|
|
I believe this is the reason as it (releasing new functionality in a service pack) was a part of several of the antitrust lawsuits. However as I say this I have XP SP2 RC 2 and it does add a lot of new functionality to the os for free that directly competes with products on the market...
John
|
|
|
|
|
I don't think so. In that point .NET Framework is essentially the same as the Microsoft Java Virtual Machine (JVM) that comes with every (newer) Windows version.
|
|
|
|
|
I think it's because .NET is still not an essential component, at least as far as Windows goes.
Regards,
Alvaro
Give a man a fish, he owes you one fish. Teach a man to fish, you give up your monopoly on fisheries.
|
|
|
|
|
Yeah, anti-competition law is set to make sure OS's become nothing more than their kernal. Curiously this is an MS only philosophy. OS X comes with a myriad of different applications from music playing, to web browsing. The whole marketing emphasis on OS X is the number of pre-installed or freely downloadable software that comes from apple.
[worldspawn]
|
|
|
|
|
60% is a lot... but it's not reality
just check the job... the majority is for java and c++
|
|
|
|
|
.NET Framework redistribution, (20MB part installed by users, not the 150MB+ used by developers), is being distributed inside XP SP2, and is built into Win 2K3 server. I haven’t heard anything about Win2K having a service pack with it installed, but I wouldn't be surprised if it was included in SP5 for Win2K when ever MS gets around to it.
|
|
|
|
|
It is also included in Windows XP Tablet PC Edition (though it's not supposed to be run on Non-Tablet PCs ).
|
|
|
|
|
I am still searching the answer of your question.Recently I was trying to convice my client about using .NET for the project.The desktop application iteslf is 100 KB Max, but the .net framework makes it around 20 MB. I think the .NET framework only helps the developer.To the clients it doesn't make sense to have such a big download ,which can be made smaller by using VB6.
|
|
|
|
|
.NET 1.1 was part of Windows XP Service Pack 1 (and SP2) and it shipped installed with Windows Server 2003.
Windows Update includes .NET for all the versions of WIndows it supports (98, 2000, XP).
In Windows Longhorn, .NET becomes the native API. The classic Win32 API is still there, but I do not think they have added support for new features (those will have to be accessed through Interop).
Dale Thompson
|
|
|
|
|
right.
But with XP SP1 you had to manually install it. It was on the CD, but not installed automatically.
That's a big problem these days IMO.
Greetings,
Stephan Eberle
hawke@deltacity.org
|
|
|
|
|
We have recently developed an application in VB.Net
The app has since been deployed on many computers, most of which did not have .net before.
The size of the installer did not increase significantly after we included the .net framework redistribuatble, so that was really not an issue for us. At the moment the installer is around 48Mb, without .net redist it was only a few Mb less.
Note: we created the installer using installshield express 5.0, so i am not sure how it would be using other products.
Cheers,
|
|
|
|
|
21MB out of 48 is NOT sicnificant?
Thats ~45%...
Greetings,
Stephan Eberle
hawke@deltacity.org
|
|
|
|
|
Stevie,
You are right. I guess it was something else that i had checked to see how much diff it made for the size of the installer... In our case the difference is not so important, as the software comes on a CD, and i think that in this case it is better to extract .net from the setup.exe, rather than ask the client to download from the internet.
Certainly, 45% is a huge difference, apologies for not checking my facts earlier.
Cheers,
Kris
|
|
|
|