|
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
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
