I'm a stupid blond :( Please help me!!!

J

Jenya

Hello, guys.

First of all, you should understand that I'm a very bad programmer and
I don't know anything.
My problem is as following. I'm supposed to write a DICOMDIR parser -
visual one - on MFC. I'm trying to use the DCMTK kit (dcdicdir
especially). Now, I simply want to use a DcmDicomDir class. What seems
the most right thing to do, is to include the dcdicdir.h file in my
project. Done. Now, unfortunately, this file #includes tons of other
files, which on their turn include tons of others. Well, I copied the
whole Dcmtk to my project. But when trying to compile, it has
unresolved stuff. Which means that I need to add all .cxx files to the
project. Now, I of course can do that, but. My simple application will
become WAY too large, and I don't think all this is necessary.... And
it really seems to me that there's an easier way to do that.........
....... So please please help?!

Thanks,
Jenya.
 
P

Peter van Merkerk

First of all, you should understand that I'm a very bad programmer and
I don't know anything.

Don't insult yourself, there are plenty of people here who can do that
better job at that than you :)
My problem is as following. I'm supposed to write a DICOMDIR parser -
visual one - on MFC. I'm trying to use the DCMTK kit (dcdicdir
especially). Now, I simply want to use a DcmDicomDir class. What seems
the most right thing to do, is to include the dcdicdir.h file in my
project. Done. Now, unfortunately, this file #includes tons of other
files, which on their turn include tons of others. Well, I copied the
whole Dcmtk to my project. But when trying to compile, it has
unresolved stuff. Which means that I need to add all .cxx files to the
project. Now, I of course can do that, but. My simple application will
become WAY too large,

Did you try it? Typically the linker will remove code that isn't
referenced. Anyway I would focus on getting your project to work correctly
first and worry about things like executable size or performance later.
and I don't think all this is necessary.... And
it really seems to me that there's an easier way to do that.........

Since it is a kit I assume that it is already available as a library (*.lib
file). If so just add the appropriate lib file to your project. If not it
the kit can probably compiled to a library. The advantage of using a
library instead of adding all *.cxx files to your project is that it does
not slow down the compilation of your project and it keeps the kit separate
from your project. I recommend you read the documentation that came with
the kit. I don't know this kit, but it should explain how to integrate it
into your project. If not contact the author.

Your question is not really topical here since it is not about the standard
C++ language itself, but about how to use a particular kit. Questions about
specific compilers (like Visual Studio), libraries (like MFC) other than
the standard library or tools are off-topic here. There are better
newsgroups, forums and/or mailing lists for these topics. For more
information what is topical here and what not, and many other useful tips,
please read this:
http://www.slack.net/~shiva/welcome.txt and
http://home.wanadoo.nl/efx/c++-faq/
 
J

jeffc

Peter van Merkerk said:
Don't insult yourself, there are plenty of people here who can do that
better job at that than you :)

We can't put together meaningful English statements, but we can program bad
code!
 
P

Peter van Merkerk

Typically the linker will remove code that isn't
Sounds like magic to me. How does the linker predict the future and
who will call who?

Simple: functions that aren't referenced (directly or indirectly) anywhere
cannot be called. No magic, no need to predict the future.

For example:

int main()
{
return 0;
}

This program will never call for example the printf() function, so there
is no need to link in the code of printf(). Of course if it is not possible
to determine at compile time whether or not a function will be called, its
code must always be linked into the executable.
As I read the orignal post, she *tried* to link and it refused. ISTM
she is immersed in a real world nasty problem.

Looking at her problem description my guess is she just forgot to link the
right library, that is the usual cause of "resolved" errors. Which library
she should add to her project I cannot tell, I have never heared the kit
she is talking about. However the people who made the kit should be able to
tell her that.
What linker did you have in mind?

The linker that comes with the compiler, which one did you have in mind?
Most linkers eliminate dead code, otherwise every executable would be at
least a couple of megs. You can verify this yourself by adding libraries
you don't use to your project. If the executable becomes bigger look for
another linker.
 
J

Joerg Riesmeier

Jenya,
My problem is as following. I'm supposed to write a DICOMDIR parser
- visual one - on MFC. I'm trying to use the DCMTK kit (dcdicdir
especially).

I propose the following:

