Help with typedef

[Daniel T.]

The short answer is:
Im trying to learn.
When i ask a question like this, i would be so much easyer if you would
either say that there is no solution, witch ofcourse wrong, as there,
in my experience allways is, a solution, or simply refrain from
answering or say that you dont know the answer ect.

however, i do actually have a problem witch need a solution.

i need to store alot of different values from 0 -> 0xffffffff eg. they
can be contained in a unsigned long/unsigned int, however, a single
vector cant contan them as the limit to how many values it can contain
is something like 0x4000000 and i need to store more.

Vector has to deal with the limits of the addressable memory in the
machine... A deque can hold more.

Try this:

int main() {
deque< unsigned long > d;
cout << d.max_size();
}

Frankly, I don't think you need all that space. I'm guessing you could
read/write the file a little at a time rather than trying to store the
whole thing in memory.

What i need is at class/function that can take 2 or more vector and
treath them as one plus initiate a new one if nesacery.

That's what deque does.

 

[felixnielsen]

Rolf Magnus skrev:

An unsigned int might not be enough then, because depending on the compiler,
it can be as small as 16 bits.

im aware of that which is the reason i what to define my own variables.

How did you determine that value? Through the max_size() member function? Or
by just trying? Do you have enough RAM for this? Does your compiler support
single memory blocks that big? 0x4000000 values would take 256MB of memory.
Depending on how you add new values (if you use push_back() without a
previous reserve()), it will probably need a lot more memory. It could
easily be three times as much temporarily.

I tryed my way at first, then someone told me about the max_size()
function, the funny thing though is that by trying, and i have tested
that this works, i get the sixe 0x4000000, but when using max_size() i
get0x3ffffff.
I do have 1 GB of ram + a 4GB pagefile, however the exstreme use of
memory is yet another reason to otimize this.

I fail to see what that has to do with your typedef question.

explained above.

 

[felixnielsen]

Daniel T. skrev:

Vector has to deal with the limits of the addressable memory in the
machine... A deque can hold more.

Try this:

int main() {
deque< unsigned long > d;
cout << d.max_size();
}

Thanks for the input, i wasnt aware of that, however its my experience
that a deque use a great deal more memory, but maybe im mistaken.

Frankly, I don't think you need all that space. I'm guessing you could
read/write the file a little at a time rather than trying to store the
whole thing in memory.

i agree, but 2 problems remain:
1)
How do i treat a regular txt file as a vector/deque/array, what i mean
is, how do i pull line 1,2 or 3 ect. when i need it?
2)
Wont reading/writing from/to disc all the time slow down the process? I
am playing around with a file the size of 2-4 GB witch is alot.

That's what deque does.

Once again, if that true im greatfull, but it does seem to use a hole
lot of memory...

 

[Daniel T.]

Daniel T. skrev:


Thanks for the input, i wasnt aware of that, however its my experience
that a deque use a great deal more memory, but maybe im mistaken.

'deque' uses the absolute least amount of memory that can be used and
still get the effect of "a class that can take multiple vectors and
treat them as one, plus initiate a new one if necessary."

i agree, but 2 problems remain:
1)
How do i treat a regular txt file as a vector/deque/array, what i mean
is, how do i pull line 1,2 or 3 ect. when i need it?

For that, you could use. Each item in the deque would be a line. Or you
could have a vector of deque::iterators which would act as offsets into
the deque representing the start of each line.

But I thought you wanted unsigned longs? What does this file look like
(give us say 5 lines worth of data?) What kind of manipulations are you
trying to do to it?

2)
Wont reading/writing from/to disc all the time slow down the process? I
am playing around with a file the size of 2-4 GB witch is alot.

The reading and writing is buffered to provide the fastest possible
access. As long as you are handling the information linearly, there
should be no problem with speed, if you expect random access into the
file, then there might be a problem.

If the file is just text, you might also want to check out sgi's "rope"
class. It may be able to compress the file somewhat in ram. In fact
sgi's "rope" class is specifically designed for representing very large
strings. <http://www.sgi.com/tech/stl/Rope.html>

 

[felixnielsen]

