|
There is not! It appears to me to be a scheme designed to confuse both the Compiler and the developer.My advice: Don't!
LateNightsInNewry
|
|
|
|
|
Hi LateNightsInNewry,
Could you show me how to solve this issue in your ideas by simple sample please?
regards,
George
|
|
|
|
|
The Problem is, you have two enum values by the same name. If the compiler is instructed correctly it should throw an error! You managed to compile it regardless!
That did not mean that it was the right thing to do to get your code to compile!
The Bottom Line is, You wrote daft code, and spent time to convince the compiler that it was wrong to issue error messages about it. You managed to convince it, so it issued a daft environment to the compiler. The way you did it is probably by having a project spread out over several folders, and having different versions of a header file in each folder!
The Simple Solution is:
1. If the enum values are meant to represent the same condition, include it's definition in an Header file visible everywere required. i.e. construct a Common Header Directory, and instruct the compiler to search that folder preferentially.
2. If the enum values represent different conditions, give them different names
3. Learn that NameSpace Collision Error Messages are your friend. It is your Indicator that things are wrong, and you catch it when it occurs! Imagine debugging an App where all variables have the same name!
4. Realise that the Names of Objects only come into play at Development Level, and that there is no reason to be coy about naming. There is absolutely No possibility of recovering te name of a correctly compiled and linked retail version of your code from the executable.
Hope this is Helpfull,
Bram van Kampen
|
|
|
|
|
Thanks for your great reply Bram!
regards,
George
|
|
|
|
|
The short answer is no because the names exist in the same scope and same namespace. You could do
<br />
class Cfoo<br />
{<br />
<br />
enum foo <br />
{<br />
NAME = 100;<br />
}<br />
};<br />
<br />
class cGoo<br />
{<br />
enum goo <br />
{<br />
NAME = 200;<br />
}<br />
};<br />
which would then allow Cfoo::NAME to be differentiated from Cgoo::NAME or
<br />
namespace nsfoo<br />
{<br />
enum foo <br />
{<br />
NAME = 100;<br />
}<br />
}<br />
<br />
enum goo <br />
{<br />
NAME = 200;<br />
}<br />
which would differentiate nsfoo::NAME from NAME. I would strongly prefer the class method because namespace resolution is relative.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Thanks Matthew!
A great sample! Cool!
have a good weekend,
George
|
|
|
|
|
Hi,
I've been doing some work using C# and like the auto document format (Under the Edit->Advanced Menu).
But noticed that this feature doesn't exist in C/C++!! Anybody know if there is an Add-In that I can use within VS2005?
Many thanks
Gibbo
|
|
|
|
|
What does the "auto document format" do? I mean... What do you want to have?
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
|
The "Auto document format", goes through and re-formats your code according to a set of rules..
For example if you had the following code:
void TestFunction ( const char *var1)
{
if (1 == 1)
{
int i = 0;
}
}
and reformats it
void
TestFunction(
const char *var1
) {
if(1==1){
int i = 0;
}
}
That sort of thing..
Gibbo
|
|
|
|
|
Personally, I prefer the first option (specially with one tab in every scope)
Like:
void TestFunction ( const char *var1)
{
if (1 == 1)
{ int i = 0;
}
if (i == 2)
return;
}
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
|
I've just checked both VS71 and VS2005 and it does exist!
Under Edit->Advanced->Format Selection
I Dream of Absolute Zero
|
|
|
|
|
I know, it is only available for C#/VB/etc, not C/C++.
I'm looking for alternative for C/C++ that will go through and format my code..
Any ideas?
|
|
|
|
|
no. no. I am using C++...and its there!
I don't know whether the installation version makes any difference. I have the Professional install.
I Dream of Absolute Zero
|
|
|
|
|
Hello everyone,
I am using Visual Studio 2005 to develop C++ DLL (in-process COM). There is a setting in Linker --> Input called Module definition file. This setting makes me confused,
1. I have tried that if input a file name (.def), then the generated DLL be larger than the time when we leave the module definition file to empty. Should we leave it empty or non-empty (input a .def file name);
2. What is the function of the module definition file? Should developer write it manually or generated by system.
thanks in advance,
George
|
|
|
|
|
You should create a .def file (always let the machine do it and you can edit it afterwards if you're a serious hacker) if your Dll will be linked into an executable. If it's a purely COM interfaced Dll which will get loaded and the interfaces interogated at run time then I don't think a .def file is going to be needed. It doesn't do any harm though and shouldn't increase the size of your output. If I remeber rightly the exception to this is if you're doing DCOM and want to build proxy/stub dlls for your objects, then you're back to needing a .def file. Either way I'd just switch it on and forget about it unless and until you need it. Good luck.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Thanks Matthew,
I think you mean if I do not hacking the def file itself (I am not doing this), I should just input a file name and let Visual Studio 2005 fill in the content during build process, right?
Could you show me a sample how other component will utilize .def file please?
regards,
George
|
|
|
|
|
Include the .def file created by your Dll project as a source file in an EXE project. Link the EXE project to your Dll and you'll be able to call the Dll functions exported in the .def from the .exe as if they were local functions, no GetProcAddress juggling or anything. Sorry I don't have a ready example handy. I was using this but changed my Dll to generate a .lib file for the case where it is statically linked into an EXE. Check the docs for your compiler version to work out the project-settings/make commands you'll need.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Interesting. I didn't realize you could use the DEF file to do the import on the DLL comusmer consumer side. I've never seen a DLL provider supply a DEF file instead of a LIB file. How did you discover this? I've never seen documentation on a DEF file that said you could use it to import - it's always been mentioned for the export side.
As I said ... interesting. <thoughtful look="">Judy
|
|
|
|
|
Hi Judy,
I want to confirm with you that .DEF technique is a general technique for DLL, and it is not a specific technique for COM DLL (in-process server) only. Right?
regards,
George
|
|
|
|
|
Sorry for the delay in responding, I've been sick for a few days.
George_George wrote: I want to confirm with you that .DEF technique is a general technique for DLL, and it is not a specific technique for COM DLL (in-process server) only. Right?
Yes
|
|
|
|
|
Thanks for considering my question even if you are sick, JudyL_FL.
regards,
George
|
|
|
|
|
Thanks Matthew,
I roughly know your ideas. But a real sample of some URL resources to learn will be better about how other components (which is dependent on the DLL) will utilize the .DEF file.
regards,
George
|
|
|
|
|
|
Thanks Judy,
In my understanding of your reply, you mean .DEF file is used for definition of what functions are exported by the DLL. I am wondering what is the differences between .DEF file and.lib file (import library), which is used to do implicit link when another component is dependent on the DLL?
BTW: could you show me a sample how other component will utilize the .DEF file of the DLL please?
regards,
George
|
|
|
|
|
Note the DEF files are used by DLLs that expose a C interface.
George_George wrote: In my understanding of your reply, you mean .DEF file is used for definition of what functions are exported by the DLL. I am wondering what is the differences between .DEF file and.lib file (import library), which is used to do implicit link when another component is dependent on the DLL?
The DEF file helps control what goes into the LIB file. A function will be listed as an exported function if a) the function has __declspec (dllexport) atrributes or b) the function name is in the DEF file. The LIB file is called an import library because it is given to users of a DLL to link with to resolve the references to functions in the DLL. The user "imports" the library functions into their code so they can link their executable. Use of an import library means that the user does not have to use LoadLibray and GetProcAddress to access the functions exported by the DLL.
George_George wrote: BTW: could you show me a sample how other component will utilize the .DEF file of the DLL please?
Other components do not use the DEF file. It is used by the creator of the DLL to generate his DLL / LIB.
The package provided by a DLL provider should include a .h file, a .lib file and a .dll file. That's all that is required for anyone to use the dll. You actually don't need the .lib but it makes it easier for the users of the dll.
Judy
|
|
|
|