0. read how your compiler works
1. read the INSTALL file from DCMTK's main directory
2. compile the toolkit with MSVC (at least module ofstd and dcmdata),
in case you want to use any of the external libraries either
compile them from source or download them in pre-compiled format
from our web site http://dicom.offis.de/dcmtk , you could also
disable particular libraries in file "config/include/cfwin32.h".
3. write a small program that uses the DCMTK, include "dctk.h" and
make sure that the libraries "ofstd.lib" and "dcmdata.lib" can be
found by the linker.

That's all. However, please be warned that your program needs to use
the same settings for "code generation" (e.g. "multi-threaded") as
you've used for the toolkit, otherwise the linking will fail.

Regards,
Joerg Riesmeier
OFFIS
 
O

osmium

Peter said:
Typically the linker will remove code that isn't
referenced.

Sounds like magic to me. How does the linker predict the future and who
will call who?

As I read the orignal post, she *tried* to link and it refused. ISTM she is
immersed in a real world nasty problem.

What linker did you have in mind?
 
G

Gianni Mariani

osmium wrote:
....
As I read the orignal post, she *tried* to link and it refused. ISTM she is
immersed in a real world nasty problem.

why do you think the OP is a she ?

SEXIST !
 
O

osmium

Peter said:
Simple: functions that aren't referenced (directly or indirectly) anywhere
cannot be called. No magic, no need to predict the future.

For example:

int main()
{
return 0;
}

This program will never call for example the printf() function, so there
is no need to link in the code of printf(). Of course if it is not possible
to determine at compile time whether or not a function will be called, its
code must always be linked into the executable.


Looking at her problem description my guess is she just forgot to link the
right library, that is the usual cause of "resolved" errors. Which library
she should add to her project I cannot tell, I have never heared the kit
she is talking about. However the people who made the kit should be able to
tell her that.


The linker that comes with the compiler, which one did you have in mind?
Most linkers eliminate dead code, otherwise every executable would be at
least a couple of megs. You can verify this yourself by adding libraries
you don't use to your project. If the executable becomes bigger look for
another linker.

I use a compiler from one of the *major* compiler vendors. Please ignore
typos, I really ran these but it was on a different machine.

Program 1

int main()
{return 0;}

Program 2

#include <iostream>
int main()
{
cout << 'a' << endl;
return 0;
}

Results:

Program 2: 27,967 bytes
Program 1: 8,578 bytes

So you are suggesting it took 19,389 bytes to write the letter 'a' in the
native character set on this machine? A hundred bytes or so would seem much
more reasonable. What kind of results does *your* compiler/linker yield on
this test? I have no reason to believe my compiler/linker is second rate or
below average.

I speculate that the vast majority of the code included would never, under
any circumstances, be called by Program 2. Most of the included functions
are not referenced, either directly or indirectly to use your words.
 
J

Jumbo

Jenya said:
Hello, guys.

First of all, you should understand that I'm a very bad programmer and
I don't know anything.

If your good in the sack it doesn't matter.
You'll always be usefull for something.
:eek:)
 
P

Peter van Merkerk

I use a compiler from one of the *major* compiler vendors. Please
ignore
typos, I really ran these but it was on a different machine.

Program 1

int main()
{return 0;}

Program 2

#include <iostream>
int main()
{
cout << 'a' << endl;
return 0;
}

Results:

Program 2: 27,967 bytes
Program 1: 8,578 bytes

So you are suggesting it took 19,389 bytes to write the letter 'a' in the
native character set on this machine?

Yes. I/O streams do a lot more than you might think. Look at the code and
you will understand where those 19,389 bytes come from.
A hundred bytes or so would seem much
more reasonable.
What kind of results does *your* compiler/linker yield on
this test? I have no reason to believe my compiler/linker is second rate or
below average.

Your test proved my point. If the linker would always link in code, even if
that code could not possibly be called then the executable sizes should be
about equal (and probably a couple of megs). Did you do the test I
suggested of adding libraries that you don't use to your project? Does it
affect the size of your executable?
I speculate that the vast majority of the code included would never, under
any circumstances, be called by Program 2.

The point is whether or not that can be detected at compile time.
Most of the included functions
are not referenced, either directly or indirectly to use your words.