Daniel T. skrev:

'deque' uses the absolute least amount of memory that can be used and
still get the effect of "a class that can take multiple vectors and
treat them as one, plus initiate a new one if necessary."

I cant help wondering, why not just use deques instead of vectors all
the time?

For that, you could use. Each item in the deque would be a line. Or you
could have a vector of deque::iterators which would act as offsets into
the deque representing the start of each line.

But I thought you wanted unsigned longs? What does this file look like
(give us say 5 lines worth of data?) What kind of manipulations are you
trying to do to it?

I have severel projects up and running, here is one of them, what they
all have in commen is that they work with wery large number and lots of
them.
Here is a prime generator i made, i have reasently chances some thing
and i have tested it, but it should work.

@code start
#include <deque>
#include <cmath>
#include <fstream>
#include <iterator>
std::deque<unsigned long> read_primes() { // Here we read the number
from 'primes.txt'
std::deque<unsigned long> P; // A deque named P i born
std::ifstream primes("primes.txt"); // Opening the file
'primes.txt' for reading
if (!primes) { // Does 'primes.txt even
excist?
primes.close(); // If not, we close the read
session
P.push_back(3); // Add the number '3' to the
back of the deque
std:fstream primes("primes.txt", // Opening file 'primes.txt'
for writing
std::ios:ut| //
std::ios::app); //
primes << "2" << std::endl; // Then we are writing the
nubmer '2'
primes << P.back() << std::endl; // And the back value of P
('3')
primes.close(); // And closes the file for
writing
} // End if
else if (primes){ // Else if 'primes.txt' does
excist
copy(std::istream_iterator<unsigned long>(primes), // Read the file
std::istream_iterator<unsigned long>(), // line for line until
the end
back_inserter(P)); // and stuff each number in
the back of P
primes.close(); // We close the file again
P.pop_front(); // The fist number in P
should now be '2'
} // We dont need that so away
it goes
return P; // Last but not least we
return P to main()
} // End of read_primes()
int main() { // main() contains the prime
generator
std::deque<unsigned long>P;
unsigned long long i;
double root;
bool is_prime;
P = read_primes();
std:fstream primes("primes.txt",std::ios:ut|std::ios::app);
for (unsigned long long test = P.back() + 2; test != 1; test += 2) {
root = sqrt(test);
for (i = 0, is_prime = true; P <= root && is_prime == true; i++)
if (test % P == 0) is_prime = false;
if (is_prime == true && test <= 0xffffffff) P.push_back(test);
if (is_prime == true) primes << P.back() << std::endl;
}
primes.close();
}
@code end

There is severel things that have i have though about.
1)
'primes.txt' will get wery large wery quick, ofcourse it cant ba
avoidet, however if you take an excample like 1234567890 it can take up
as little or less as 4 byte i memory, while in the file it takes up 10
bytes. It is easy to understand why, the question is can you do
anything about it?
2)
I am using 2 different types here (the rest is not important) unsigned
long and unsigned long long, the need to work the same, wether i
compile on dev-c++ like i do now, or use something else. I have, on
severel ecations been told that this is not the case. Thats one of the
reasons i want to define my own types from scrats, but i guess its not
as simple as it sounds.
3)
Last you might wonder why 'P' is unsigned long while 'test' is unsigned
long long.
The reason is that there is no need to declare 'P' unsigned long long,
this type can contain as big values needed to test if 'test' is prime.

The reading and writing is buffered to provide the fastest possible
access. As long as you are handling the information linearly, there
should be no problem with speed, if you expect random access into the
file, then there might be a problem.

If the file is just text, you might also want to check out sgi's "rope"
class. It may be able to compress the file somewhat in ram. In fact
sgi's "rope" class is specifically designed for representing very large
strings. <http://www.sgi.com/tech/stl/Rope.html>

it is just number, anyway, i dont want to download a hole lot of weird
classes and headers and stuff that i dont understand.
Thanks anyway.

 

[Daniel T.]

Daniel T. skrev:


I cant help wondering, why not just use deques instead of vectors all
the time?

