Problem writing struct out to file

R

rmr531

First of all I am very new to c++ so please bear with me. I am trying
to create a program that keeps an inventory of items. I am trying to
use a struct to store a product name, purchase price, sell price, and
a taxable flag (a Y/N char) and then write this all out to a file
(preferably just a plain old text file) and then read it in later so
that I can keep a running inventory. The problem that I am running
into is when I write to the file it seems save it but when I read it
back in it doesn't seem to give me anything. From what I have been
able to figure out so far you can't just save a String to a file you
have to manipulate it somehow but being very new (and not that good)
at c++ I can't figure out a practical way to do it.

Is there any simple way to handle this or might I be better off trying
to do it somehow other than a Struct?

This is what I have so far, tried to limit the code to what relates to
this problem so it might make a little more sense. If more is needed
will be happy to post.
*************************************
struct product
{
int stockNum;
string name;
float cost;
float price;
char tax;
};

product inventory[25];

ofstream st("c:/stock.txt");
ifstream stI("c:/stock.txt");

stI.read((char *)&inventory, sizeof(inventory));

if (stockChoice == 1)
{
stockChoice = 0;
inventory[counter].stockNum = counter;
cout << "Product Number: " << inventory[counter].stockNum;
cout << "\nEnter product name: ";
cin >> inventory[counter].name;
cout << "\nEnter product purchase cost: ";
cin >> inventory[counter].cost;
cout << "\nEnter product purchase price: ";
cin >> inventory[counter].price;
cout << "\nIs product taxable (Y/N): ";
cin >> inventory[counter].tax;
cout << "\n\nProduct Entered: " << inventory[counter].stockNum <<
inventory[counter].name << " " << inventory[counter].cost << " " <<
inventory[counter].price << " " << inventory[counter].tax;

counter++;
}

st.write((char *)&inventory, sizeof(inventory));
*********************************

Thank you!
 
A

Alf P. Steinbach

* (e-mail address removed):
First of all I am very new to c++ so please bear with me. I am trying
to create a program that keeps an inventory of items. I am trying to
use a struct to store a product name, purchase price, sell price, and
a taxable flag (a Y/N char) and then write this all out to a file
(preferably just a plain old text file) and then read it in later so
that I can keep a running inventory. The problem that I am running
into is when I write to the file it seems save it but when I read it
back in it doesn't seem to give me anything. From what I have been
able to figure out so far you can't just save a String to a file you
have to manipulate it somehow but being very new (and not that good)
at c++ I can't figure out a practical way to do it.

Is there any simple way to handle this or might I be better off trying
to do it somehow other than a Struct?

This is what I have so far, tried to limit the code to what relates to
this problem so it might make a little more sense. If more is needed
will be happy to post.
*************************************
struct product
{
int stockNum;
string name;
float cost;
float price;
char tax;
};

At least make 'cost' and 'price' of type 'double'.


product inventory[25];

Don't use globals.

And don't use raw arrays.

Use std::vector, and use its 'at' function instead of []-indexing (it's
safer in that it detects range errors).

ofstream st("c:/stock.txt");
ifstream stI("c:/stock.txt");

stI.read((char *)&inventory, sizeof(inventory));

As a novice, don't /ever/ use casts, especially not C style casts.

That means that 'read' is an ungood function for the kinds of problems
you'll be solving, and the kind of problem you are solving right now.

For 'read' you should have opened the file in binary mode, but don't try
that: instead, use a text file, with each item of a record on its own
line. Use the usual << and >> operators for i/o, except for the string,
which you should input via 'getline'.


