Click here to Skip to main content
16,006,749 members
Home / Discussions / C / C++ / MFC
   

C / C++ / MFC

 
QuestionHow I can Get DLL Version Number from resource file Pin
jinzhecheng26-Apr-06 7:32
jinzhecheng26-Apr-06 7:32 
AnswerRe: How I can Get DLL Version Number from resource file Pin
Michael Dunn26-Apr-06 7:39
sitebuilderMichael Dunn26-Apr-06 7:39 
QuestionRe: How I can Get DLL Version Number from resource file Pin
David Crow26-Apr-06 7:44
David Crow26-Apr-06 7:44 
AnswerRe: How I can Get DLL Version Number from resource file Pin
jinzhecheng28-Apr-06 14:11
jinzhecheng28-Apr-06 14:11 
Question3D graphics Pin
Gagnon Claude26-Apr-06 7:24
Gagnon Claude26-Apr-06 7:24 
QuestionBest way to setup environment for modular development ? Pin
Defenestration26-Apr-06 7:14
Defenestration26-Apr-06 7:14 
AnswerRe: Best way to setup environment for modular development ? Pin
Blake Miller26-Apr-06 7:25
Blake Miller26-Apr-06 7:25 
AnswerRe: Best way to setup environment for modular development ? Pin
Rilhas29-Apr-06 15:06
Rilhas29-Apr-06 15:06 
I've been using a modular structure for years, at home and at work, based on LIB+HPP pairs.

This has various advantages. The first is that many projects take about 4 to 5 minutes to compile in the source form, and about 15 seconds using libs. That on a P4@4.2GHz.

Another advantage is that a module may be composed of various strange and hard to setup items. For example, I have a module for speech recognition that relies on SCANSOFT and LOQUENDO libraries, and some of my own wrappings. To use this as source would be difficult, since SCANSOFT and LOQUENDO's software has to be installed in the machine that compiles the module. On the other hand, pre compiling it and using it as a lib does not need LOQUENDO and SCANSOT to be installed (my libs include all other extarnal libs automatically).

My modules always have 3 files: "module_x.hpp", "module_x.lib", and "module_x_release.lib". The "hpp" file does not include any other external files or classes. This is hidden in the HPP, since all my classes have hidden internal data. For example, the HPP for a module could be as follows:

module_recognition.hpp

class Rilhas_Recognize {
protected:
struct Rilhas_Recognize_Data_Struct* itsData;
public:
Rilhas_Recognize();
~Rilhas_Recognize();
char* DoSomething();
};

This HPP does not need any inclusions, since it compiles without the exact definition of Rilhas_Recognize_Data_Struct. The CPP (which originates the libs) will be something like:

module_recognition.cpp

#include <stdio.h>
#include "this_file.h"
#include "that_file.h"
#include "loquendo.h"
#include "scansoft.h"

typdef struct Rilhas_Recognize_Data_Struct {
Rilhas_Recognize* object;
Loquendo_Handle handle;
char buffer[1000];
Scansoft_Handler asr;
} Rilhas_Recognize_Data;

Rilhas_Recognize::Rilhas_Recognize() {
itsData=new Rilhas_Recognize_Data;
itsData->object=this;
sprintf(itsData->buffer, "Hello world!");
}

Rilhas_Recognize::~Rilhas_Recognize() {
delete itsData;
}

char* Rilhas_Recognize::DoSomething() {
sprintf(itsData->buffer, "Hello again world!");
return itsData->buffer;
}

As you can see, the CPP can include many specific files. All internal operation data is hidden to the HPP and the HPP user, which makes it easy to distribute it. I use VC6, but for VC8 the setup should be easy as well. I simply create a workspace, named Module_X in its own directory. Inside it I create a "Source" directory where I will store the HPP and the source files used to produce the LIB, and where the compiled libs will be copied to. I also create a "Tools" folder where I store everything else the module needs (like LOQUENDO and SCANSOT stuff).

Then I create a project named Module_X_Con inside Module_X. This is a console project which I use for development. It includes the sources, and a simple "main.cpp" (which I create in the "Tools" folder). During development the CON project is used for debugging everything.

Then I create a Module_X_Lib which will take all the sources (except the "main.cpp" in the CON project). Note that I include external lib files to the lib project. The linker will add any external libs to the lib you are generating, so the lib becomes self-contained. In the post build step I add a command to copy the LIBs to the Source directory. Sometimes I also add a console project named "Module_X_Lib_Tester" that includes the libs and confirms everything is ok. It can use the same "main.cpp" file as the CON project.