At one point, even the likes of Herb Sutter was asking that question.
<http://www.gotw.ca/gotw/054.htm> AFAICT, vector is used by default
because the standard says to use it by default (despite the fact that
they use deque by default in the standard adapters like stack.)

I have severel projects up and running, here is one of them, what they
all have in commen is that they work with wery large number and lots of
them.
Here is a prime generator i made, i have reasently chances some thing
and i have tested it, but it should work.

[Interesting prime code snipped]

You don't need a deque, or any other kind of container for prime
numbers. Primes are already a sequence, and you can represent them with
an iterator. I've already done this, but I'm not going to show my code,
better for you to do it yourself. Here is the interface though:

class primes:
public std::iterator< std::forward_iterator_tag, unsigned long >
{

public:
primes(); // create a sentinel object
explicit primes(unsigned long m); // 'm' is how many primes
// that will be in the sequence
unsigned long operator*() const; // return the current prime
primes& operator++(); // advance to the next prime
primes operator++(int) { primes tmp(*this); ++(*this); return tmp; }
friend bool operator==(const primes& lhs, const primes& rhs);
// if one of the inputs is a sentinel and the other is at the end
// of its sequence, return true. Otherwise check to see if the
// two inputs are pointing to the same prime, and will have the
// same effect if advanced.
};

bool operator!=(const primes& lhs, const primes& rhs) {
return !(lhs == rhs);
}


With the above, you can generate your primes file without taking up lots
of memory:

int main() {
ofstream file("primes.txt");
copy(primes(/*number of primes to write*/), primes(),
ostream_iterator<unsigned long>(file, "\n"));
}

If you write the primes class right, the memory requirements of the
above will remain constant no matter how many primes you write to the
file.

There is severel things that have i have though about.
1)
'primes.txt' will get wery large wery quick, ofcourse it cant ba
avoidet, however if you take an excample like 1234567890 it can take up
as little or less as 4 byte i memory, while in the file it takes up 10
bytes. It is easy to understand why, the question is can you do
anything about it?

Open the file as binary. Reading and writing to it will be tricker
though. Look up the ifstream::read and ofstream::write functions.

(hint) I would use a union for this:

union Buffer {
char c[sizeof(unsigned long)];
unsigned long i;
};

2)
I am using 2 different types here (the rest is not important) unsigned
long and unsigned long long, the need to work the same, wether i
compile on dev-c++ like i do now, or use something else. I have, on
severel ecations been told that this is not the case. Thats one of the
reasons i want to define my own types from scrats, but i guess its not
as simple as it sounds.

They don't really need to work the same, you should write your code so
that it works no matter the size of the types (hint: lookup
"numeric_limits".)

Note, if you go with a binary file the same file won't necessarily work
on all platforms (hint: lookup "endian".) There are things you can do to
fix that...

 

[TB]

(e-mail address removed) sade:

Daniel T. skrev:


I cant help wondering, why not just use deques instead of vectors all
the time?

A good book, like Josuttis' The C++ Standard Library, might help
explain why there are different containers.

 

[felixnielsen]

Frankly, I don't think you need all that space. I'm guessing you could

I have severel projects up and running, here is one of them, what they
all have in commen is that they work with wery large number and lots of
them.
Here is a prime generator i made, i have reasently chances some thing
and i have tested it, but it should work.

[Interesting prime code snipped]

You don't need a deque, or any other kind of container for prime
numbers. Primes are already a sequence, and you can represent them with
an iterator. I've already done this, but I'm not going to show my code,
better for you to do it yourself. Here is the interface though:

class primes:
public std::iterator< std::forward_iterator_tag, unsigned long >
{

public:
primes(); // create a sentinel object
explicit primes(unsigned long m); // 'm' is how many primes
// that will be in the sequence
unsigned long operator*() const; // return the current prime
primes& operator++(); // advance to the next prime
primes operator++(int) { primes tmp(*this); ++(*this); return tmp; }
friend bool operator==(const primes& lhs, const primes& rhs);
// if one of the inputs is a sentinel and the other is at the end
// of its sequence, return true. Otherwise check to see if the
// two inputs are pointing to the same prime, and will have the
// same effect if advanced.
};

