Help with typedef

[felixnielsen]

What i really wanna do, is defining my own types, it doesnt really
matter why.
Anyway, i have run into some problems

1)
typedef unsigned short U16;
U16 test = 0xffffffff; // There should be a limit on this, max value
you should be able to asign should be 0xffff //
std::cout << test; // result = 0xffff //

This is not a problem without at solution, however i am no certain of
where the solution lies.

2)
typedef unsigned:8 U8; // This doesnt work, i would like it to. Can it
be done? //

Maybe typedef isnt the way to go, but what is the alternatives?

Thanks in advance.

Zacariaz

[Ben Pope]

fe**********@hotmail.com wrote:

What i really wanna do, is defining my own types, it doesnt really
matter why.
Anyway, i have run into some problems

1)
typedef unsigned short U16;
That doesn't define a new type, it aliases an existing type.
U16 test = 0xffffffff; // There should be a limit on this, max value
you should be able to asign should be 0xffff //
std::cout << test; // result = 0xffff //
So what, you would like a compile time diagnostic? Something at run
time? An editor that prevents you from typing more 'f's?

It's also platform / compiler dependant - an unsigned short does not
have to be 16bits.
This is not a problem without at solution, however i am no certain of
where the solution lies.
Well, I'm not sure what the problem is.
2)
typedef unsigned:8 U8; // This doesnt work, i would like it to. Can it
be done? //
Not with that syntax.
Maybe typedef isnt the way to go, but what is the alternatives?

You could use your own type (a struct or class), but I'm not sure what
problem you're trying to solve.

I *think* you want integer types that are of a given size (in bits).
There is no standard way of doing it in C++.

Take a look at boost:
http://www.boost.org/libs/integer/integer.htm
specifically, the header:
http://www.boost.org/boost/cstdint.hpp

And also at the C99 header, "stdint.h", which may also be found as
<cstdint> with your library. (or may not).

Neither of these are C++ standard, but something approximating either
are very likely to be, in the future.

Ben Pope
--
I'm not just a number. To many, I'm known as a string...

[Victor Bazarov]

fe**********@hotmail.com wrote:

What i really wanna do, is defining my own types, it doesnt really
matter why.
Anyway, i have run into some problems

1)
typedef unsigned short U16;
U16 test = 0xffffffff; // There should be a limit on this, max value
you should be able to asign should be 0xffff //
std::cout << test; // result = 0xffff //

This is not a problem without at solution, however i am no certain of
where the solution lies.
There is none. The truncation is done by the compiler at the time of
initialisation. You're explicitly allowed to initialise an unsigned short
with an expression that produces an unsigned int or unsigned long.
2)
typedef unsigned:8 U8; // This doesnt work, i would like it to. Can it
be done? //

Maybe typedef isnt the way to go, but what is the alternatives?

If your system has eight-bit bytes, you should be able to say

typedef unsigned char U8;

But if it doesn't, there is no way. A minimal addressable element of
your computer memory is a byte ('char'), and you cannot declare an object
of any size smaller than that stand-alone.

V
--
Please remove capital As from my address when replying by mail

[felixnielsen]

Ben Pope skrev:

fe**********@hotmail.com wrote:

What i really wanna do, is defining my own types, it doesnt really
matter why.
Anyway, i have run into some problems

1)
typedef unsigned short U16;

That doesn't define a new type, it aliases an existing type.

U16 test = 0xffffffff; // There should be a limit on this, max value
you should be able to asign should be 0xffff //
std::cout << test; // result = 0xffff //

So what, you would like a compile time diagnostic? Something at run
time? An editor that prevents you from typing more 'f's?

It's also platform / compiler dependant - an unsigned short does not
have to be 16bits.

This is not a problem without at solution, however i am no certain of
where the solution lies.

Well, I'm not sure what the problem is.

2)
typedef unsigned:8 U8; // This doesnt work, i would like it to. Can it
be done? //

Not with that syntax.

Maybe typedef isnt the way to go, but what is the alternatives?

You could use your own type (a struct or class), but I'm not sure what
problem you're trying to solve.

I *think* you want integer types that are of a given size (in bits).
There is no standard way of doing it in C++.

Take a look at boost:
http://www.boost.org/libs/integer/integer.htm
specifically, the header:
http://www.boost.org/boost/cstdint.hpp

And also at the C99 header, "stdint.h", which may also be found as
<cstdint> with your library. (or may not).

Neither of these are C++ standard, but something approximating either
are very likely to be, in the future.

Ben Pope
--
I'm not just a number. To many, I'm known as a string...

To say it as simple as posible.

I need four type:

unsigned char
unsigned short
unsigned long
unsigned long long