if (stockChoice == 1)
{
stockChoice = 0;
inventory[counter].stockNum = counter;
cout << "Product Number: " << inventory[counter].stockNum;
cout << "\nEnter product name: ";
cin >> inventory[counter].name;
cout << "\nEnter product purchase cost: ";
cin >> inventory[counter].cost;
cout << "\nEnter product purchase price: ";
cin >> inventory[counter].price;
cout << "\nIs product taxable (Y/N): ";
cin >> inventory[counter].tax;
cout << "\n\nProduct Entered: " << inventory[counter].stockNum <<
inventory[counter].name << " " << inventory[counter].cost << " " <<
inventory[counter].price << " " << inventory[counter].tax;

counter++;
}

This seems to be part of a loop you haven't shown.
 
M

Marcus Kwok

Alf P. Steinbach said:
* (e-mail address removed):
I am trying to
use a struct to store a product name, purchase price, sell price, and
a taxable flag (a Y/N char) and then write this all out to a file
(preferably just a plain old text file) and then read it in later so
that I can keep a running inventory.
[snip]

struct product
{
int stockNum;
string name;
float cost;
float price;
char tax;
};

At least make 'cost' and 'price' of type 'double'.

I would also consider making 'tax' a 'bool'. Otherwise, what happens if
'tax' is set to something besides 'Y' or 'N'?
 
F

Fei Liu

First of all I am very new to c++ so please bear with me. I am trying
to create a program that keeps an inventory of items. I am trying to
use a struct to store a product name, purchase price, sell price, and
a taxable flag (a Y/N char) and then write this all out to a file
(preferably just a plain old text file) and then read it in later so
that I can keep a running inventory. The problem that I am running
into is when I write to the file it seems save it but when I read it
back in it doesn't seem to give me anything. From what I have been
able to figure out so far you can't just save a String to a file you
have to manipulate it somehow but being very new (and not that good)
at c++ I can't figure out a practical way to do it.

Is there any simple way to handle this or might I be better off trying
to do it somehow other than a Struct?

This is what I have so far, tried to limit the code to what relates to
this problem so it might make a little more sense. If more is needed
will be happy to post.
*************************************
struct product
{
int stockNum;
string name;
float cost;
float price;
char tax;
};

product inventory[25];

ofstream st("c:/stock.txt");
ifstream stI("c:/stock.txt");

stI.read((char *)&inventory, sizeof(inventory));

if (stockChoice == 1)
{
stockChoice = 0;
inventory[counter].stockNum = counter;
cout << "Product Number: " << inventory[counter].stockNum;
cout << "\nEnter product name: ";
cin >> inventory[counter].name;
cout << "\nEnter product purchase cost: ";
cin >> inventory[counter].cost;
cout << "\nEnter product purchase price: ";
cin >> inventory[counter].price;
cout << "\nIs product taxable (Y/N): ";
cin >> inventory[counter].tax;
cout << "\n\nProduct Entered: " << inventory[counter].stockNum <<
inventory[counter].name << " " << inventory[counter].cost << " " <<
inventory[counter].price << " " << inventory[counter].tax;

counter++;
}

st.write((char *)&inventory, sizeof(inventory));
*********************************

Thank you!

I'd check boost::serialization..
 
J

James Kanze

First of all I am very new to c++ so please bear with me. I am trying
to create a program that keeps an inventory of items. I am trying to
use a struct to store a product name, purchase price, sell price, and
a taxable flag (a Y/N char) and then write this all out to a file
(preferably just a plain old text file) and then read it in later so
that I can keep a running inventory. The problem that I am running
into is when I write to the file it seems save it but when I read it
back in it doesn't seem to give me anything. From what I have been
able to figure out so far you can't just save a String to a file you
have to manipulate it somehow but being very new (and not that good)
at c++ I can't figure out a practical way to do it.

I presume that this is a school project, and not something that
will be actually used commercially. Otherwise, there are some
very serious problems.
Is there any simple way to handle this or might I be better off trying
to do it somehow other than a Struct?