bool operator!=(const primes& lhs, const primes& rhs) {
return !(lhs == rhs);
}


With the above, you can generate your primes file without taking up lots
of memory:

int main() {
ofstream file("primes.txt");
copy(primes(/*number of primes to write*/), primes(),
ostream_iterator<unsigned long>(file, "\n"));
}

If you write the primes class right, the memory requirements of the
above will remain constant no matter how many primes you write to the
file.

This is wery interesting and all (i the good kinda way) but i have only
been coding for about 3 weeks, seems a bit to advanced for me, defining
my own iterator havent even got to understand classes yet... ;(

Open the file as binary. Reading and writing to it will be tricker
though. Look up the ifstream::read and ofstream::write functions.

Why didnt i think of that?
Well thanks for the answer on that one. ;-)

(hint) I would use a union for this:

union Buffer {
char c[sizeof(unsigned long)];
unsigned long i;
};

I dont understand what i should use above piece of code for. please
axplain if you have got the time.

They don't really need to work the same, you should write your code so
that it works no matter the size of the types (hint: lookup
"numeric_limits".)

If i understand what you mean, as i probably dont, i dont like the
solution at all, i havent yet looked it up, but im not happy about
"limitations" being the answer.

Note, if you go with a binary file the same file won't necessarily work
on all platforms (hint: lookup "endian".) There are things you can do to
fix that...

I looked it up and i must admit that i dont se any use for it at all
(guess i have looked the wrong place) and i certainly dont see how it
can solve the problem you are talking about, however i dont think its a
problem as the file wont have to work on aother platforms that the one
the program is compiled for.

Once again thanks for all the feedback.

Regards

 

[Daniel T.]

This is wery interesting and all (i the good kinda way) but i have only
been coding for about 3 weeks, seems a bit to advanced for me, defining
my own iterator havent even got to understand classes yet... ;(

That's why I provided the interface and all the notes about what each
member-function is supposed to do. Try it, it's only 5 functions...

Open the file as binary. Reading and writing to it will be tricker
though. Look up the ifstream::read and ofstream::write functions.

Why didnt i think of that?
Well thanks for the answer on that one. ;-)

(hint) I would use a union for this:

union Buffer {
char c[sizeof(unsigned long)];
unsigned long i;
};

I dont understand what i should use above piece of code for. please
axplain if you have got the time.

ifstream::read and ofstream::write take char* buffers, but you want an
unsigned long... Using the above code:

Buffer buf;
buf.i = myUnsignedLong; // buf.i is an unsigned long variable
myStream.write( buf.c, sizeof(buf) ); // buf.c is a char array that
points to the same bit of ram that buf.i points to.

Run the program below and you will see what I mean:

union Buffer {
char c[sizeof(unsigned long)];
unsigned long i;
};

int main() {
Buffer buf;
buf.i = 0x12345678;
for ( int x = 0; x < sizeof(buf); ++x )
cout << hex << static_cast<unsigned int>(buf.c[x]) << ", ";
}

If i understand what you mean, as i probably dont, i dont like the
solution at all, i havent yet looked it up, but im not happy about
"limitations" being the answer.

Sorry, limitations are part of computing. Different computers have
different limits on how big a number they can store and easily compute
with. There are libraries that allow you to work with arbitrarily large
integers, but unless you are being paid to write this program, I doubt
it's worth it.

 

[felixnielsen]

I dont understand what i should use above piece of code for. please

axplain if you have got the time.

ifstream::read and ofstream::write take char* buffers, but you want an
unsigned long... Using the above code:

Buffer buf;
buf.i = myUnsignedLong; // buf.i is an unsigned long variable
myStream.write( buf.c, sizeof(buf) ); // buf.c is a char array that
points to the same bit of ram that buf.i points to.

Run the program below and you will see what I mean:

union Buffer {
char c[sizeof(unsigned long)];
unsigned long i;
};

int main() {
Buffer buf;
buf.i = 0x12345678;
for ( int x = 0; x < sizeof(buf); ++x )
cout << hex << static_cast<unsigned int>(buf.c[x]) << ", ";
}

