[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  Programming
. -> [Folder]  General
. . -> [Subject]  Compiling a C based mud under g++
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: Compiling a C based mud under g++
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please).
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1 2  

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Thu 03 Aug 2006 05:41 AM (UTC)  [ quote  ]
Message
g++ (and C++) is more strict about some things than C++. It might not be a bad idea to compile using g++, even if you're compiling C code.

And regarding const etc., it's actually a fairly common technique to have functions for a const version and functions for a non-const version; generally it's better to prefer the const version, if you can get away with it, because it's an extra aid to the programmer: you are guaranteeing that nothing will be changed (which is a good thing for the programmer to know) and the compiler is enforcing this restriction.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Samson   USA  (683 posts)  [Biography] bio
Date Thu 03 Aug 2006 02:57 AM (UTC)  [ quote  ]
Message
Quote:
Thanks to Samson for changing "class" to "Class" which avoided heaps of problems I had earlier.


Heh. I used the script you provided for the purpose, it worked quite well. The reason SmaugFUSS compiled cleanly using g++ is because I had gone through it once before and cleaned out all of the errors it generated, then changed the Makefile back to C. Didn't figure on it being necessary to remain as C++ when it's not. Just wanted to clean up the heap of residual errors/warnings it picks up.
SmaugMuds.org: http://www.smaugmuds.org - The Smaug MUDs Community Center

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Thu 03 Aug 2006 01:47 AM (UTC)  [ quote  ]
Message
Some cases? Like what?

Quote:

And the C stuff must not be so strict then.


It isn't. They are different languages really. C++ allows you to have multiple implementations of the same function name. It isn't really a matter of being strict, it is a language feature.

Consider this program:


int test (const char * arg)
  {
  }
  
int test (char * arg)
  {
  }

int main (void)
  {
  const char * a;
  char * b;
  
  test (a);  // uses first function
  test (b);  // uses second function

  return 0;
  } // end of main


The function "test" is defined twice, with different arguments. The C++ compiler will correctly call the appropriate function (as in the example in main). This compiles without errors under C++.

Under C, you get this:


gcc test.c
test.c:6: conflicting types for `test'
test.c:2: previous declaration of `test'
test.c: In function `main':
test.c:17: warning: passing arg 1 of `test' discards qualifiers from pointer target type


Because of this, if you prototype something, and call it, as in your example, but implement a different function (that is, with different argument types), then it will compile but the linker will complain you never implemented that version.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Crix   (11 posts)  [Biography] bio
Date Thu 03 Aug 2006 01:21 AM (UTC)  [ quote  ]
Message
why would that work though in some cases but not others?

And the C stuff must not be so strict then.
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Thu 03 Aug 2006 01:10 AM (UTC)  [ quote  ]
Message
Quote:

char * string_allocation ( char *str );

char *string_allocation( const char *str )


There's your problem.

The prototype promises you will implement a function accepting
( char *str ), however you have a function taking ( const char *str ).

That is a different function. Either put const in front of the prototype, or take if off the implementation.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Crix   (11 posts)  [Biography] bio
Date Thu 03 Aug 2006 12:56 AM (UTC)  [ quote  ]
Message
string_allocation is actually part of a macro called STRALLOC, I'll paste that in as well.
Here is one of the samples though of it:

void generate_com_freq(CHAR_DATA *ch)
{
char buf[MAX_STRING_LENGTH];

sprintf(buf, "%d%d%d.%d%d%d",
number_range(0,9), number_range(0,9), number_range(0,9),
number_range(0,9), number_range(0,9), number_range(0,9));
if(ch->comfreq)
STRFREE(ch->comfreq);
ch->comfreq = STRALLOC(buf);
save_char_obj(ch);
return;
}

Here is how it is defined in mud.h:
char * string_allocation ( char *str );

and the macro:
#define STRALLOC(point) string_allocation((point))