Well, you already mentionned the best solution: plain old text.
But even with plain old text, you have to define a format.
(FWIW: since you're struct really just contains raw data, and
has no behavior, a struct seems perfectly appropriate. In a
real application, of course, you'd probably give it some
behavior, to ensure consistency between the various fields,
etc.)
This is what I have so far, tried to limit the code to what relates to
this problem so it might make a little more sense. If more is needed
will be happy to post.
*************************************
struct product
{
int stockNum;
string name;
float cost;
float price;
char tax;
};

First, as Alf said, make cost and price at least double. (In a
real application, it's more complicated, because of legally
imposed rounding rules which suppose a base 10 representation,
several different tax rates, etc., etc..)

The simplest solution (to implement) with regards to format is
to reserve a character as a field separator, say ':', and forbid
it in the name field, and put one record per line. So you'd end
up with something like:

std::eek:stream&
operator<<( std::eek:stream& dest, product const& source )
{
dest << stockNum << ':' << name << ':'
<< cost << ':' << price << ':' << tax << '\n' ;
return dest ;
}

Reading is a bit more complicated, because you have to do error
checking. In general, it's best to read line by line (in a line
oriented file, at least), since it allows easy resynchronization
in case of error, and also allows outputting a usable indication
of where the error occured (the line number). So you might end
up with something like:

std::istream&
operator>>( std::istream& source, product& dest )
{
std::string line ;
if ( getline( source, line ) ) {
parseLine( line, dest ) ;
}
return source ;
}

Parsing the line is pretty classical; you can use the individual
fields to initialize an std::istringstream to convert the
numeric values. (To do this, std::find and the two iterator
constructor of std::string seem indicated.)
product inventory[25];

Again, as Alf said, std::vector is a far better solution.
Until you know C++ fairly well, you shouldn't be using C style
arrays.
ofstream st("c:/stock.txt");
ifstream stI("c:/stock.txt");
stI.read((char *)&inventory, sizeof(inventory));

[...]
st.write((char *)&inventory, sizeof(inventory));
*********************************

And of course, all ostream::write and istream::read do is dump
and reload the memory. About the only time you use them is for
preformatted buffers. Like C style arrays, they're only for
programmers with a bit of experience. Globally, until you
understand a lot more about binary formats, etc., you should
only be using <<, >> and getline.

Using operators like the above, your code might become:

void
load( std::vector< product >& inventory )
{
std::ifstream file( "c:/stock.txt" ) ;
if ( ! file ) {
// Error handling, could not open...
// throw ... ?
}
std::copy( std::istream_iterator< product >( file ),
std::istream_iterator< product >(),
std::back_inserter( inventory ) ) ;
if ( ! file.eof() ) {
// Hard read error...
}
}

void
store( std::vector< product > const& inventory )
{
rename( "c:/stock.txt", "c:/stock.bak" ) ;
std::eek:fstream file( "c:/stock.txt" ) ;
std::copy( inventory.begin(), inventory.end(),
std::eek:stream_iterator< product >( file ) ) ;
file.close() ;
if ( ! file ) {
// Oops! Problem writing the data to disk.
// delete "c:/stock.txt" ?
// throw ... ?
}
}

and in main...

std::vector< product > inventory ;
load( inventory ) ;
process( inventory ) ;
save( inventory ) ;
 
A

asterisc

(e-mail address removed) a scris:
First of all I am very new to c++ so please bear with me. I am trying
to create a program that keeps an inventory of items. I am trying to
use a struct to store a product name, purchase price, sell price, and
a taxable flag (a Y/N char) and then write this all out to a file
(preferably just a plain old text file) and then read it in later so
that I can keep a running inventory. The problem that I am running
into is when I write to the file it seems save it but when I read it
back in it doesn't seem to give me anything. From what I have been
able to figure out so far you can't just save a String to a file you
have to manipulate it somehow but being very new (and not that good)
at c++ I can't figure out a practical way to do it.

Is there any simple way to handle this or might I be better off trying
to do it somehow other than a Struct?

This is what I have so far, tried to limit the code to what relates to
this problem so it might make a little more sense. If more is needed
will be happy to post.
*************************************
struct product
{
int stockNum;
string name;
float cost;
float price;
char tax;
};