I think i understand how the code works now, not quite why i need it,
but ill get to that, however it has at bug.

@code start
#include <iostream>

union Buffer {
char c[sizeof(unsigned long)];
unsigned long i;
};

int main() {
Buffer buf;
buf.i = 0x92345678;
for (int x = sizeof(buf)-1; x >= 0; x--)
std::cout << std::hex << static_cast<unsigned long>(buf.c[x]) <<
", ";
std::cin.get();
}
@code end
first, i have changed the value of buf.i, important to nitice, because
the code works fine with ox123456780.
Then i have changed some minor thing so that the numbers is printed the
the right order.
if you try to run this program it will work, but not quite the way you
whant it to, maybe it doesnt matter, but in that case i dont understand
nothing.

Now the "i dont understand part"
What to use it for?

first, here is my primecode as it looks now:
@code start
#include <iostream>
#include <deque>
#include <cmath>
#include <fstream>
#include <iterator>
std::deque<unsigned long> read_primes() {
std::deque<unsigned long> P;
std::ifstream primes("primes.txt",
std::ios::in|
std::ios::binary);
if (primes){
copy(std::istream_iterator<unsigned long>(primes),
std::istream_iterator<unsigned long>(),
back_inserter(P));
P.pop_front();
}
else {
primes.close();
P.push_back(3);
std:fstream primes("primes.txt",
std::ios:ut|
std::ios::binary|
std::ios::app);
primes << "2"
<< std::endl;
primes << P.back()
<< std::endl;
}
primes.close();
return P;
}
int main() {
std::deque<unsigned long>P;
unsigned long long i;
double root;
bool is_prime;
std::cout << "Reading primes from file... ";
P = read_primes();
std::cout << "Done!"
<< std::endl;
std::cout << P.size()+1
<< " primes read from file"
<< std::endl;
std::cout << "press enter to start the search";
std::cin.get();
std::cout << "Searching for primes between "
<< P.back()
<< " and "
<< pow(2,64)-1
<< "... ";
std:fstream primes("primes.txt",
std::ios:ut|
std::ios::binary|
std::ios::app);
for (unsigned long long test = P.back() + 2; test != 1; test += 2) {
root = sqrt(test);
for (i = 0, is_prime = true; P <= root && is_prime == true; i++)
if (test % P == 0)
is_prime = false;
if (is_prime == true && test <= 0xffffffff)
P.push_back(test);
if (is_prime == true)
primes << P.back()
<< std::endl;
}
primes.close();
std::cout << "Done!"
<< std::endl;
std::cout << P.size()+1
<< " primes was found between 0 and "
<< pow(2,64)-1;
std::cin.get();
}
@code end

Besides from aome text and stuff, the only great difference is that i
have changed the read/write to binary, and it works fine, that the
first reason i dont understand what i should use your ingeenious code
for. The other reason is that im stupid, but eh, thats not your
problem.

about the code though.
I have some doubt about what will happen when test > 0xffffffff
and i need some kinda limit so when i read from the file, i dont takes
value higher than 0xffffffff.

regards

 

[Daniel T.]

I dont understand what i should use above piece of code for. please
axplain if you have got the time.

ifstream::read and ofstream::write take char* buffers, but you want an
unsigned long... Using the above code:

Buffer buf;
buf.i = myUnsignedLong; // buf.i is an unsigned long variable
myStream.write( buf.c, sizeof(buf) ); // buf.c is a char array that
points to the same bit of ram that buf.i points to.

Run the program below and you will see what I mean:

union Buffer {
char c[sizeof(unsigned long)];
unsigned long i;
};

int main() {
Buffer buf;
buf.i = 0x12345678;
for ( int x = 0; x < sizeof(buf); ++x )
cout << hex << static_cast<unsigned int>(buf.c[x]) << ", ";
}

I think i understand how the code works now, not quite why i need it,
but ill get to that, however it has at bug.

Don't count on it. ;-)

@code start
#include <iostream>

union Buffer {
char c[sizeof(unsigned long)];
unsigned long i;
};