First of all i would like to redefine their names as to how many bit
they occupy and wether they are signed or not:

unsigned char - U8
unsigned short - U16
unsigned long - U32
unsigned long long - U64

signed char - S8
signed short - S16
signed long - S32
signed long long - S64

or something like it.

Second, the unsigned char i really enoying.
Yes its true, you dont have to store a letter in a char, but if you
store numbers, every time you need to pull out the number again.
std::cout << static_cast<int>(char_var);
is the way to do it, if im not mistaken.

As i said, it is a problem with a solution, but i dont much like the
solution.

[felixnielsen]

Victor Bazarov skrev:

fe**********@hotmail.com wrote:

What i really wanna do, is defining my own types, it doesnt really
matter why.
Anyway, i have run into some problems

1)
typedef unsigned short U16;
U16 test = 0xffffffff; // There should be a limit on this, max value
you should be able to asign should be 0xffff //
std::cout << test; // result = 0xffff //

This is not a problem without at solution, however i am no certain of
where the solution lies.

There is none. The truncation is done by the compiler at the time of
initialisation. You're explicitly allowed to initialise an unsigned short
with an expression that produces an unsigned int or unsigned long.

2)
typedef unsigned:8 U8; // This doesnt work, i would like it to. Can it
be done? //

Maybe typedef isnt the way to go, but what is the alternatives?

If your system has eight-bit bytes, you should be able to say

typedef unsigned char U8;

But if it doesn't, there is no way. A minimal addressable element of
your computer memory is a byte ('char'), and you cannot declare an object
of any size smaller than that stand-alone.

V
--
Please remove capital As from my address when replying by mail

As writen in the answer to ben hope, the char type, is enoying as hell
(excuse me my big mouth)
std::cout << static_cast<int>(char_var);
Would be the correct way to pull a value from a char type, this is
enoying and i would rather i didnt have to do it that way.

[Victor Bazarov]

fe**********@hotmail.com wrote:

[...]
To say it as simple as posible.

I need four type:

unsigned char
unsigned short
unsigned long
unsigned long long
No such type in C++. As much as you may need it, it simply isn't there.
First of all i would like to redefine their names as to how many bit
they occupy and wether they are signed or not:

unsigned char - U8
unsigned short - U16
unsigned long - U32
unsigned long long - U64

signed char - S8
signed short - S16
signed long - S32
signed long long - S64

or something like it.

Second, the unsigned char i really enoying.
Uh... I don't understand that statement.
Yes its true, you dont have to store a letter in a char, but if you
store numbers, every time you need to pull out the number again.
std::cout << static_cast<int>(char_var);
is the way to do it, if im not mistaken.
But you are mistaken. Just use that value in an expression. You seem to
be solving a wrong problem.
As i said, it is a problem with a solution, but i dont much like the
solution.

Again, I don't understand. What exactly don't you like about what
solution?

V
--
Please remove capital As from my address when replying by mail

[Victor Bazarov]

fe**********@hotmail.com wrote:

[..]
As writen in the answer to ben hope
"Ben Pope", actually.
, the char type, is enoying as hell
(excuse me my big mouth)
std::cout << static_cast<int>(char_var);
Would be the correct way to pull a value from a char type, this is
enoying and i would rather i didnt have to do it that way.

First of all, to "pull a value", you don't need to print it. Just use
a variable of that type in an expression. Yes, if you want to _print_
it, you need to use the right conversion, and outputting a char (whether
signed or unsigned) is a special action in C++, and you need to cast, as
you do. What's the big deal?

V
--
Please remove capital As from my address when replying by mail

[TB]

fe**********@hotmail.com sade:

Victor Bazarov skrev:

fe**********@hotmail.com wrote:

What i really wanna do, is defining my own types, it doesnt really
matter why.
Anyway, i have run into some problems

1)
typedef unsigned short U16;
U16 test = 0xffffffff; // There should be a limit on this, max value
you should be able to asign should be 0xffff //
std::cout << test; // result = 0xffff //

This is not a problem without at solution, however i am no certain of
where the solution lies.

There is none. The truncation is done by the compiler at the time of
initialisation. You're explicitly allowed to initialise an unsigned short
with an expression that produces an unsigned int or unsigned long.

2)
typedef unsigned:8 U8; // This doesnt work, i would like it to. Can it
be done? //

Maybe typedef isnt the way to go, but what is the alternatives?

If your system has eight-bit bytes, you should be able to say

typedef unsigned char U8;

But if it doesn't, there is no way. A minimal addressable element of
your computer memory is a byte ('char'), and you cannot declare an object
of any size smaller than that stand-alone.