product inventory[25];

ofstream st("c:/stock.txt");
ifstream stI("c:/stock.txt");

stI.read((char *)&inventory, sizeof(inventory));

if (stockChoice == 1)
{
stockChoice = 0;
inventory[counter].stockNum = counter;
cout << "Product Number: " << inventory[counter].stockNum;
cout << "\nEnter product name: ";
cin >> inventory[counter].name;
cout << "\nEnter product purchase cost: ";
cin >> inventory[counter].cost;
cout << "\nEnter product purchase price: ";
cin >> inventory[counter].price;
cout << "\nIs product taxable (Y/N): ";
cin >> inventory[counter].tax;
cout << "\n\nProduct Entered: " << inventory[counter].stockNum <<
inventory[counter].name << " " << inventory[counter].cost << " " <<
inventory[counter].price << " " << inventory[counter].tax;

counter++;
}

st.write((char *)&inventory, sizeof(inventory));
*********************************

Thank you!

And if all says about the expanding posibilities, i would add a
versioning system to that structure.
 
B

BobR

James Kanze said:
void load( std::vector< product >& inventory ){
std::ifstream file( "c:/stock.txt" ) ;
if ( ! file ) {
// Error handling, could not open...
// throw ... ?
}

Hi James,

Small nit:
{
std::ifstream file;
if( file ){
cout<<"This will print!";
} // else{ /* .... */ }
file<<"NOW it fails! <cussword here>"
}

I've taken to using:
{
std::ifstream file( "c:/stock.txt" );
if( not file.is_open() ){
throw "Failure to open file"; // handle failure
}
}

Have you found any problems using something like that?
( seems deja vu, but my CRS is getting worse. ;-} ).

[ Too many file systems, so little time!! [1]]
 
J

James Kanze

Small nit:
{
std::ifstream file;
if( file ){
cout<<"This will print!";
} // else{ /* .... */ }
file<<"NOW it fails! <cussword here>"
}

Without the else:).

I don't know what the requirements are in case of failure, so I
just left it blank. In a typical school project, simply
outputting an error message and exiting might be sufficient.
Obviously, of course, you don't want to go beyond the if.

In production code, the code generally ends up looking something
like:

std::ifstream file( "c:/stock.txt" ) ;
if ( ! file ) {
// Error handling ...
} else {
process( file ) ;
if ( ! file.eof() || file.bad() ) {
// Error handling...
}
}
I've taken to using:
{
std::ifstream file( "c:/stock.txt" );
if( not file.is_open() ){
throw "Failure to open file"; // handle failure
}
}
Have you found any problems using something like that?

It depends on context. If you can't handle the error locally,
it's probably the best solution. If you can, then you should do
so.

Of course, I'd throw std::ios_base::failure, or something
derived from it, and not a string literal.
 
B

BobR

James Kanze wrote in message ...

/* """
Small nit:
{
std::ifstream file;
if( file ){
cout<<"This will print!";
} // else{ /* .... */ }
file<<"NOW it fails! <cussword here>"
}

Without the else:).

I don't know what the requirements are in case of failure, so I
just left it blank. In a typical school project, simply
outputting an error message and exiting might be sufficient.
Obviously, of course, you don't want to go beyond the if.

In production code, the code generally ends up looking something
like:

std::ifstream file( "c:/stock.txt" ) ;
if ( ! file ) {
// Error handling ...
} else {
process( file ) ;
if ( ! file.eof() || file.bad() ) {
// Error handling...
}
}
I've taken to using:
{
std::ifstream file( "c:/stock.txt" );
if( not file.is_open() ){
throw "Failure to open file"; // handle failure
}
}
Have you found any problems using something like that?

