C / C++ / MFC

15-Nov-08 7:25

I have downloaded a unit testing framework which is written in standard C++. I have the source as well as a "lib" file. Is it possible to use that "lib" file in my CPP file instead of copying that framework source to my application directory.

I have added the "lib" file path in the visual studio's directory search path, but still it is complaining that the header files are missing. This error will disappear if I copy the framework's source files to my application directory. So is there any way to use the lib file in my project?

Any help would be great

Mark Salsbery15-Nov-08 7:30

Mark Salsbery

15-Nov-08 7:30

The lib file may have the compiled object code from the source code,
but you will need to #include the header files in any of your source
modules that use code from the library.

That doesn't mean you have to copy source into your project folder.
You can use a path in your #include directives.

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Christian Flutcher16-Nov-08 6:56

16-Nov-08 6:56

Yes that helped a lot. I solved the problem. It happened because of my lack of knowledge on how linker works.

To solve this, I have taken "Project Properties -> Linker -> Input" and added my library name in "Additional dependencies". Header file is written like the following

#include "c:\somepath\someheader.h"

I can copy the someheader.h to my application directory, but this file is a facade header file which contains includes to several other files. So compiler is complaining about those missing ones. Is it a good practice to give fully qualified path for the includes?

Thanks Mark for helping me. Have a great week ahead.

Smile | :)

Mark Salsbery16-Nov-08 7:08

Mark Salsbery

16-Nov-08 7:08

Christian Flutcher wrote:
Is it a good practice to give fully qualified path for the includes?

I personally don't like fully qualified pathnames because it may cause a problem
when I move a project to another computer or a different drive.

I also don't like copying third-party source to my project's folder.

I like to arrange my project folders so I can use relative paths, something like

SolutionFolder
   ProjectAFolder
   ProjectBFolder
   ProjectCFolder
   ThirdPartyLibFolder

Then if a source file in project A needs to reference a ThirdPartyLib header file:

#include "..\ThirdPartyLibFolder\someheader.h"

That way the entire solution folder tree can be freely moved around without having to change
source code.

You can also use relative paths to reference the .lib Smile | :)

Christian Flutcher wrote:
Have a great week ahead.

Thank you! You too!

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Christian Flutcher16-Nov-08 7:12

16-Nov-08 7:12

Mark Salsbery wrote:
I also don't like copying third-party source to my project's folder.

Yeah. But looks like we can't avoid copying them to the solution folder.

Mark Salsbery16-Nov-08 7:22

Mark Salsbery

16-Nov-08 7:22

Christian Flutcher wrote:
can't avoid

"Can't"?

I guess if you don't mind someone else's code mixed in with yours...
Whatever works for you Smile | :)

I also use some SDKs from Microsoft, which aren't installed in my solution
folder tree.

For those I add the appropriate paths to the Visual Studio project directories
settings so they are available to all projects.

My main goal is to not have absolute paths in source code - it's a pain to change them
later....not good for maintainability.

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Jijo.Raj16-Nov-08 7:34

Jijo.Raj

16-Nov-08 7:34

Christian Flutcher wrote:
I can copy the someheader.h to my application directory, but this file is a facade header file which contains includes to several other files. So compiler is complaining about those missing ones. Is it a good practice to give fully qualified path for the includes?

You should not use hardcoded path in your source. Assume if you go to another machine and there the headers exist in another directory, either you've to edit the source or copy the headers to hardcoded path. Well, the solutions are as follows.

Solution 1
1) Include the header by just filename - #include "someheader.h"
2) Declare an environment variable - SOME_HEADER_PATH with path as C:\Somepath.
3) Restart visual studio IDE for making the new env var in effect.
4) Take Visual Studio project settings, C/C++ tab, Preprocessor settings category.
5) In "Additional include directories" add - $(SOME_HEADER_PATH).
6) Now recompile the project.

Here you've moved the directory dependency to an external env var. And if you move to some other machine, just make sure that the env var in that machine holds the right path to your Somepath.