int main() {
Buffer buf;
buf.i = 0x92345678;
for (int x = sizeof(buf)-1; x >= 0; x--)
std::cout << std::hex << static_cast<unsigned long>(buf.c[x]) <<
", ";
std::cin.get();
}
@code end
first, i have changed the value of buf.i, important to nitice, because
the code works fine with ox123456780.
Then i have changed some minor thing so that the numbers is printed the
the right order.

That is where subject 'endian' comes in. On my machine, my program
printed the numbers out in the correct order, on your machine you had to
reverse the bytes to get it to print correctly.

if you try to run this program it will work, but not quite the way you
whant it to, maybe it doesnt matter, but in that case i dont understand
nothing.

Now the "i dont understand part"
What to use it for?

The 'read' and 'write' member functions require char*, but you want to
write an unsigned long*... The union is a simple way to convert from one
to the other.

Besides from aome text and stuff, the only great difference is that i
have changed the read/write to binary, and it works fine, that the
first reason i dont understand what i should use your ingeenious code
for. The other reason is that im stupid, but eh, thats not your
problem.

Did you look at the file after your program wrote it? It still
represents the primes as ascii values, not binary. You didn't save the
space that you wanted to save.

You opened the file as binary, but then you used op<< and endl to put
the numbers into the file. Those operators convert to text. Again, you
need to look up the 'read' and 'write' member-functions of fstream.

about the code though.
I have some doubt about what will happen when test > 0xffffffff
and i need some kinda limit so when i read from the file, i dont takes
value higher than 0xffffffff.

Check it in your for loop. Currently you have test != 1, test will never
equal 1 so you are effectively looping forever. Assuming an unsigned
long long can hold values greater than 0xFFFFFFFF, you need to test for
that condition in the for loop.

 

[felixnielsen]

Daniel T. skrev:

I dont understand what i should use above piece of code for. please
axplain if you have got the time.

ifstream::read and ofstream::write take char* buffers, but you want an
unsigned long... Using the above code:

Buffer buf;
buf.i = myUnsignedLong; // buf.i is an unsigned long variable
myStream.write( buf.c, sizeof(buf) ); // buf.c is a char array that
points to the same bit of ram that buf.i points to.

Run the program below and you will see what I mean:

union Buffer {
char c[sizeof(unsigned long)];
unsigned long i;
};

int main() {
Buffer buf;
buf.i = 0x12345678;
for ( int x = 0; x < sizeof(buf); ++x )
cout << hex << static_cast<unsigned int>(buf.c[x]) << ", ";
}

I think i understand how the code works now, not quite why i need it,
but ill get to that, however it has at bug.

Don't count on it. ;-)

@code start
#include <iostream>

union Buffer {
char c[sizeof(unsigned long)];
unsigned long i;
};

int main() {
Buffer buf;
buf.i = 0x92345678;
for (int x = sizeof(buf)-1; x >= 0; x--)
std::cout << std::hex << static_cast<unsigned long>(buf.c[x]) <<
", ";
std::cin.get();
}
@code end
first, i have changed the value of buf.i, important to nitice, because
the code works fine with ox123456780.
Then i have changed some minor thing so that the numbers is printed the
the right order.

That is where subject 'endian' comes in. On my machine, my program
printed the numbers out in the correct order, on your machine you had to
reverse the bytes to get it to print correctly.
<http://www.rdrop.com/~cary/html/endian_faq.html>[/QUOTE]
i still dont get the endian stuff, it can reverse the bits yes, but so
can what i have done.

The 'read' and 'write' member functions require char*, but you want to
write an unsigned long*... The union is a simple way to convert from one
to the other.


Did you look at the file after your program wrote it? It still
represents the primes as ascii values, not binary. You didn't save the
space that you wanted to save.

Yes i did look at the file and i didnt see a single number, however i
saw like a billion of endl squares ;-) i could live without them.
bout the space, the file take up half or less of the space it did
before and i have had the program running for a day and a half now.

You opened the file as binary, but then you used op<< and endl to put
the numbers into the file. Those operators convert to text. Again, you
need to look up the 'read' and 'write' member-functions of fstream.


