Re: [Freeciv-Dev] Permission to make freeciv headers standard C/C++ compatible.
On Sun, 3 Jun 2007, James Supancic wrote:
> I'm working on a C++ GUI for freeciv. I need to make some calls into
> the C component of client. The problem I'm running into is that the
> freeciv header files are neither standard C or C++ compatible.
>
> For example:
> typedef enum a b;
> enum a { A, B };
>
> When this is compiled with g++ or 'gcc -pedantic' there will be an
> error, if it is compiled with gcc there will be no error.
>
> Given this problem, I see three possible solutions:
> 1) Quit
> 2) update the freeciv headers
> 3) write a C++ compatible wrapper for the functions I need.
>
> #3 would be the easiest in the short term
I am sure #1 is easiest in the short term ;-)
More seriously - does it work if you compile with g++ using -fpermissive?
If not, I'd say #2 is the best solution. But I would like to see a patch
for some header files first, to see how invasive the required changes are.
> refactoring the code to eliminate the use of 'class' as an identifier
> (as this is a C++ reserved keyword), perhaps other things.
C++ reserved keywords should be avoided, I agree.
- Per
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] Permission to make freeciv headers standard C/C++ compatible.
On 6/3/07, James Supancic <[EMAIL PROTECTED]> wrote:
I'm working on a C++ GUI for freeciv. I need to make some calls into
the C component of client. The problem I'm running into is that the
freeciv header files are neither standard C or C++ compatible.
For example:
typedef enum a b;
enum a { A, B };
When this is compiled with g++ or 'gcc -pedantic' there will be an
error, if it is compiled with gcc there will be no error.
Why even compile with -pedantic in the first place?
Given this problem, I see three possible solutions:
1) Quit
2) update the freeciv headers
3) write a C++ compatible wrapper for the functions I need.
#3 would be the easiest in the short term, but long term it will
require a significant amount of additional work to maintain. #2 is the
best in the long term, but has significant dangers. In updating the
headers, I could possibly introduce bugs or break features.
I'd like to do #2, with permission from the freeciv development team.
However, I'm also willing to do #3 if they feel it is unsafe.
#2 will probably involve me moving around some typedefs so that they
don't come before enum declarations and refactoring the code to
eliminate the use of 'class' as an identifier (as this is a C++
reserved keyword), perhaps other things.
Thank you for your time,
James Steven Supancic III
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
--
Vasco Alexandre da Silva Costa
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39383) BUG: terrain and resource name translation
http://bugs.freeciv.org/Ticket/Display.html?id=39383 >
In this version, I moved the translation into the accessor functions, as
this seemed to be better than spread around in 3 places, especially as the
other places in the code forgot to test for NULL and '\0' (empty string).
Comments in the code seemed to indicate a move was desired.
There's a warning, because the current resource list is const, and this
modifies the pointer. Updating the const can happen later.
Also, renamed the previous name_orig (or name_original) to name_rule --
that better indicates where the name originated, and makes it easier to
search in the future.
I've left the rest alone, but more could be done
As far as I'm concerned, it's ready to check in.
Index: server/generator/mapgen.c
===
--- server/generator/mapgen.c (revision 12970)
+++ server/generator/mapgen.c (working copy)
@@ -303,8 +303,8 @@
**/
static struct terrain *pick_ocean(int depth)
{
- /* FIXME: get_flag_terrain may return NULL if there is no match. */
- struct terrain *best_terrain = get_flag_terrain(TER_OCEANIC);
+ /* FIXME: pick_terrain_by_flag may return NULL if there is no match. */
+ struct terrain *best_terrain = pick_terrain_by_flag(TER_OCEANIC);
int best_match = abs(depth - best_terrain->property[MG_OCEAN_DEPTH]);
terrain_type_iterate(pterrain) {
@@ -980,9 +980,9 @@
if (!terrain_has_flag(pterrain, TER_CAN_HAVE_RIVER)) {
/* We have to change the terrain to put a river here. */
- /* FIXME: get_flag_terrain may return NULL
+ /* FIXME: pick_terrain_by_flag may return NULL
* if there is no match. */
- pterrain = get_flag_terrain(TER_CAN_HAVE_RIVER);
+ pterrain = pick_terrain_by_flag(TER_CAN_HAVE_RIVER);
tile_set_terrain(tile1, pterrain);
}
tile_set_special(tile1, S_RIVER);
@@ -1109,7 +1109,7 @@
terrain_type_iterate(pterrain) {
freelog(loglevel, "%20s : %4d %d%% ",
- get_name(pterrain), terrain_count[pterrain->index],
+ pterrain->name_rule, terrain_count[pterrain->index],
(terrain_count[pterrain->index] * 100 + 50) / total);
} terrain_type_iterate_end;
}
Index: server/scripting/api.pkg
===
--- server/scripting/api.pkg(revision 12970)
+++ server/scripting/api.pkg(working copy)
@@ -100,7 +100,7 @@
};
struct Terrain {
- const char *name_orig @ name;
+ const char *name_rule @ name;
};
Index: server/scripting/api_find.c
===
--- server/scripting/api_find.c (revision 12970)
+++ server/scripting/api_find.c (working copy)
@@ -147,15 +147,15 @@
**/
Terrain *api_find_terrain(int terrain_id)
{
- return get_terrain(terrain_id);
+ return get_terrain_by_number(terrain_id);
}
/**
- Return the tech type with the given name_orig.
+ Return the terrain with the given name_orig.
**/
Terrain *api_find_terrain_by_name(const char *name_orig)
{
- struct terrain *pterrain = get_terrain_by_name(name_orig);
+ struct terrain *pterrain = get_terrain_by_rule_name(name_orig);
return pterrain;
}
Index: server/citytools.c
===
--- server/citytools.c (revision 12970)
+++ server/citytools.c (working copy)
@@ -1097,7 +1097,7 @@
_("Moved %s out of disbanded city %s "
"since it cannot stay on %s."),
unit_type(punit)->name, pcity->name,
- get_name(tile_get_terrain(ptile)));
+ terrain_name_translation(tile_get_terrain(ptile)));
break;
}
}
Index: server/cityturn.c
===
--- server/cityturn.c (revision 12970)
+++ server/cityturn.c (working copy)
@@ -817,7 +817,7 @@
"%s terrain is required. Postponing..."),
pcity->name,
get_impr_name_ex(pcity, building->index),
- get_name(preq->source.value.terrain));
+
terrain_name_translation(preq->source.value.terrain));
script_signal_emit("building_cant_be_built", 3,
API_TYPE_BUILDING_TYPE, building,
API_TYPE_CITY, pcity,
Index: server/ruleset.c
===
--- server/ruleset.c(revi
[Freeciv-Dev] Permission to make freeciv headers standard C/C++ compatible.
I'm working on a C++ GUI for freeciv. I need to make some calls into
the C component of client. The problem I'm running into is that the
freeciv header files are neither standard C or C++ compatible.
For example:
typedef enum a b;
enum a { A, B };
When this is compiled with g++ or 'gcc -pedantic' there will be an
error, if it is compiled with gcc there will be no error.
Given this problem, I see three possible solutions:
1) Quit
2) update the freeciv headers
3) write a C++ compatible wrapper for the functions I need.
#3 would be the easiest in the short term, but long term it will
require a significant amount of additional work to maintain. #2 is the
best in the long term, but has significant dangers. In updating the
headers, I could possibly introduce bugs or break features.
I'd like to do #2, with permission from the freeciv development team.
However, I'm also willing to do #3 if they feel it is unsafe.
#2 will probably involve me moving around some typedefs so that they
don't come before enum declarations and refactoring the code to
eliminate the use of 'class' as an identifier (as this is a C++
reserved keyword), perhaps other things.
Thank you for your time,
James Steven Supancic III
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39383) BUG: terrain and resource name translation
http://bugs.freeciv.org/Ticket/Display.html?id=39383 >
While trying to debug some of my terrain changes, it was frustrating that
some error messages had empty (missing/blank) fields. Numerous messages
tried to insert a translated name into log messages that are not translated.
(I'm running without translation, so it shows up badly here.)
So, I spent all day figuring out some problems, and found a few others!
For example, the req_ Terrain Mountains probably didn't work for foreign
languages, because the test compared the translated terrain name against a
list that is always in ruleset (original) language.
Tests were wildly inconsistent, sometimes testing against original, others
against translated. I made them *all* against original. Translated names
are now only accessed via a central function. (The function existed, but
not everybody used it.)
My solution was to rename the "name" field to name_translated (how it
was actually used in most places), and rename name_orig to name_original.
That allowed me to find all the uses.
For the same reason, I renamed the accessor functions, so that future
programmers will be more aware of the actual purpose (or less confused).
I found some error messages that could be reworded to be identical, with
different parameters, that should ease translation a little.
Also, I found that there were many places that terrain and tiles were
confused (such as calling terrain "tile_type"). That will take more
time to unravel.
Compiles, runs here, needs more testing.
Index: server/generator/mapgen.c
===
--- server/generator/mapgen.c (revision 12970)
+++ server/generator/mapgen.c (working copy)
@@ -303,8 +303,8 @@
**/
static struct terrain *pick_ocean(int depth)
{
- /* FIXME: get_flag_terrain may return NULL if there is no match. */
- struct terrain *best_terrain = get_flag_terrain(TER_OCEANIC);
+ /* FIXME: pick_terrain_by_flag may return NULL if there is no match. */
+ struct terrain *best_terrain = pick_terrain_by_flag(TER_OCEANIC);
int best_match = abs(depth - best_terrain->property[MG_OCEAN_DEPTH]);
terrain_type_iterate(pterrain) {
@@ -980,9 +980,9 @@
if (!terrain_has_flag(pterrain, TER_CAN_HAVE_RIVER)) {
/* We have to change the terrain to put a river here. */
- /* FIXME: get_flag_terrain may return NULL
+ /* FIXME: pick_terrain_by_flag may return NULL
* if there is no match. */
- pterrain = get_flag_terrain(TER_CAN_HAVE_RIVER);
+ pterrain = pick_terrain_by_flag(TER_CAN_HAVE_RIVER);
tile_set_terrain(tile1, pterrain);
}
tile_set_special(tile1, S_RIVER);
@@ -1109,7 +1109,7 @@
terrain_type_iterate(pterrain) {
freelog(loglevel, "%20s : %4d %d%% ",
- get_name(pterrain), terrain_count[pterrain->index],
+ pterrain->name_original, terrain_count[pterrain->index],
(terrain_count[pterrain->index] * 100 + 50) / total);
} terrain_type_iterate_end;
}
Index: server/scripting/api.pkg
===
--- server/scripting/api.pkg(revision 12970)
+++ server/scripting/api.pkg(working copy)
@@ -100,7 +100,7 @@
};
struct Terrain {
- const char *name_orig @ name;
+ const char *name_original @ name;
};
Index: server/scripting/api_find.c
===
--- server/scripting/api_find.c (revision 12970)
+++ server/scripting/api_find.c (working copy)
@@ -147,15 +147,15 @@
**/
Terrain *api_find_terrain(int terrain_id)
{
- return get_terrain(terrain_id);
+ return get_terrain_by_number(terrain_id);
}
/**
- Return the tech type with the given name_orig.
+ Return the terrain with the given name_orig.
**/
Terrain *api_find_terrain_by_name(const char *name_orig)
{
- struct terrain *pterrain = get_terrain_by_name(name_orig);
+ struct terrain *pterrain = get_terrain_by_original_name(name_orig);
return pterrain;
}
Index: server/citytools.c
===
--- server/citytools.c (revision 12970)
+++ server/citytools.c (working copy)
@@ -1097,7 +1097,7 @@
_("Moved %s out of disbanded city %s "
"since it cannot stay on %s."),
unit_type(punit)->name, pcity->name,
- get_name(tile_get_terrain(ptile)));
+ terrain_name_translation(tile_get_terrain(ptile)));
break;
}
}
Index: server/cityturn.c
===
