C / C++ / MFC

Re: name conflicts in enum

3-Nov-07 23:07

Thanks for your great reply Bram!

regards,
George

Matthew Faithfull1-Nov-07 23:52

Matthew Faithfull

1-Nov-07 23:52

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.

Re: name conflicts in enum

George_George2-Nov-07 0:00

VS2005 C++ Auto Formatting..

2-Nov-07 0:00

Thanks Matthew!

A great sample! Cool!

have a good weekend,
George

WHGibbo1-Nov-07 23:18

WHGibbo

1-Nov-07 23:18

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

Nelek1-Nov-07 23:51

Nelek

1-Nov-07 23:51

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

Wink | ;)

WHGibbo2-Nov-07 0:30

WHGibbo

2-Nov-07 0:30

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

Nelek5-Nov-07 20:41

Nelek

5-Nov-07 20:41

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;
      //more code
   }

   if (i == 2)
      return;
}

RChin2-Nov-07 2:45

RChin

2-Nov-07 2:45

I've just checked both VS71 and VS2005 and it does exist!
Under Edit->Advanced->Format Selection

I Dream of Absolute Zero

WHGibbo2-Nov-07 5:15

WHGibbo

2-Nov-07 5:15

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?

RChin2-Nov-07 6:17

RChin

2-Nov-07 6:17

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

module definition file

George_George1-Nov-07 23:10

1-Nov-07 23:10

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

Matthew Faithfull2-Nov-07 0:35

Matthew Faithfull

2-Nov-07 0:35

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. Smile | :)

Nothing is exactly what it seems but everything with seems can be unpicked.

George_George2-Nov-07 0:53

2-Nov-07 0:53

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

Matthew Faithfull2-Nov-07 7:17

Matthew Faithfull

2-Nov-07 7:17

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.

JudyL_MD2-Nov-07 8:14

2-Nov-07 8:14

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

George_George2-Nov-07 19:51

2-Nov-07 19:51

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

JudyL_MD7-Nov-07 2:41

7-Nov-07 2:41

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

George_George7-Nov-07 3:25

7-Nov-07 3:25

Thanks for considering my question even if you are sick, JudyL_FL.

regards,
George

George_George2-Nov-07 19:49

2-Nov-07 19:49

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

JudyL_MD2-Nov-07 2:11

2-Nov-07 2:11

If you do not want to use __declspec (dllexport) inside your DLL, it is a way to export the functions from the DLL.

Exporting from a DLL Using DEF Files[^]

Judy

George_George2-Nov-07 5:28

2-Nov-07 5:28

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

JudyL_MD2-Nov-07 5:49

2-Nov-07 5:49

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

George_George2-Nov-07 19:46

2-Nov-07 19:46

Thanks Judy,

I want to confirm that, if I understand your points correctly, .DEF file is used to manage (or I should use the word *impact*) the import library file (.lib), and the other components which is dependent on the DLL should use import library file (.lib) directly other than use .DEF file. Right?

regards,
George

JudyL_MD7-Nov-07 2:44