Solution 2
1) Include the header by just filename - #include "someheader.h"
2) Take menu, Tools > Options > Directories tab.
3) Now add C:\somepath to the include directory search list.
4) you are done.

Well, depends on your requirement choose the best. Well, I recommend the first. Smile | :)

Regards,
Jijo.

_____________________________________________________

http://weseetips.com[^] Visual C++ tips and tricks. Updated daily.

Christian Flutcher17-Nov-08 15:37

Problems with malloc() and typedef struct

17-Nov-08 15:37

Jijo,

That was brilliant answer. It helped a lot. I followed the solution 1 and it worked like a charm! Smile | :)

Appreciate your help.

Jijo raj wrote:

http://weseetips.com[^] Visual C++ tips and tricks. Updated daily.

WOW! great blog. I like the images you added there.

Manfr3d15-Nov-08 3:11

Manfr3d

15-Nov-08 3:11

Hello guys,

I've created a struct and defined it as a new data type. However, when I want to declare a variable of this type there are several errors:
SMap: Illegal use of this type as expression
mySMap: undeclared identifier

<br />
#include <stdio.h><br />
#include <stdlib.h><br />
<br />
#ifndef NULL<br />
#define NULL 0<br />
#endif<br />
<br />
typedef struct<br />
{<br />
	int width;<br />
	int height;<br />
	char* data;<br />
} SMap;<br />
<br />
SMap* createMap(int width, int height);<br />
<br />
int main(int argc, char* argv[])<br />
{<br />
	int width;<br />
	int height;<br />
	printf("Enter width: ");<br />
	scanf("%i", &width);<br />
	printf("Enter height: ");<br />
	scanf("%i", &height);<br />
	<br />
	SMap* mySMap = (SMap*)malloc(sizeof(SMap));    // the errors refer to this line<br />
<br />
	return 0;<br />
}<br />
<br />
SMap* createMap(int width, int height)<br />
{<br />
	SMap* mymap = (SMap*) malloc(sizeof(SMap));<br />
	if (mymap == NULL)<br />
	{<br />
		return NULL;<br />
	}<br />
	mymap->width = width;<br />
	mymap->height = height;<br />
	mymap->data = (char*) malloc(width*height);<br />
	if (mymap->data = NULL)<br />
	{<br />
		free(mymap);<br />
		return NULL;<br />
	}<br />
	return mymap;<br />
}<br />
</stdlib.h></stdio.h>

I know that the use of malloc() isn't necessary in C++ but I want to compile the code as C-code.
Does anyone know why this doesn't work, maybe it's a basic thing I forgot about?

Thanks and best wishes.

Iain Clarke, Warrior Programmer

Iain Clarke, Warrior Programmer15-Nov-08 3:18

15-Nov-08 3:18

Do you get different errors if you change the extension of the from between C and CPP? Then you'll be using the different compilers.

Also, for the initial typedef, try this:

struct _SMap_
{
  int width;
  int height;
  char* data;
}  SMap;

then, in main:

main (...)
{
  int n;
  ...
  n = sizeof(struct _SMap_);
  n = sizeof(SMap);
}

and see if any happiness results.

Iain.

Manfr3d15-Nov-08 4:08

Manfr3d

15-Nov-08 4:08

I told VS to compile the project as C-code until now this was enough.
As expected the results of the sizeof()-operations were the same (12Byte).
However, this didn't change anything. I've no idea what's the problem.

cmk15-Nov-08 9:21

cmk

15-Nov-08 9:21

In C all variables must be defined at the start of the scope they belong to.

Change main() to:

int main(int argc, char* argv[])
{
  int width;
  int height;
  SMap* mySMap;
  
  printf("Enter width: ");
  scanf("%i", &width);
  printf("Enter height: ");
  scanf("%i", &height);
  
  mySMap = (SMap*)malloc(sizeof(SMap));
  
  return 0;
}

...cmk

The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack

Manfr3d15-Nov-08 23:22

Manfr3d

15-Nov-08 23:22

Thanks, this was my problem. I knew that variables must be defined at the beginning of their scope when programming micro processors, didn't know that this is also important when writing Windows programs.
Thanks a lot.