It depends on context. If you can't handle the error locally,
it's probably the best solution. If you can, then you should do
so.
Of course, I'd throw std::ios_base::failure, or something
derived from it, and not a string literal.
""" */

[ ref: > Have you found any problems using something like that? ]

Yeah, I was as clear as mud on that one! <G>

I meant (can't you read minds?) the difference between:

std::ifstream file;
if( file ){ cout<<"This will print!"; }
// illustrates that even tho' a file is not opened, the stream is valid.
.... and:
if( file.is_open() ){ cout<<"This will NOT print!"; }

In other words, I was asking if you have noticed any problem with using
'.is_open()' (vs. just testing the stream object)?
(let's assume there is some reason to do it that way. <G>)
No need to answer this unless you have some caution/warnings to give.

I'm pretty sure I know how/when/what exceptions to throw, but, thanks for
the info anyway. I'm in agreement with you on that part.
[ I should have shown the 'error handling' part the way you did originally
(commented)(that wasn't part of my ?). ]
 
R

Ricardo

* (e-mail address removed):






At least make 'cost' and 'price' of type 'double'.

Be careful when typing prices as double, it could bother you. I think
double should be used in cases where a floating points really makes
sense. GIS for instance. Sometimes an int/long works pretty fine, just
makeup the values to the user and that's ok.
product inventory[25];

Don't use globals.

And don't use raw arrays.

Why not raw arrays? It sounds obligatory...something like I can't open
my window because I have an air-conditioned.
Use std::vector, and use its 'at' function instead of []-indexing (it's
safer in that it detects range errors).
ofstream st("c:/stock.txt");
ifstream stI("c:/stock.txt");
stI.read((char *)&inventory, sizeof(inventory));

As a novice, don't /ever/ use casts, especially not C style casts.

I agree not using C style casts...but C++ style is ok, so why did
Stroustrup make the xxx_cast<>()?
I think even reinterpret_cast is useful when you know what you're
doing.
That means that 'read' is an ungood function for the kinds of problems
you'll be solving, and the kind of problem you are solving right now.

here is a good example...
Suppose you have a the following struct:

struct {
char one[10];
char two[35];
char thr[15];
} bla_;

reinterpret_cast<char*>(bla_); is not a such bad think at all, let's
see why:

1 - char* is a C style string.
2 - C doesnt have strings, so char* is a /0 array convention.
3 - an array is GUARANTEED to be a memory continous area;
4 - a struct is NOT GUARANTED to be a memory continous area due to the
machine aligning aptimization HOWEVER
5 - as my bla_ struct is only composed of chars it will be a memory
continous area, like an array.


SO, if I have a "char tmp[60];" the
if (sizeof(tmp) == sizeof(bla_)) will be TRUE.

Jose
 
A

Alf P. Steinbach

* Ricardo:
Be careful when typing prices as double, it could bother you.

That's right. Therefore, at least make them double. Better, choose
some representation with more digits (usually fixed point).

I think
double should be used in cases where a floating points really makes
sense. GIS for instance. Sometimes an int/long works pretty fine, just
makeup the values to the user and that's ok.

Usually the range of int and long is too small to handle monetary values.

product inventory[25];
Don't use globals.

And don't use raw arrays.

Why not raw arrays? It sounds obligatory...something like I can't open
my window because I have an air-conditioned.

Raw arrays are dangerous for the novice and the typical programmer (and
maintainance programmers are mostly typical programmers), because (1)
raw arrays introduce problems with memory management, and (2) raw arrays
don't do range checking of indexing, or of pointer arithmetic.

Use std::vector, and use its 'at' function instead of []-indexing (it's
safer in that it detects range errors).
ofstream st("c:/stock.txt");
ifstream stI("c:/stock.txt");
stI.read((char *)&inventory, sizeof(inventory));
As a novice, don't /ever/ use casts, especially not C style casts.

I agree not using C style casts...but C++ style is ok, so why did
Stroustrup make the xxx_cast<>()?
I think even reinterpret_cast is useful when you know what you're
doing.

Even professionals don't always know what they're doing. A cast causes
the compiler to shut up. As a novice you want or should ideally want
the opposite: the best is when the compiler complains about even the
just slightly suspicious code, and you're ensuring 100% clean compiles.

That means that 'read' is an ungood function for the kinds of problems
you'll be solving, and the kind of problem you are solving right now.

here is a good example...
Suppose you have a the following struct:

struct {
char one[10];
char two[35];
char thr[15];
} bla_;

reinterpret_cast<char*>(bla_); is not a such bad think at all, let's
see why:

1 - char* is a C style string.

Not necessarily.

2 - C doesnt have strings, so char* is a /0 array convention.

Not necessarily.

3 - an array is GUARANTEED to be a memory continous area;
Yes.


4 - a struct is NOT GUARANTED to be a memory continous area
Yes.


due to the
machine aligning aptimization

Well, due to some reasons. ;-) But this makes me wonder what you mean
by "continuous", which I take it is a misspelling of "contiguous". I
think that what you mean is possibly not the usual that all of the
struct's data is between two memory addresses where there's nothing but
the struct's data and unused memory. I think you mean there's no
padding. That a struct is not guaranteed to have no padding. And
that's also true.

HOWEVER
5 - as my bla_ struct is only composed of chars it will be a memory
continous area, like an array.

Yes in the usual sense of "contiguous", but no in the sense of no padding.

SO, if I have a "char tmp[60];" the
if (sizeof(tmp) == sizeof(bla_)) will be TRUE.

Sorry, that's incorrect. You're guaranteed that 'one' is at the same
address as 'bla_' (because it's a POD), but that's all. The compiler is
free to insert padding anywhere else than at the start.

So, being wrong about that, you don't (yet) know what you're doing at
the level of reinterpret_cast.

Don't use it.


Cheers,

- Alf
 
J

James Kanze

On May 21, 3:03 pm, "Alf P. Steinbach" <[email protected]> wrote:

[...]
Be careful when typing prices as double, it could bother you. I think
double should be used in cases where a floating points really makes
sense. GIS for instance. Sometimes an int/long works pretty fine, just
makeup the values to the user and that's ok.

Double will cause problems if the code has to conform to legally
imposed bookkeeping rules. It's probably the best choice
otherwise. Int/long may be too small, even for centimes, and
probably won't round correctly most of the time when calculating
things like tax. (There will be some very special cases where
double won't round correctly either, but I doubt that they'd be
relevant for a school project; they aren't even always relevant for
commercial software.)
product inventory[25];
Don't use globals.
And don't use raw arrays.
Why not raw arrays? It sounds obligatory...something like I can't open
my window because I have an air-conditioned.

Or something like: don't go looking for trouble when you don't
have to. I'm not exactly a novice, but about the only time I
use C style arrays is when I need static initialization, to
solve an order of initialization problem. Not the sort of
problem a novice is going to encounter.
Use std::vector, and use its 'at' function instead of []-indexing (it's
safer in that it detects range errors).

I sort of disagree on this one. In the implementations I use,
both at() and operator[] detect range errors, and the behavior
when operator[] detects one is more useful.
I agree not using C style casts...but C++ style is ok, so why did
Stroustrup make the xxx_cast<>()?

Maybe because not every one who uses C++ is expected to be a
novice.
I think even reinterpret_cast is useful when you know what you're
doing.

Certainly. I use it myself sometimes in low level system
programming. The sort of thing you don't attack until you have
some real experience with simpler things.
here is a good example...
Suppose you have a the following struct:
struct {
char one[10];
char two[35];
char thr[15];
} bla_;
reinterpret_cast<char*>(bla_); is not a such bad think at all, let's
see why:
1 - char* is a C style string.

No. It's a pointer. A C style string is an array.
2 - C doesnt have strings, so char* is a /0 array convention.

Not necessarily. In the above, probably not.
3 - an array is GUARANTEED to be a memory continous area;

An array is guaranteed to be contiguous, for a sufficiently
loose definition of contiguous. An array of char is guaranteed
to be contiguous for all reasonable definitions.
4 - a struct is NOT GUARANTED to be a memory continous area due to the
machine aligning aptimization HOWEVER
5 - as my bla_ struct is only composed of chars it will be a memory
continous area, like an array.

Maybe. The standard doesn't guarantee it, although it happens
to be true for a lot of compilers, at least on byte addressed
machines.
SO, if I have a "char tmp[60];" the
if (sizeof(tmp) == sizeof(bla_)) will be TRUE.

Not guaranteed.

I've used something from time to time, but only in non-portable
software, with an assert that the assumption was true. It's
more or less acceptable in low-level programming by an expert,
who understands the restrictions, and in particular, the lack of
portability. It's not something I'd recommend to a novice. (In
my case, it was more or less an experiment, and I don't think
I'll do it again. Doing it this way instead of the more
classical way of defining integral constants for the width and
offset of each field didn't gain enough elsewhere to be worth
the loss of portability.)
 
A

Alf P. Steinbach

* Pete Becker:
You must have a lot more money than I do.

Wish it was so... :) Yes you're right, it depends on the application.
But in general, on a 32-bit system, and most systems today are still
32-bit, long can be expected to be 32 bits, and that's about two US
billion, not even enough for a medium sized construction project (the
first time 1 billion was exceeded for the pure budget /overruns/ for a
reasonably small project in Norway, we called it a "Mong", for Mongstad,
the place where the project was, but the expression went out of use when
this scale of overruns became common).

Cheers,

- Alf
 
P

peter koch

You must have a lot more money than I do.

I don't know how rich Alf is, but in many financial applications, a
precision of 1/100.000 is required. This is the case e.g. if you use
multiple currencies. Thus, a 32 bit integer will not even be able to
represent an amount of 100.000 which is a huge sum for me, but not for
a company.

/Peter
 
P

Pete Becker

peter said:
I don't know how rich Alf is, but in many financial applications, a
precision of 1/100.000 is required. This is the case e.g. if you use
multiple currencies. Thus, a 32 bit integer will not even be able to
represent an amount of 100.000 which is a huge sum for me, but not for
a company.

Sheesh. No sense of humor. But even for the humor-impaired, not that
"many financial applications" is not "all financial applications."

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
 
P

peter koch

Sheesh. No sense of humor. But even for the humor-impaired, not that
"many financial applications" is not "all financial applications."

Well - I did get your (and Alfs) humour, just wanted to add a bit of
seriousness back ;-)

/Peter
 
J

James Kanze

* Pete Becker:
Wish it was so... :) Yes you're right, it depends on the application.
But in general, on a 32-bit system, and most systems today are still
32-bit, long can be expected to be 32 bits, and that's about two US
billion,

Typically, that will be 2 billion cents. Which is "only" about
20 million dollars/euros/whatever. While that's still probably
largely sufficient to handle the yearly income of most people
reading this group, there are a lot of companies, and even some
individuals, where it won't suffice.
not even enough for a medium sized construction project (the
first time 1 billion was exceeded for the pure budget /overruns/ for a
reasonably small project in Norway, we called it a "Mong", for Mongstad,
the place where the project was, but the expression went out of use when
this scale of overruns became common).

I wonder: is that where the English word "humongous" comes from?
(The online Merriam-Webster says simply "perhaps alteration of
huge + monstrous". Another source gives the first appearance as
1968---would that be before or after Mong in Norwegian?)
 
R

Ricardo

Thank you James and Alf, I got what you said. It´s really good posting
here because you guys really know what you´re saying.

Ricardo
 
R

Ricardo

Thank you James and Alf, I got the point. It´s really good posting
here cause you guys know what you´re saying.

Ricardo
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,294
Messages
2,571,511
Members
48,198
Latest member
couriermedicine

Latest Threads

Top