Older Compiler Issues

[Mike Copeland]

The code below compiles and works in VS2010, but I'm forced to
compile it with an older version (VS6.0). It doesn't compile (Error
C2552 and C2078). I Googled the error and see that there are solutions
that involve code that doesn't work in VS6.0. Is there another way to
do this sort of thing? TIA

#define EDITS 36
struct Replacements // Street Address cleanup values
{
string oValue[EDITS]; // old/original value
string nValue[EDITS]; // new/replacement value
} extern changeValues;
Replacements changeValues =
{{" AVENUE", " STREET","N.W.", "S.W.", "N.E.", "S.W.",
" SOUTH ", " NORTH "," WEST "," EAST ", " RD.", " ROAD",
" ST.", " AVE.", " BLVD."," PKWY.", " LANE", " LN.",
" UNIT ", " SUITE "," N. ", " S. ", " E. ", " W. ",
" # ", " DRIVE", " DR.", " PARKWAY"," PLACE"," PL.",
" TERRACE", " TER", " COURT"," CIRCLE", " TRAIL"," BOULEVARD"},
{" AVE", " ST", "NW", "SW", "NE", "SW",
" S ", " N ", " W ", " E ", " RD", " RD",
" ST", " AVE", " BLVD", " PKWY", " LN", " LN",
" #", " # ", " N ", " S ", " E ", " W ",
" #", " DR", " DR", " PKWY", " PL", " PL",
" TERR", " TERR", " CT", " CIR", " TRL", "BLVD"}};

 

[Ian Collins]

The code below compiles and works in VS2010, but I'm forced to
compile it with an older version (VS6.0).

Why? That compiler is ancient and buggy, move on.

 

[Alf P. Steinbach]

The code below compiles and works in VS2010, but I'm forced to
compile it with an older version (VS6.0). It doesn't compile (Error
C2552 and C2078). I Googled the error and see that there are solutions
that involve code that doesn't work in VS6.0. Is there another way to
do this sort of thing? TIA

#define EDITS 36
struct Replacements // Street Address cleanup values
{
string oValue[EDITS]; // old/original value
string nValue[EDITS]; // new/replacement value
} extern changeValues;
Replacements changeValues =
{{" AVENUE", " STREET","N.W.", "S.W.", "N.E.", "S.W.",
" SOUTH ", " NORTH "," WEST "," EAST ", " RD.", " ROAD",
" ST.", " AVE.", " BLVD."," PKWY.", " LANE", " LN.",
" UNIT ", " SUITE "," N. ", " S. ", " E. ", " W. ",
" # ", " DRIVE", " DR.", " PARKWAY"," PLACE"," PL.",
" TERRACE", " TER", " COURT"," CIRCLE", " TRAIL"," BOULEVARD"},
{" AVE", " ST", "NW", "SW", "NE", "SW",
" S ", " N ", " W ", " E ", " RD", " RD",
" ST", " AVE", " BLVD", " PKWY", " LN", " LN",
" #", " # ", " N ", " S ", " E ", " W ",
" #", " DR", " DR", " PKWY", " PL", " PL",
" TERR", " TERR", " CT", " CIR", " TRL", "BLVD"}};

Well, I would simply replace "string" with "char const*".

That changes the kind of object from non-POD aggregate to pure POD
(Plain Old Data). Visual C++ 6.0 was developed before the C++98, the
first standardization of C++, and thus before value initialization was
added in C++03. Even Visual 7.x had problems with value/default
initialization of non-POD aggregates (perhaps also some POD ones).

Do note that support for the standard exception hierarchy, if I remember
this correctly, was not added until Visual C++ 7.0, mainly because the
exception hierarchy was finalized very late in the standardization process.

***

Regarding the code in general,

* "#define" to define a constant is generally ungood in C++, mainly
because macros in the themselves are generally ungood (because macros
don't respect scopes, so can lead to inadvertent and undesired text
substitution, and anyway name conflicts that are not easy to fix).

* Non-const global variables, as indicated by the "extern", are
generally ungood, mainly because they allow widely separated parts of
the code to interact, invisible to the programmer, but also in the case
above because you can run into the so called "initialization order
fiasco" (see the FAQ) -- plus some other reasons... ;-)