V
--
Please remove capital As from my address when replying by mail

As writen in the answer to ben hope, the char type, is enoying as hell
(excuse me my big mouth)
std::cout << static_cast<int>(char_var);
Would be the correct way to pull a value from a char type, this is
enoying and i would rather i didnt have to do it that way.

std::cout << int(char_var);

--
TB @ SWEDEN

[Daniel T.]

In article <11**********************@g47g2000cwa.googlegroups .com>,
fe**********@hotmail.com wrote:

What i really wanna do, is defining my own types, it doesnt really
matter why.
Anyway, i have run into some problems

1)
typedef unsigned short U16;
U16 test = 0xffffffff; // There should be a limit on this, max value
you should be able to asign should be 0xffff //
std::cout << test; // result = 0xffff //

This is not a problem without at solution, however i am no certain of
where the solution lies.

2)
typedef unsigned:8 U8; // This doesnt work, i would like it to. Can it
be done? //

Maybe typedef isnt the way to go, but what is the alternatives?

Thanks in advance.

Zacariaz

Run this:

int main()
{
cout << "sizeof( unsigned char ) == "
<< sizeof( unsigned char ) << '\n';
cout << "sizeof( unsigned short ) == "
<< sizeof( unsigned short ) << '\n';
cout << "sizeof( unsigned int ) == "
<< sizeof( unsigned int ) << '\n';
cout << "sizeof( unsigned long ) == "
<< sizeof( unsigned long ) << '\n';
}

The one who's sizeof is 1 can hold 0xff, sizeof 2 can hold 0xffff,
sizeof 4 can hold 0xffffffff and so on...
--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.

[felixnielsen]

Well, i didnt quite get the answer i was looking for, however i realize
now that the problem maybe isnt at great as i thought.
Thank you all a bunch.

Regards

[Victor Bazarov]

Daniel T. wrote:

[..]
Run this:

int main()
{
cout << "sizeof( unsigned char ) == "
<< sizeof( unsigned char ) << '\n';
'sizeof(unsigned char)' is _always_ 1.
cout << "sizeof( unsigned short ) == "
<< sizeof( unsigned short ) << '\n';
cout << "sizeof( unsigned int ) == "
<< sizeof( unsigned int ) << '\n';
cout << "sizeof( unsigned long ) == "
<< sizeof( unsigned long ) << '\n';
}

The one who's sizeof is 1 can hold 0xff, sizeof 2 can hold 0xffff,
sizeof 4 can hold 0xffffffff and so on...

This is misleading. Did you mean to imply that 'sizeof' somehow gives
the number of bits in the type/object? That's not true by itself. The
'sizeof' operator is only useful in determining the number of bits in
the object/type _iff_ it's combined with CHAR_BIT value (multiplied by
it, anyway):

cout << "number of bits in an unsigned char is " << CHAR_BIT << endl;
cout << "number of bits in an unsigned short is " <<
sizeof(unsigned short)*CHAR_BIT << endl;

and so on.

V
--
Please remove capital As from my address when replying by mail

[Ben Pope]

fe**********@hotmail.com wrote:

Ben Pope skrev:

<snip>

Well, I'm not sure what the problem is.

<snip>

I *think* you want integer types that are of a given size (in bits).
There is no standard way of doing it in C++.

Take a look at boost:
http://www.boost.org/libs/integer/integer.htm
specifically, the header:
http://www.boost.org/boost/cstdint.hpp

And also at the C99 header, "stdint.h", which may also be found as
<cstdint> with your library. (or may not).
To say it as simple as posible.

I need four type:

unsigned char
unsigned short
unsigned long
unsigned long long

First of all i would like to redefine their names as to how many bit
they occupy and wether they are signed or not:

unsigned char - U8
unsigned short - U16
unsigned long - U32
unsigned long long - U64

OK, this is platform and compiler dependant. Your platform might not
even have an 8 bit char.

long long doesn't exist in C++. It's is compiler dependant.
signed char - S8
signed short - S16
signed long - S32
signed long long - S64
Similarly as above.
or something like it.
Did you look at the <cstdint> header I pointed you too? This provides
the functionality you are looking for in the most platform independent way.
Second, the unsigned char i really enoying.
Yes its true, you dont have to store a letter in a char, but if you
store numbers, every time you need to pull out the number again.
std::cout << static_cast<int>(char_var);
is the way to do it, if im not mistaken.
I'm not sure what you mean by "pull out", but if you want to format it
as a number, not a character, you need to make it a number. It's not
called a "char" for no reason; the usual type to put in it is a
character. The << operator is for formatting, hence, it is formatted as
a character.
As i said, it is a problem with a solution, but i dont much like the
solution.