And here is the actual implementation in hashstr.cpp:
char *string_allocation( const char *str )
{
register int len, hash, psize;
register struct hashstr_data *ptr;

len = strlen(str);
psize = sizeof(struct hashstr_data);
hash = len % STR_HASH_SIZE;
for (ptr = string_hash[hash]; ptr; ptr = ptr->next )
if ( len == ptr->length && !strcmp(str,(char *)ptr+psize) )
{
if ( ptr->links < 65535 )
++ptr->links;
return (char *) ptr+psize;
}
ptr = (struct hashstr_data *) malloc(len+psize+1);
ptr->links = 1;
ptr->length = len;
if (len)
strcpy( (char *) ptr+psize, str );
else
strcpy( (char *) ptr+psize, "" );
ptr->next = string_hash[hash];
string_hash[hash] = ptr;
return (char *) ptr+psize;
}


[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Thu 03 Aug 2006 12:50 AM (UTC)  [ quote  ]
Message
Also show the prototype for string_allocation as well as the implementation.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Thu 03 Aug 2006 12:49 AM (UTC)  [ quote  ]
Message
Can you show an example of how string_allocation is called? For example, in generate_com_freq, it says there is an undefined reference. Perhaps it is calling it with different arguments, for example:

string_allocation ("nick")

This would be const char *, not char *.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Crix   (11 posts)  [Biography] bio
Date Thu 03 Aug 2006 12:31 AM (UTC)  [ quote  ]
Message
hashstr.cpp is in the project and I placed it at the front of the list of items being compiled. Also, string_allocation does not have the extern "C" bit around it.
I've gotten all the errors narrowed to this:
act_comm.o(.text+0x1f2): In function `generate_com_freq(char_data*)':
: undefined reference to `string_allocation(char*)'
act_comm.o(.text+0x2899): In function `do_retune(char_data*, char*)':
: undefined reference to `string_allocation(char*)'
act_comm.o(.text+0x29c3): In function `do_retune(char_data*, char*)':
: undefined reference to `string_allocation(char*)'
act_info.o(.text+0x5a3d): In function `do_hedit(char_data*, char*)':
: undefined reference to `string_allocation(char*)'
act_info.o(.text+0x5a53): In function `do_hedit(char_data*, char*)':
: undefined reference to `string_allocation(char*)'
act_info.o(.text+0x5fe9): more undefined references to `string_allocation(char*)' follow
finger.o(.text+0xe4c): In function `read_finger(char_data*, char*)':
: undefined reference to `check_parse_name(char*, bool)'
magic.o(.text+0x4a29): In function `spell_create_water(int, int, char_data*, void*)':
: undefined reference to `string_allocation(char*)'
magic.o(.text+0x92e4): In function `spell_animate_dead(int, int, char_data*, void*)':
: undefined reference to `string_allocation(char*)'
magic.o(.text+0x938d): In function `spell_animate_dead(int, int, char_data*, void*)':
: undefined reference to `string_allocation(char*)'
magic.o(.text+0x9436): In function `spell_animate_dead(int, int, char_data*, void*)':
: undefined reference to `string_allocation(char*)'
magic.o(.text+0xb798): In function `spell_obj_inv(int, int, char_data*, void*)':
: undefined reference to `string_allocation(char*)'
makeobjs.o(.text+0x199): more undefined references to `string_allocation(char*)' follow
collect2: ld returned 1 exit status
make[1]: *** [swreality] Error 1
make[1]: Leaving directory `/home/mud/lots/lotscode/dist/src'
make: *** [all] Error 2

The other ones that I had I moved declarations around for variables and that fixed it but I've moved the prototyping around and I've kept this same problem.
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Wed 02 Aug 2006 11:55 PM (UTC)  [ quote  ]
Message
I would confirm that there is no "extern C" around the declaration for string_allocation (that is, in the .h file).


Also I would check that hashstr.cpp is part of the project.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Crix   (11 posts)  [Biography] bio
Date Wed 02 Aug 2006 11:41 PM (UTC)  [ quote  ]
Message
Alright, so I took out the extern "C" bit and changed all the file names to end with .cpp
I still get the same errors, now with a couple extra thrown in for good measure.
Here's what I've got so far:
act_comm.o(.text+0x1f2): In function `generate_com_freq(char_data*)':
: undefined reference to `string_allocation(char*)'
act_comm.o(.text+0x2899): In function `do_retune(char_data*, char*)':
: undefined reference to `string_allocation(char*)'
act_comm.o(.text+0x29c3): In function `do_retune(char_data*, char*)':
: undefined reference to `string_allocation(char*)'
act_info.o(.text+0x5a3d): In function `do_hedit(char_data*, char*)':
: undefined reference to `string_allocation(char*)'
act_info.o(.text+0x5a53): In function `do_hedit(char_data*, char*)':
: undefined reference to `string_allocation(char*)'
act_info.o(.text+0x5fe9): more undefined references to `string_allocation(char*)' follow
finger.o(.text+0xe4c): In function `read_finger(char_data*, char*)':
: undefined reference to `check_parse_name(char*, bool)'
magic.o(.text+0x4a29): In function `spell_create_water(int, int, char_data*, void*)':
: undefined reference to `string_allocation(char*)'
magic.o(.text+0x92e4): In function `spell_animate_dead(int, int, char_data*, void*)':
: undefined reference to `string_allocation(char*)'
magic.o(.text+0x938d): In function `spell_animate_dead(int, int, char_data*, void*)':
: undefined reference to `string_allocation(char*)'
magic.o(.text+0x9436): In function `spell_animate_dead(int, int, char_data*, void*)':
: undefined reference to `string_allocation(char*)'
magic.o(.text+0xb798): In function `spell_obj_inv(int, int, char_data*, void*)':
...
space2.o(.text+0x112): In function `reload_ship(ship_data*)':
: undefined reference to `string_allocation(char*)'
space2.o(.text+0x12e): In function `reload_ship(ship_data*)':
: undefined reference to `string_allocation(char*)'
space2.o(.text+0x2674): In function `do_giveship(char_data*, char*)':
: undefined reference to `string_allocation(char*)'
space2.o(.text+0x280c): In function `do_cleanships(char_data*, char*)':
: undefined reference to `string_allocation(char*)'
space2.o(.text+0x2822): In function `do_cleanships(char_data*, char*)':
: undefined reference to `string_allocation(char*)'
space2.o(.text+0x2838): more undefined references to `string_allocation(char*)' follow
collect2: ld returned 1 exit status
make[1]: *** [swreality] Error 1
make[1]: Leaving directory `/home/mud/lots/lotscode/dist/src'
make: *** [all] Error 2


As a reference to one of the errors, string_allocation is prototyped in hashstr.cpp and found in hashstr.cpp
Thanks
[Go to top] top
Posted by Crix   (11 posts)  [Biography] bio
Date Wed 02 Aug 2006 12:03 PM (UTC)  [ quote  ]
Message
Excellent, thank you everyone for the work, when I get home tonight, I'll try it it out and copy some of the errors that I have.
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Wed 02 Aug 2006 06:24 AM (UTC)  [ quote  ]
Message
zlib actually has the extern "C" inside zlib.h, so you don't need to do that either.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Wed 02 Aug 2006 06:21 AM (UTC)  [ quote  ]
Message
As an experiment, I took the SmaugFUSS source (1.6 I think) and changed gcc in the Makefile to g++, did a "make clean" and then a make.

This compiled and linked with no errors whatsoever.

I wasn't sure what that proved, so I added a bit of definite C++ to inside comm.c :


vector<int> v (100);
generate (v.begin (), v.end (), rand);


That compiled OK too, so it seems that it should be working for you with no errors.

Thanks to Samson for changing "class" to "Class" which avoided heaps of problems I had earlier.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Wed 02 Aug 2006 06:08 AM (UTC)  [ quote  ]
Message
Quote:

Is there any benefit in renaming the files as .cpp ...


I agree with Ksilyan that the compiler is more likely to treat your source as C++ files, rather than C being compiled in C++ mode which gives a rather different result. Of course there will be a compiler switch to do that. Judging by the (incredibly long) man page for g++ it is:

-x c++

However a quick test seems to show that compiling a .c file with g++ does in fact treat it as C++. However as Ksilyan says, if they are C++ files, why not have them suffixed .cpp?

This doesn't totally explain your linking problems, however I would, as I said before, stop using "extern C" and make the source compile without it, as far as possible anyway.

It will probably be needed for external libraries (zlib springs to mind), but should not be needed for things like including mud.h.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

4,820 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]