Some projects require me to build a DLL. For that I create a "Module_X_DLL" project, and in the post build step I copy the LIB and DLL to the source directory, with the names "module_x_dll.lib" and "module_x_dll.dll" respectively. The release version takes the the names "module_x_dll_release.lib" and "module_x_dll_release.dll" (the Link name must be fixed for the release configuration). I sometimes add a console project named "Module_X_DLL_Tester" which takes the DLL libs from the Source and tests the DLL with the same "main.cpp" as before. Typically I add a pre-link step to the DLL tester to copy the DLL's from the source to the local directory.

This setup is very practical. You should note that I don't have dependent projects Y access the Source directory to take the libs or dlls directory. This is important, since I may be making changes which do not compile yet, and in the middle of the process I need to change and compile project Y. Or I may make a new version which is backward incompatible with project Y. For these situations not to be a problem, each dependent project Y has it's own "Tools" directory to where I copy frozen snapshots of everything it will need (hpp, libs, or dlls).

This project Y is then self-suficient and self-contained, and can even be passed on to another person. I still compiles perfectly even if it is 10 years old and module X has gone through several revisions, or if X has become incompatible with Y. When I need or want to update the X module in project Y I just go to the module X directory and bring fresh copies of the HPP, LIB, or DLL files to the dependent project's Y "Tools" directory.

As a final note, the multithreaded/singlethreaded version variations are usually not a problem. I used mixed versions in any project. When setting up a new project you may have to go to the link tab and ignore standard libraries like "libc", "libcd", "libcmt", and "licmtd". This is not difficult, since the linker detects the variation colision and sugests which library should be removed. I just go to the link tab and remove it, it is a very safe operation.

In the end the directory named Module_X will contain everything needed to build and test module X, including LIB's and DLL's. In the source directory I always find the CPP (which I do not use outside module X) and the distributables "module_x.hpp", "module_x.lib", and "module_x_release.lib". Eventually, for DLL projects, I also find "module_x_dll.lib", "module_x_dll.dll", module_x_dll_release.dll" and "module_x_dll_release.lib".

I hope this helps. It is nice to know that someone else recognizes the importance of adequate setup for modularity and code reusability.

Rilhas
QuestionHandling asynchronous I/O Pin
logicaldna26-Apr-06 6:24
logicaldna26-Apr-06 6:24 
QuestionCTreeCtrl selection problem Pin
RoyceF26-Apr-06 5:57
RoyceF26-Apr-06 5:57 
AnswerRe: CTreeCtrl selection problem Pin
includeh1026-Apr-06 6:16
includeh1026-Apr-06 6:16 
GeneralRe: CTreeCtrl selection problem Pin
RoyceF26-Apr-06 7:15
RoyceF26-Apr-06 7:15 
GeneralRe: CTreeCtrl selection problem Pin
RoyceF26-Apr-06 7:17
RoyceF26-Apr-06 7:17 
QuestionCFileDialog & GetOpenFileName Pin
RobJones26-Apr-06 5:24
RobJones26-Apr-06 5:24 
QuestionRe: CFileDialog & GetOpenFileName Pin
David Crow26-Apr-06 6:06
David Crow26-Apr-06 6:06 
AnswerRe: CFileDialog &amp; GetOpenFileName Pin
RobJones26-Apr-06 6:18
RobJones26-Apr-06 6:18 
AnswerRe: CFileDialog & GetOpenFileName Pin
RobJones26-Apr-06 6:42
RobJones26-Apr-06 6:42 
AnswerRe: CFileDialog & GetOpenFileName Pin
RobJones26-Apr-06 7:16
RobJones26-Apr-06 7:16 
AnswerRe: CFileDialog &amp; GetOpenFileName Pin
RobJones26-Apr-06 7:58
RobJones26-Apr-06 7:58 
QuestionRe: CFileDialog &amp; GetOpenFileName Pin
David Crow27-Apr-06 2:45
David Crow27-Apr-06 2:45 
GeneralRe: CFileDialog &amp; GetOpenFileName Pin
David Crow27-Apr-06 9:41
David Crow27-Apr-06 9:41 
GeneralRe: CFileDialog &amp; GetOpenFileName Pin
RobJones27-Apr-06 9:50
RobJones27-Apr-06 9:50 
GeneralRe: CFileDialog &amp; GetOpenFileName Pin
RobJones1-May-06 3:55
RobJones1-May-06 3:55 
QuestionSystem sound volume on WinCE Pin
KellyR26-Apr-06 5:15
KellyR26-Apr-06 5:15 
QuestionJPEG image display Pin
CPP91126-Apr-06 4:52
CPP91126-Apr-06 4:52 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.