I don't know of any suitable alternative. You may not like it, but it
is explicit as to what you want to achieve, and is also simple.
#include <iostream>

// these two functions are explicit, but not sure what
// they gain you in real terms, make maintenance harder
unsigned int as_integer(unsigned char c) {
return static_cast<unsigned int>(c);
}

signed int as_integer(signed char c) {
return static_cast<signed int>(c);
}

// this class is just obscure, don't see the point, really.
class my_U8 {
public:
my_U8() : c_(0) {}
my_U8(unsigned char c) : c_(c) {}
// this should be chosen in most cases
operator unsigned char&() { return c_; }
// this one seems to be chosen for the stream (dunno why)
operator unsigned int() { return static_cast<unsigned int>(c_); }
private:
unsigned char c_;
};
int main() {
unsigned char c = 'A';
std::cout << "uchar: " << c
<< "\nuint: " << as_integer(c) << std::endl;

my_U8 u = 'B';
std::cout << "my_U8: " << u << std::endl;

u += 3;

std::cout << "my_U8: " << u << std::endl;
}

Not recommended though, just use the static cast to make it explicit.

Ben Pope
--
I'm not just a number. To many, I'm known as a string...

[felixnielsen]

Wether this is smart or not i found a "solution"

typedef struct {
unsigned a:8;
} uint8;
uint8 test;
test.a = 7;
std::cout << test.a;

Now i just need to know how to get rit of the'a', because i dont really
need it.

[Victor Bazarov]

fe**********@hotmail.com wrote:

Wether this is smart or not i found a "solution"

typedef struct {
unsigned a:8;
} uint8;
uint8 test;
test.a = 7;
std::cout << test.a;

Now i just need to know how to get rit of the'a', because i dont really
need it.

Why do you think it's a solution? What was the problem you were trying
to solve?

struct uint8 {
unsigned a:8;
uint8& operator =(unsigned u) { a = u & 0xff; return *this; }
operator int() const { return a; }
};

#include <iostream>
int main() {
uint8 test;
test = 7;
std::cout << test << " occupies " << sizeof(test) << " bytes\n";
}

Now, run it and see if you "solved" anything.

V
--
Please remove capital As from my address when replying by mail

[Bo Persson]

<fe**********@hotmail.com> skrev i meddelandet
news:11**********************@f14g2000cwb.googlegr oups.com...

Wether this is smart or not i found a "solution"

typedef struct {
unsigned a:8;
} uint8;
uint8 test;
test.a = 7;
std::cout << test.a;

Now i just need to know how to get rit of the'a', because i dont
really
need it.

This isn't really a solution, as the struct will be the size of an
unsigned int, even if you only use 8 bits of it.
Bo Persson

[Rolf Magnus]

fe**********@hotmail.com wrote:

As writen in the answer to ben hope, the char type, is enoying as hell
(excuse me my big mouth)
std::cout << static_cast<int>(char_var);
Would be the correct way to pull a value from a char type, this is
enoying and i would rather i didnt have to do it that way.

This has nothing to do with "pulling out" a value. char is just an integer
type like the others. What you are talking about is a property of the
ostream class, which has an operator<< that interprets char values as
characters. If that was done different, how would you print a single
character?

[felixnielsen]

Never mind, so long and thanks for all the fish...

[Default User]

fe**********@hotmail.com wrote:

What i really wanna do, is defining my own types, it doesnt really
matter why.

Actually, it probably DOES matter why. As the others have explained,
much of what you want to do isn't possible or isn't easy. It would be
better to tell us what problem you are trying to solve. There may be
other solutions besides fixed-width data types.


Brian

[felixnielsen]

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.
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.
I would indeed be wery thankfull if anyone could help me with that,
otherwise i consider this subject closed.

Once again thank you all for your time.

[Rolf Magnus]

fe**********@hotmail.com wrote:

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,
An unsigned int might not be enough then, because depending on the compiler,
it can be as small as 16 bits.
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.
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.
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.
I fail to see what that has to do with your typedef question.
I would indeed be wery thankfull if anyone could help me with that,
otherwise i consider this subject closed.

Once again thank you all for your time.

[Daniel T.]

In article <11**********************@f14g2000cwb.googlegroups .com>,
fe**********@hotmail.com wrote:

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.
--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.

[felixnielsen]

Rolf Magnus skrev:

fe**********@hotmail.com wrote:

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,
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.

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.

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.

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.
I fail to see what that has to do with your typedef question.

explained above.

I would indeed be wery thankfull if anyone could help me with that,
otherwise i consider this subject closed.

Once again thank you all for your time.