They are referenced, that they are not called during run-time because some
conditions will never be met is a different issue. If there are
conditionals which can not be determined at compile time whether or not
they will be taken, the linker must link in the code (seems rather obvious
to me).

For example:

#include "foo.h"
int main(int argc)
{
if(argc < 0)
{
foo();
}
}

This code will cause the code of the foo() function and any functions it
calls to be linked, because that function is referenced from the code. The
fact that it will never be called cannot be determined during compile time
(assuming the compiler does not know about the characteristics of the
arguments of the main() function).

However if the program is changed to:

#include "foo.h"
int main(int argc)
{
if(argc < 0)
{
}
}

The code of the foo() function won't be linked because it cannot possibly
be called. Whether you add the library containing the foo() function to
your project or not won't make a difference.

If you want to understand which functions are linked let the linker
generate a map file. If you look at the map file you will see many
functions, most of them are internal implementation functions of the
run-time library. However you won't see all functions that are in the
libraries you linked, only those that may be called either by the startup
code or your own code.
 
J

Jenya

Joerg Riesmeier said:
Jenya,


I propose the following:

0. read how your compiler works
1. read the INSTALL file from DCMTK's main directory
2. compile the toolkit with MSVC (at least module ofstd and dcmdata),
in case you want to use any of the external libraries either
compile them from source or download them in pre-compiled format
from our web site http://dicom.offis.de/dcmtk , you could also
disable particular libraries in file "config/include/cfwin32.h".
3. write a small program that uses the DCMTK, include "dctk.h" and
make sure that the libraries "ofstd.lib" and "dcmdata.lib" can be
found by the linker.

That's all. However, please be warned that your program needs to use
the same settings for "code generation" (e.g. "multi-threaded") as
you've used for the toolkit, otherwise the linking will fail.

Regards,
Joerg Riesmeier
OFFIS


Joerg, Thanks!!! That's exactly the explanation I needed, and now
everything has linked and compiled. I'm so very new to linkage stuff,
that the whole problem was about 3 things:
1. I separated the libs by a comma!!!!!! And didn't notice it. I spent
like a day on this one!!!
2. The last thing you said... Gee... THANKS!!! :)
3. And the osftd.lib. Who could've thought that I need another lib for
this? ;)

To other guys, hey, I am a SHE, you're right, and thank you all as
well, very very much. I'll bug you all again in a short period of
time, I promise,

Jenya, the stupid blondE:))))
 
T

Thom

Jenya said:
Hello, guys.

First of all, you should understand that I'm a very bad programmer and
I don't know anything.
My problem is as following. I'm supposed to write a DICOMDIR parser -
visual one - on MFC. I'm trying to use the DCMTK kit (dcdicdir
especially). Now, I simply want to use a DcmDicomDir class. What seems
the most right thing to do, is to include the dcdicdir.h file in my
project. Done. Now, unfortunately, this file #includes tons of other
files, which on their turn include tons of others. Well, I copied the
whole Dcmtk to my project. But when trying to compile, it has
unresolved stuff. Which means that I need to add all .cxx files to the
project. Now, I of course can do that, but. My simple application will
become WAY too large, and I don't think all this is necessary.... And
it really seems to me that there's an easier way to do that.........
...... So please please help?!

Thanks,
Jenya.

Try asking over in the comp.protocols.dicom group. They deal with DICOM all
day.
 
N

Niklas Borson

osmium said:
Peter said:
Simple: functions that aren't referenced (directly or indirectly) anywhere
cannot be called. No magic, no need to predict the future.
[snip]

I use a compiler from one of the *major* compiler vendors. Please ignore
typos, I really ran these but it was on a different machine.

Program 1

int main()
{return 0;}

Program 2

#include <iostream>
int main()
{
cout << 'a' << endl;
return 0;
}

Results:

Program 2: 27,967 bytes
Program 1: 8,578 bytes

So you are suggesting it took 19,389 bytes to write the letter 'a' in the
native character set on this machine? A hundred bytes or so would seem much
more reasonable. What kind of results does *your* compiler/linker yield on
this test? I have no reason to believe my compiler/linker is second rate or
below average.

I speculate that the vast majority of the code included would never, under
any circumstances, be called by Program 2. Most of the included functions
are not referenced, either directly or indirectly to use your words.