Check it in your for loop. Currently you have test != 1, test will never
equal 1 so you are effectively looping forever. Assuming an unsigned
long long can hold values greater than 0xFFFFFFFF, you need to test for
that condition in the for loop.

i have solved the problem i was concerned about by splitting the
numbers < 0xffffffff and the numbers > 0xffffffff up in two different
files.
As for the neverending for loop i disagree.
I should think that the result of the code below equals 1.
@code start
unsigned long long test = 0xffffffffffffffff; // i have had some
troubles asigning values greater than 0xffffffff so you might wanna do
it like this: 0xffffffff*0xffffffff+2*0xffffffff
test += 2;
@code end

Now i havent testet this, but in my experience when a variable reaches
a value higher than it can contain, i starts fron scratch, in case of
an unsigned 0

 

[Daniel T.]

Daniel T. skrev:

@code start
#include <iostream>

union Buffer {
char c[sizeof(unsigned long)];
unsigned long i;
};

int main() {
Buffer buf;
buf.i = 0x92345678;
for (int x = sizeof(buf)-1; x >= 0; x--)
std::cout << std::hex << static_cast<unsigned long>(buf.c[x]) <<
", ";
std::cin.get();
}
@code end
first, i have changed the value of buf.i, important to nitice, because
the code works fine with ox123456780.
Then i have changed some minor thing so that the numbers is printed the
the right order.

That is where subject 'endian' comes in. On my machine, my program
printed the numbers out in the correct order, on your machine you had to
reverse the bytes to get it to print correctly.
<http://www.rdrop.com/~cary/html/endian_faq.html>

i still dont get the endian stuff, it can reverse the bits yes, but so
can what i have done.

It's not something you have to worry about, unless you expect to be able
to send your file to others and have them read in the data. If their
computer has a different endian, then special arrangements must be made.

Yes i did look at the file and i didnt see a single number, however i
saw like a billion of endl squares ;-) i could live without them.
bout the space, the file take up half or less of the space it did
before and i have had the program running for a day and a half now.

There must be a difference in our implementations then, I'm not sure
what the standard behavior is supposed to be...

 

[felixnielsen]

Daniel T. skrev:

Daniel T. skrev:

@code start
#include <iostream>

union Buffer {
char c[sizeof(unsigned long)];
unsigned long i;
};

int main() {
Buffer buf;
buf.i = 0x92345678;
for (int x = sizeof(buf)-1; x >= 0; x--)
std::cout << std::hex << static_cast<unsigned long>(buf.c[x]) <<
", ";
std::cin.get();
}
@code end
first, i have changed the value of buf.i, important to nitice, because
the code works fine with ox123456780.
Then i have changed some minor thing so that the numbers is printed the
the right order.

That is where subject 'endian' comes in. On my machine, my program
printed the numbers out in the correct order, on your machine you had to
reverse the bytes to get it to print correctly.
<http://www.rdrop.com/~cary/html/endian_faq.html>

i still dont get the endian stuff, it can reverse the bits yes, but so
can what i have done.

It's not something you have to worry about, unless you expect to be able
to send your file to others and have them read in the data. If their
computer has a different endian, then special arrangements must be made.

Excactly my thought ;-)

There must be a difference in our implementations then, I'm not sure
what the standard behavior is supposed to be...

I must admit im in doubt if what i wrote is correct.
I know i did look at the file, and i didnt see a single number, but
alot of squares.
when i use "type" in cmd to look at the file though, it just shows the
numbers.
About size though...
I now having a file with the size ~ 6 GB, that is alot
Maybe i was wrong on that point.

 

[Daniel T.]

Daniel T. skrev:


I must admit im in doubt if what i wrote is correct.
I know i did look at the file, and i didnt see a single number, but
alot of squares.
when i use "type" in cmd to look at the file though, it just shows the
numbers.
About size though...
I now having a file with the size ~ 6 GB, that is alot
Maybe i was wrong on that point.

Check out the file with a hex dump program...

 

[felixnielsen]

Daniel T. skrev:

Check out the file with a hex dump program...

Can you recoment any?

 

[Daniel T.]

Daniel T. skrev:


Can you recoment any?

Not for your platform.