[felixnielsen]

Daniel T. skrev:

In article <11**********************@f14g2000cwb.googlegroups .com>,
fe**********@hotmail.com wrote:

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();
}

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.

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.

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


--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.

[Daniel T.]

In article <11*********************@z14g2000cwz.googlegroups. com>,
fe**********@hotmail.com wrote:

Daniel T. skrev:

In article <11**********************@f14g2000cwb.googlegroups .com>,
fe**********@hotmail.com wrote:

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();
}

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."

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?

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>
--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.

[felixnielsen]

Daniel T. skrev:

In article <11*********************@z14g2000cwz.googlegroups. com>,
fe**********@hotmail.com wrote:

Daniel T. skrev:

In article <11**********************@f14g2000cwb.googlegroups .com>,
fe**********@hotmail.com wrote:

> 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();
}

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 cant help wondering, why not just use deques instead of vectors all
the time?

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?

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::ofstream primes("primes.txt", // Opening file 'primes.txt'
for writing
std::ios::out| //
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::ofstream primes("primes.txt",std::ios::out|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[i] <= root && is_prime == true; i++)
if (test % P[i] == 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.

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>

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.


--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.

[Daniel T.]

In article <11*********************@g44g2000cwa.googlegroups. com>,
fe**********@hotmail.com wrote:

Daniel T. skrev:

In article <11*********************@z14g2000cwz.googlegroups. com>,
fe**********@hotmail.com wrote:

Daniel T. skrev:

> In article <11**********************@f14g2000cwb.googlegroups .com>,
> fe**********@hotmail.com wrote:
>
> > 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();
> }
>

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 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.)

> 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?

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.

[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...
--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.

[TB]

fe**********@hotmail.com sade:

Daniel T. skrev:

In article <11*********************@z14g2000cwz.googlegroups. com>,
fe**********@hotmail.com wrote:

Daniel T. skrev:

In article <11**********************@f14g2000cwb.googlegroups .com>,
fe**********@hotmail.com wrote:

> 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();
}

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 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.

--
TB @ SWEDEN

[felixnielsen]

> > > > > 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?

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.

[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 O_o havent even got to understand classes yet... ;(

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.

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.

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".)

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.]

In article <11**********************@o13g2000cwo.googlegroups .com>,
fe**********@hotmail.com wrote:

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 O_o 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...

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.

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]) << ", ";
}

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".)

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.
--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.

[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::ofstream primes("primes.txt",
std::ios::out|
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::ofstream primes("primes.txt",
std::ios::out|
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[i] <= root && is_prime == true; i++)
if (test % P[i] == 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.]

In article <11*********************@g47g2000cwa.googlegroups. com>,
fe**********@hotmail.com wrote:

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>
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.

--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.

[felixnielsen]

Daniel T. skrev:

In article <11*********************@g47g2000cwa.googlegroups. com>,
fe**********@hotmail.com wrote:

> 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>

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

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.

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.

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.

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.]

In article <11**********************@f14g2000cwb.googlegroups .com>,
fe**********@hotmail.com wrote:

Daniel T. skrev:

In article <11*********************@g47g2000cwa.googlegroups. com>,
fe**********@hotmail.com wrote:

@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.

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.

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...

--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.

[felixnielsen]

Daniel T. skrev:

In article <11**********************@f14g2000cwb.googlegroups .com>,
fe**********@hotmail.com wrote:

Daniel T. skrev:

In article <11*********************@g47g2000cwa.googlegroups. com>,
fe**********@hotmail.com wrote:

> @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 ;-)

> 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.

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...

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 O_o
Maybe i was wrong on that point.

[Daniel T.]

In article <11**********************@g43g2000cwa.googlegroups .com>,
fe**********@hotmail.com wrote:

Daniel T. skrev:

In article <11**********************@f14g2000cwb.googlegroups .com>,
fe**********@hotmail.com wrote:

Daniel T. skrev:

>
> 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.

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 O_o
Maybe i was wrong on that point.

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

--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.

[felixnielsen]

Daniel T. skrev:

In article <11**********************@g43g2000cwa.googlegroups .com>,
fe**********@hotmail.com wrote:

Daniel T. skrev:

In article <11**********************@f14g2000cwb.googlegroups .com>,
fe**********@hotmail.com wrote:

> Daniel T. skrev:
>
> >
> > 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.

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 O_o
Maybe i was wrong on that point.

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

Can you recoment any?
--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.

[Daniel T.]

In article <11*********************@g47g2000cwa.googlegroups. com>,
fe**********@hotmail.com wrote:

Daniel T. skrev:

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

Can you recoment any?

Not for your platform.

--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.