*Called* is not the same thing as *referenced*. Consider this example:

#include <iostream>
#include <cstring>
int foo();
int bar(int n)
{
return n < 0 ? foo() : n;
}
int fred(char* s)
{
return strlen(s);
}
int main()
{
std::cout << bar(1) << std::endl;
return 0;
}

I can easily tell by analyzing this program that foo will never be called
because bar is only called once with n==1. However, neither the compiler
nor the linker attempts such an analysis. All that matters is that main
references bar, which references foo; therefore foo will be linked in.

On the other hand, fred is not referenced either directly or indirectly
by main so it is not linked in.

Returning to your example, it may seem surprising to you that writing a
single character to stdout would add almost 20K to your program, but
merely by referencing cout in your program you force a global object of
type basic_ostream< char, char_traits<char> > to be instantiated. This
means at a minimum that your program references the constructor of this
class, all the functions referenced by that contructor (including the
constructors of bases and members), all the functions THEY reference, and
so on. Similarly for the particular operator<< you invoke.

Another issue may be compiler-specific. Some compilers allow exception
handling to be turned on and off. Your compiler may turn on exception
handling by default in your second program (because it uses the standard
library) but not your first (because it does not). The run-time support
for exception handling could account for much of the difference in size
between your two programs.
 
J

jeffc

Jenya said:
Joerg, Thanks!!! That's exactly the explanation I needed, and now
everything has linked and compiled. I'm so very new to linkage stuff,
that the whole problem was about 3 things:
1. I separated the libs by a comma!!!!!! And didn't notice it. I spent
like a day on this one!!!
2. The last thing you said... Gee... THANKS!!! :)
3. And the osftd.lib. Who could've thought that I need another lib for
this? ;)

To other guys, hey, I am a SHE, you're right, and thank you all as
well, very very much. I'll bug you all again in a short period of
time, I promise,

Jenya, the stupid blondE:))))

It's not the blondE so much as it is the 6 exclamation marks.
 
J

Jenya

Jumbo said:
If your good in the sack it doesn't matter.
You'll always be usefull for something.
:eek:)

Oh. Yeah. But not programming. I haven't written a single line without
a reference here online heh :)
 
O

osmium

Niklas Borson writes:

Returning to your example, it may seem surprising to you that writing a
single character to stdout would add almost 20K to your program, but
merely by referencing cout in your program you force a global object of
type basic_ostream< char, char_traits<char> > to be instantiated.

Not at all surprising. After all, that *was* my point! Unused code is
linked in. I was rebutting a claim that:
Typically the linker will remove code that isn't
referenced.

I read "removed" as meaning "will not be linked".
 
P

Peter van Merkerk

Returning to your example, it may seem surprising to you that writing a
Not at all surprising. After all, that *was* my point! Unused code is
linked in. I was rebutting a claim that:


I read "removed" as meaning "will not be linked".

The word you misinterpreted is "referenced" not the word "removed". If code
is *referenced* it does not necessarily mean that it will be *called*
during run-time. However if code is not *referenced* anywhere it cannot
possibly be *called* during run-time. Whether or not code is *referenced*
can be detected during compile- and/or link time. There is no point in
putting code that is not *referenced* into the executable, because it will
not be *called* under any circumstances.

If you link to a library it doesn't mean that all the code in that library
is put into the executable, only the code that is *referenced* directly or
indirectly by your program. You don't have to take my word for this, if you
can produce executables of less then a couple of megabytes (which
apparently you can), my point is proven.
 
K

Karl Heinz Buchegger

Peter said:
The word you misinterpreted is "referenced" not the word "removed". If code
is *referenced* it does not necessarily mean that it will be *called*
during run-time. However if code is not *referenced* anywhere it cannot
possibly be *called* during run-time. Whether or not code is *referenced*
can be detected during compile- and/or link time. There is no point in
putting code that is not *referenced* into the executable, because it will
not be *called* under any circumstances.

Also note that with the existence of virtual functions it got much harder
for the linker to figure out if a function is referenced or not.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

I'm tempted to quit out of frustration 1
Probably a stupid question 2
Help please 8
I'm new 0
Please, help me. 1
Help me, going live with a quiz 0
Please help 7
Please, help me. 1

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top