Here's a suggestion as to how to organize such data for easier
maintenance and avoiding the problems noted above:

struct Replacement
{
char const*  oldValue;
char const*  newValue;
};

extern Replacement const replacements[];
extern int const nReplacements;

extern Replacement const replacements[] =
{
{" AVENUE",     " AVE"},
{" STREET",     " ST"},
{"N.W.",        "NW"},
{"S.W.",        "SW"},
{"N.E.",        "NE"},
{"S.W.",        "SW"},
{" SOUTH ",     " S "},
{" NORTH ",     " N "},
{" WEST ",      " W "},
{" EAST ",      " E "},
{" RD.",        " RD"},
{" ROAD",       " RD"},
{" ST.",        " ST"},
{" AVE.",       " AVE"},
{" BLVD.",      " BLVD"},
{" PKWY.",      " PKWY"},
{" LANE",       " LN"},
{" LN.",        " LN"},
{" UNIT ",      " #"},
{" SUITE ",     " # "},
{" N. ",        " N "},
{" S. ",        " S "},
{" E. ",        " E "},
{" W. ",        " W "},
{" # ",         " #"},
{" DRIVE",      " DR"},
{" DR.",        " DR"},
{" PARKWAY",    " PKWY"},
{" PLACE",      " PL"},
{" PL.",        " PL"},
{" TERRACE",    " TERR"},
{" TER",        " TERR"},
{" COURT",      " CT"},
{" CIRCLE",     " CIR"},
{" TRAIL",      " TRL"},
{" BOULEVARD",  "BLVD"},
};

extern int const nReplacements =
sizeof(replacements)/sizeof(*replacements);

Cheers & hth.,

- Alf

 

[Mike Copeland]

Why? That compiler is ancient and buggy, move on.

Not an option. Aspects of VS2010 executables prohibit it from
running on Windows 7 - it needs a DLL file that can't be ported to a
system that doesn't have the VS2010 compiler installed. I've tried
several "fixes" that have been proposed, but none work. 8<{{
My solution seems to be on;y to go back to a compiler that produces
executables that actually run on the target machines. <sigh>

 

[Alf P. Steinbach]

Not an option. Aspects of VS2010 executables prohibit it from
running on Windows 7 - it needs a DLL file that can't be ported to a
system that doesn't have the VS2010 compiler installed. I've tried
several "fixes" that have been proposed, but none work. 8<{{
My solution seems to be on;y to go back to a compiler that produces
executables that actually run on the target machines. <sigh>

http://www.microsoft.com/en-us/download/details.aspx?id=5555

"The Microsoft Visual C++ 2010 Redistributable Package installs runtime
components of Visual C++ Libraries required to run applications
developed with Visual C++ on a computer that does not have Visual C++
2010 installed."

Also, but I only ever did for Visual C++ 7.2 or something, if you link
everything statically then chances are no "extra" DLLs will be needed.


Cheers & hth.,

- Alf

 

[Geoff]

Not an option. Aspects of VS2010 executables prohibit it from
running on Windows 7 - it needs a DLL file that can't be ported to a
system that doesn't have the VS2010 compiler installed. I've tried
several "fixes" that have been proposed, but none work. 8<{{

Eh? What DLL is that? What aspect of VS2010 could possibly preclude an
application from running on Windows 7?

It sounds more like you are linking it wrong for VS2010. There are
some aspects of conversion from older VS projects to VS2010 projects
that need follow up and tweaks but I have never seen a problem such as
you describe. Are you running VS2010 Express Edition?

 

[James Kanze]

(e-mail address removed) (Mike Copeland) wrote in

Now, if I take your claim "needs a DLL file that can't be ported to a
system that doesn't have the VS2010 compiler installed" in a face value
then my only conclusion is that you are trying to distribute programs
compiled in Debug mode. This is indeed hard and might be illegal (you may
not legally redistribute MS Debug-build runtimes, last time I checked).
So give up and distribute Release builds like everyone else is doing!

You normally don't want to distribute what Microsoft offers as
the defaults for "Release" build, but you can (sometimes) modify
one of the builds (or create a new one) to give you something
reasonable which doesn't require the debug libraries.