It looks like Borland uses "atoi64" ...
0% grep -i 'atoi.*64' * */*
fwcommon.h:// Required since TCHAR.H defines _ttoi64 -> atoi64, which =
requires oldnames.lib, which
fwcommon.h:#define atoi64 _atoi64
math.h:__int64 _RTLENTRY _EXPFUNC _atoi64(const char * __s);
math.h: using std::_atoi64;
stdlib.h:__int64 _RTLENTRY _EXPFUNC _atoi64(const char * __s);
stdlib.h: using std::_atoi64;
tchar.h:#define _ttoi64 _atoi64
It only takes 1 argument, so you'll have to forego some error checking =
As far as the link errors go (item 2), will they be fixed when BCC can =
compile vil_nitf2_typed_field_formatter.cxx? That's the file that needs =
From: vxl-maintainers-admin@... =
[mailto:vxl-maintainers-admin@...]On Behalf Of Rob =
Sent: Wednesday, August 17, 2005 8:26 AM
Subject: [Vxl-maintainers] Win2k_bcc-5.5.1_MinSizeRel build
After many iterations, the vil_nitf2 classes are compiling just fine on =
most platforms/compilers. I am having some trouble with the =
Win2k_bcc-5.5.1_MinSizeRel configuration ( =
bcc-5.5.1_MinSizeRel/20050817-0932-Continuous/BuildError.html) though. =
There seem to be two general issues:
1) Does it have a function that can convert a string (char*) to a 64 bit =
integer (ie. 64 bit version of strtol()). strtoll() is the most common =
function for this but MSVC uses a function named _strtoi64(). Neither =
work for the Borland compiler. Does anyone know what the alternative =
is? I've also heard of some platforms using atoi64(), but haven't tried =
this one out yet. =20
2) I'm seeing a bunch of link errors with functions declared in =
vil_nitf2_typed_field_formatter subclasses. As far as I can tell (and =
as far as the other compilers can tell), these functions are defined in =
vil_nitf2_typed_field_formatter.cxx. Any ideas.
Thank you for the help.
From: Peter Vanroose <peter_vanroose@ya...> - 2005-08-17 16:10:03
> stdlib.h:__int64 _RTLENTRY _EXPFUNC _atoi64(const char * __s);
> stdlib.h: using std::_atoi64;
If ::strtoll indeed belongs in <cstdlib> according to the standard, the
file vcl/generic/vcl_cstdlib.hhh must be adapted accordingly.
In that case, the special Borland behaviour can be made transparent by
implementing vcl_strtoll in vcl/borland*/vcl_cstdlib.h
Then it suffices to #include <vcl_cstrlib.h> and use vcl_strtoll(),
without having to use #if PLATFORM stuff all over the place.
On Wed 17 Aug 2005, Peter Vanroose wrote:
> If ::strtoll indeed belongs in <cstdlib> according to the standard, the
> file vcl/generic/vcl_cstdlib.hhh must be adapted accordingly.
strtoll is not part of the current C++ standard (C++98), since it is
not in the C89 standard. The latest C standard, C99, introduces
strtoll, along with type "long long". It is likely that the next C++
standard (C++0x) will also introduce it.
Only the latest versions of the compilers are C99 compatible.