strange problem in compilation

[Massimo M.]

hi, i'm a newbie of c++ and i have a strange problem with compiling a
c++ source
kdeveloper, gcc 4.2.4, slack.

i've 2 files, S3.cpp and S3.h


s3.h:

#include <ncurses.h>
#include <strings.h>
#include <stdio.h>
#include <vector>
#include <form.h>

using namespace std;

....

class campo
{
public:

campo()
{
fldInp=new_field(1, 1, 1, 1, 0, 0);
}

campo(int intXInp, int intYInp, int intLungInp, int intAltInp,
TipoCampo tcInp,InputCampo icInp, char *chrInit)
{
fldInp=new_field(intAltInp, intLungInp, intYInp, intXInp, 0, 0);

};

private:

FIELD *fldInp;
TipoCampo tcCampo;
};

class s3{
public:
s3();
~s3();
void reset();
private:
vector<campo> campi;
};


s3.cpp

#include "s3.h"

s3::s3()
{
initscr();
....
}

s3::~s3()
{
clear();
endwin();
}

void s3::reset()
{
....
}

the problem is in the "campo" class
as you see, ther are two constructors. one with parameters, one
without parameters.
they do the same thing, but gcc say:

s3.o: In function `campo':
/home/max/source/produzione/masks/src/s3.h:24: undefined reference to
`new_field'

i don't understand. i cut and paste the function "fldInp=new_field(1,
1, 1, 1, 0, 0);" from the other constructor, but gcc don't like it.

 

[Massimo M.]

i rewrite by hand all the constructor, and i modified


campo()
{
fldInp=new_field(10);
}


and the gcc says

/usr/include/form.h:309: error: too few arguments to function 'FIELD*
new_field(int, int, int, int, int, int)'
/home/max/source/produzione/masks/src/s3.h:24: error: at this point in
file

so gcc see the function new_field, but if i put the right number of
parameters, it don't find the new_field.

i don't understand...

 

[Alf P. Steinbach /Usenet]

* Massimo M., on 06.09.2010 22:06:

hi, i'm a newbie of c++ and i have a strange problem with compiling a
c++ source
kdeveloper, gcc 4.2.4, slack.

i've 2 files, S3.cpp and S3.h


s3.h:

Here you should have an "include guard" (google it) like

#ifndef S3_H
#define S3_H

followed, at the very end of the header file, by

#endif

#include<ncurses.h>
#include<strings.h>
#include<stdio.h>
#include<vector>
#include<form.h>

using namespace std;

When you do this in the global namespace in a header file you then risk name
collisions in any file that includes the header.

So, don't do this in the global namespace in a header file.

For that matter, don't do it within a namespace either. ;-)

...

class campo
{

Uhm, please replace tabs with spaces before posting, because tabs are rendered
with different tab positions by different reader programs.

public:

campo()
{
fldInp=new_field(1, 1, 1, 1, 0, 0);

When one of the Old Ones was asked what he'd do differently if he were to design
Unix from scratch again, he replied: "I'd spell 'creat' with an 'e'".

Of course he probably meant it as a comment on the goodness of the design.

But it's also a good story about needless shortenings. Don't say "hlt" when you
mean "halt" or "mov" when you mean "move". Don't say "fldInp".

}

campo(int intXInp, int intYInp, int intLungInp, int intAltInp,
TipoCampo tcInp,InputCampo icInp, char *chrInit)

Here the last argument is better declared as

char const* init

plus, of course, changing the name to something that communicates more clearly.

I removed the 'chr' prefix because you don't want those type-indicating prefixes.

Read up on "Hungarian Notation" and why that's Evil(TM).

{
fldInp=new_field(intAltInp, intLungInp, intYInp, intXInp, 0, 0);

};

private:

FIELD *fldInp;
TipoCampo tcCampo;
};

class s3{
public:
s3();
~s3();
void reset();
private:
vector<campo> campi;
};

Hm, it seems a little inconsistent to define the methods of class "campo"
inline, but defining the methods of "s3" in a separately compiled file.

Is there any reason for this?

s3.cpp

#include "s3.h"

s3::s3()
{
initscr();
...
}

s3::~s3()
{
clear();
endwin();
}

void s3::reset()
{
...
}

the problem is in the "campo" class
as you see, ther are two constructors. one with parameters, one
without parameters.
they do the same thing, but gcc say:

s3.o: In function `campo':
/home/max/source/produzione/masks/src/s3.h:24: undefined reference to
`new_field'

i don't understand. i cut and paste the function "fldInp=new_field(1,
1, 1, 1, 0, 0);" from the other constructor, but gcc don't like it.

It's a linker error.

It says that you're lacking a definition of 'new_field'.

Possibly you need to link with some library.

You haven't shown where 'new_field' is supposed to be declared so it's difficult
to say.

If the above doesn't help, try to reduce your example to the absolute minimum in
/one/ file, and post that (all of it).


Cheers & hth.,

- Alf

 

[Massimo M.]

solved. problem with include.

 

[James Kanze]

Alf P. Steinbach /Usenet ha scritto:

Not to mention that you should not assume everyone who will
ever read or maintain your code knows Italian and understands
"campo". Just use English, and don't mix it with other
languages. Say "field", not "campo".

That depends on context. If you're developing a program in
house, and "in house" is in Italy, there's probably a good
chance that most of the readers will understand Italian better
than English. Different companies have different rules about
this: international companies do impose English, but a lot of
smaller companies (and some not so small---I've used German at
the Dresdner Bank and T Mobil) impose the local language.

With regards to symbols, there's a very nice advantage in using
the local language (if it isn't English)---there are less
chances of conflicts with library symbols and keywords, and what
is library and what is local is immediately recognizable.

With regards to documentation: although it's rather unthinkable
that a C++ programmer doesn't understand English, it's quite
common that they can't express themselves as clearly in it as in
their native language. And I'd rather read well written German
or French, or even Italian, than poorly written English. For
that matter, I'd rather have the documentation in well written
Hungarian or Japanese than is some of the English I've seen. At
least I know I don't understand it, I know why, and I can get it
translated, since the precise information is there. Whereas in
poorly written English, significant information has been lost
(or even changed).