So far the only way that I found to do this was by making a
single global instance of the container class and providing
access to the contained class, through this single global
instance. Are there any other no-overhead ways that a
contained class can access its container?
The obvious choice of passing (a pointer or a reference to
the container) to the contained class is not a no-overhead
solution, it requires both memory and time. I am hoping that
there might be some obscure C++ syntax that provides the
capability that I am seeking, without the need to resort to
the single global instance of the container to provide
access.
36  1987 
Peter Olcott wrote:
So far the only way that I found to do this was by making a
single global instance of the container class and providing
access to the contained class, through this single global
instance. Are there any other no-overhead ways that a
contained class can access its container?
The obvious choice of passing (a pointer or a reference to
the container) to the contained class is not a no-overhead
solution, it requires both memory and time. I am hoping that
there might be some obscure C++ syntax that provides the
capability that I am seeking, without the need to resort to
the single global instance of the container to provide
access.
It sounds like you may be asking the wrong thing. For one thing, you're
creating a tight-coupling between the contained and the container. This
prevents your contained objects from being in two separate containers at
the same time.
The other possible problem is the "no-overhead" requirement. Don't
optimize prematurely. Only worry about overhead when you find that
you're running out of memory, or that you're algorithm takes too long to
run. And then, use a profiler to determine exactly *where* your code
needs optimization.
I know its not the answer you're looking for, but I hope it helps you
non-the-less.
Good luck,
Daniel.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
"Daniel Pitts" <ne******************@virtualinfinity.net>
wrote in message
news:48***********************@newsrazor.net...
Peter Olcott wrote:
>So far the only way that I found to do this was by making
a single global instance of the container class and
providing access to the contained class, through this
single global instance. Are there any other no-overhead
ways that a contained class can access its container?
The obvious choice of passing (a pointer or a reference
to the container) to the contained class is not a
no-overhead solution, it requires both memory and time. I
am hoping that there might be some obscure C++ syntax
that provides the capability that I am seeking, without
the need to resort to the single global instance of the
container to provide access.
It sounds like you may be asking the wrong thing. For one
thing, you're creating a tight-coupling between the
contained and the container. This prevents your contained
objects from being in two separate containers at the same
time.
The other possible problem is the "no-overhead"
requirement. Don't optimize prematurely. Only worry
about overhead when you find that you're running out of
memory, or that you're algorithm takes too long to run.
And then, use a profiler to determine exactly *where* your
code needs optimization.
I know its not the answer you're looking for, but I hope
it helps you non-the-less.
Good luck,
Daniel.
I already have a solution that meets all of my criteria,
what I am looking for is a cleaner solution. Either such a
solution exists, or it does not exist. If it does not exist,
then no further discussion is required, and my somewhat
clumsy solution will have to suffice.
The no-overhead requirement is a binding constraint that can
not be avoided. Adding any space or time overhead makes the
project infeasible. This project provides a solution where
alternative solutions do not exist, and this aspect of the
design provides the core functionality of the system.
--
Daniel Pitts' Tech Blog:
<http://virtualinfinity.net/wordpress/>
Peter Olcott ha scritto:
So far the only way that I found to do this was by making a
single global instance of the container class and providing
access to the contained class, through this single global
instance. Are there any other no-overhead ways that a
contained class can access its container?
You should think whether a solution is possible in any other programming
language, machine language included.
If it is not possible in machine language, of course it is possible
neither in C++.
The only solution I can think of is applicable only if your collections
occupy distinct memory pools. For example, if your collections are
arrays, you could check if the address of your object is between the
begin address and the end address of that array.
But that has a overhead though. To find the right array you have to loop
over all the arrays or something like that.
--
Carlo Milanesi http://digilander.libero.it/carlmila
"Carlo Milanesi" <ca********************@libero.itwrote in
message news:48**********************@news.tiscali.it...
Peter Olcott ha scritto:
>So far the only way that I found to do this was by making
a single global instance of the container class and
providing access to the contained class, through this
single global instance. Are there any other no-overhead
ways that a contained class can access its container?
You should think whether a solution is possible in any
other programming language, machine language included.
If it is not possible in machine language, of course it is
possible neither in C++.
I can do it in C++, but, the solution is clumsy. I am
looking for a less clumsy C++ solution, if one exists.
>
The only solution I can think of is applicable only if
your collections occupy distinct memory pools. For
example, if your collections are arrays, you could check
if the address of your object is between the begin address
and the end address of that array.
But that has a overhead though. To find the right array
you have to loop over all the arrays or something like
that.
--
Carlo Milanesi
http://digilander.libero.it/carlmila
I have a solution that allows the existence of multiple
instances of the container class, the number of such
instances can be specified at run-time. These multiple
instances would be stored in a single global
std::vector<ContainerClass>. Another single instance global
integer would be used as the current subscript into this
std::vector<ContainerClass>, specifying which ContainerClass
is being used. There would be no extra overhead in the use
of either the ContainerClass, nor its ContainedClass.
In article <ku*****************@newsfe11.phx>, No****@SeeScreen.com
says...
>
"Alf P. Steinbach" <al***@start.nowrote in message
[ ... ]
Hm, that sounds like much bullshit and zero information,
iow., trolling.
www.SeeScreen.com
This technology can be applied to the automated testing of
video games. Video games are currently a $37 Billion annual
market, and all testing is done manually by human testers.
This looks like it retains the same level of information (i.e. none) and
adds only distraction. The question is exactly why you require zero
overhead for this particular aspect of a program. The annual revenues of
video games has nothing whatsoever to do with the question at hand.
--
Later,
Jerry.
The universe is a figment of its own imagination.
"Jerry Coffin" <jc*****@taeus.comwrote in message
news:MP************************@news.sunsite.dk...
In article <ku*****************@newsfe11.phx>,
No****@SeeScreen.com
says...
>>
"Alf P. Steinbach" <al***@start.nowrote in message
[ ... ]
Hm, that sounds like much bullshit and zero
information,
iow., trolling.
www.SeeScreen.com
This technology can be applied to the automated testing
of
video games. Video games are currently a $37 Billion
annual
market, and all testing is done manually by human
testers.
This looks like it retains the same level of information
(i.e. none) and
adds only distraction. The question is exactly why you
require zero
overhead for this particular aspect of a program. The
annual revenues of
video games has nothing whatsoever to do with the question
at hand.
I was directly addressing your last remark, which itself
avoided rather than addressed the issue at hand. You really
don't need to know these details to answer my question. The
question is how can a contained class access its container
without adding any overhead? It seems like you are saying
(in a very convoluted way) that you simply don't know. Good
enough, no need for further discussion.
>
--
Later,
Jerry.
The universe is a figment of its own imagination.
YES, I agree!
Peter Olcott wrote:
"Carlo Milanesi" <ca********************@libero.itwrote in
message news:48**********************@news.tiscali.it...
>Peter Olcott ha scritto:
>>So far the only way that I found to do this was by making
a single global instance of the container class and
providing access to the contained class, through this
single global instance. Are there any other no-overhead
ways that a contained class can access its container?
You should think whether a solution is possible in any
other programming language, machine language included.
If it is not possible in machine language, of course it is
possible neither in C++.
I can do it in C++, but, the solution is clumsy. I am
looking for a less clumsy C++ solution, if one exists.
>The only solution I can think of is applicable only if
your collections occupy distinct memory pools. For
example, if your collections are arrays, you could check
if the address of your object is between the begin address
and the end address of that array.
But that has a overhead though. To find the right array
you have to loop over all the arrays or something like
that.
--
Carlo Milanesi
http://digilander.libero.it/carlmila
I have a solution that allows the existence of multiple
instances of the container class, the number of such
instances can be specified at run-time. These multiple
instances would be stored in a single global
std::vector<ContainerClass>. Another single instance global
integer would be used as the current subscript into this
std::vector<ContainerClass>, specifying which ContainerClass
is being used. There would be no extra overhead in the use
of either the ContainerClass, nor its ContainedClass.
I'm not sure, but Boosts intrusive containers give you what you're
looking for, and then some.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
Daniel Pitts wrote:
Peter Olcott wrote:
>"Carlo Milanesi" <ca********************@libero.itwrote in message
news:48**********************@news.tiscali.it.. .
>>Peter Olcott ha scritto:
So far the only way that I found to do this was by making a single
global instance of the container class and providing access to the
contained class, through this single global instance. Are there any
other no-overhead ways that a contained class can access its container?
You should think whether a solution is possible in any other
programming language, machine language included.
If it is not possible in machine language, of course it is possible
neither in C++.
I can do it in C++, but, the solution is clumsy. I am looking for a
less clumsy C++ solution, if one exists.
>>The only solution I can think of is applicable only if your
collections occupy distinct memory pools. For example, if your
collections are arrays, you could check if the address of your object
is between the begin address and the end address of that array.
But that has a overhead though. To find the right array you have to
loop over all the arrays or something like that.
--
Carlo Milanesi
http://digilander.libero.it/carlmila
I have a solution that allows the existence of multiple instances of
the container class, the number of such instances can be specified at
run-time. These multiple instances would be stored in a single global
std::vector<ContainerClass>. Another single instance global integer
would be used as the current subscript into this
std::vector<ContainerClass>, specifying which ContainerClass is being
used. There would be no extra overhead in the use of either the
ContainerClass, nor its ContainedClass.
I'm not sure, but Boosts intrusive containers give you what you're
looking for, and then some.
I meant "may" give you what you're looking for.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
In article <2X*****************@newsfe11.phx>, No****@SeeScreen.com
says...
>
"Jerry Coffin" <jc*****@taeus.comwrote in message
news:MP************************@news.sunsite.dk...
In article <ku*****************@newsfe11.phx>,
No****@SeeScreen.com
says...
>
"Alf P. Steinbach" <al***@start.nowrote in message
[ ... ]
Hm, that sounds like much bullshit and zero
information,
iow., trolling.
www.SeeScreen.com
This technology can be applied to the automated testing
of
video games. Video games are currently a $37 Billion
annual
market, and all testing is done manually by human
testers.
This looks like it retains the same level of information
(i.e. none) and
adds only distraction. The question is exactly why you
require zero
overhead for this particular aspect of a program. The
annual revenues of
video games has nothing whatsoever to do with the question
at hand.
I was directly addressing your last remark, which itself
avoided rather than addressed the issue at hand.
This was the first post I'd made to this thread, so none of your remarks
shows any sign of addressing anything I'd said previously.
You really
don't need to know these details to answer my question. The
question is how can a contained class access its container
without adding any overhead? It seems like you are saying
(in a very convoluted way) that you simply don't know. Good
enough, no need for further discussion.
I'm not saying I do or don't know -- I simply pointed out a serious
problem with your post. Unfortunately, I don't have a direct answer to
your question, largely because I don't think your question is entirely
clear -- in particular, while you say absolutely no overhead is allowed,
you don't say whether it's purely time overhead, space overhead, or both
that must be eliminated to qualify.
My guess is that there is no real answer -- if there is a possibility of
more than one collection to which an object might belong, _something_
must record which for the program to know -- and no matter how careful
one is to minimize that, it must still exist. Likewise if/when (for one
example) an object is moved from one collection to another, that
something must be updated to match -- and, again, no matter how
carefully that update time is optimized, it can never be reduced to
zero.
--
Later,
Jerry.
The universe is a figment of its own imagination.
On Jun 15, 10:35 am, "Peter Olcott" <NoS...@SeeScreen.comwrote:
"Carlo Milanesi" <carlo.milanesi.no.s...@libero.itwrote in
messagenews:48**********************@news.tiscali. it...
Peter Olcott ha scritto:
So far the only way that I found to do this was by making
a single global instance of the container class and
providing access to the contained class, through this
single global instance. Are there any other no-overhead
ways that a contained class can access its container?
You should think whether a solution is possible in any
other programming language, machine language included.
If it is not possible in machine language, of course it is
possible neither in C++.
I can do it in C++, but, the solution is clumsy. I am
looking for a less clumsy C++ solution, if one exists.
The only solution I can think of is applicable only if
your collections occupy distinct memory pools. For
example, if your collections are arrays, you could check
if the address of your object is between the begin address
and the end address of that array.
But that has a overhead though. To find the right array
you have to loop over all the arrays or something like
that.
--
Carlo Milanesi
http://digilander.libero.it/carlmila
I have a solution
That is not a solution to the question you have in the subject line.
You are asking whether the contained class can have access to the
container without any overhead. No, it cannot.
Then you're providing a solution where a particular class has access
to particular instances of containers.
The fact that you *limit* the access to a certain class doesn't make
that a solution of "some class accessing its container." What you have
is a solution where everybody can access globals. That has been there
for decades.
that allows the existence of multiple
instances of the container class, the number of such
instances can be specified at run-time. These multiple
instances would be stored in a single global
std::vector<ContainerClass>.
And that's no memory overhead?
Another single instance global
integer would be used as the current subscript into this
std::vector<ContainerClass>,
How about that one? That is both a memory overhead and a time
overhead, because you need to manage it in non-zero time.
specifying which ContainerClass
is being used. There would be no extra overhead in the use
of either the ContainerClass, nor its ContainedClass.
When an object "uses" the container, it does it so because some time
has been spent to set the global(s) properly. That is overhead.
You may have something else in mind but you are not asking that.
Ali
<ac******@gmail.comwrote in message
news:f0**********************************@m3g2000h sc.googlegroups.com...
On Jun 15, 10:35 am, "Peter Olcott" <NoS...@SeeScreen.com>
wrote:
>"Carlo Milanesi" <carlo.milanesi.no.s...@libero.itwrote
in
messagenews:48**********************@news.tiscali .it...
Peter Olcott ha scritto:
So far the only way that I found to do this was by
making
a single global instance of the container class and
providing access to the contained class, through this
single global instance. Are there any other
no-overhead
ways that a contained class can access its container?
You should think whether a solution is possible in any
other programming language, machine language included.
If it is not possible in machine language, of course it
is
possible neither in C++.
I can do it in C++, but, the solution is clumsy. I am
looking for a less clumsy C++ solution, if one exists.
The only solution I can think of is applicable only if
your collections occupy distinct memory pools. For
example, if your collections are arrays, you could
check
if the address of your object is between the begin
address
and the end address of that array.
But that has a overhead though. To find the right array
you have to loop over all the arrays or something like
that.
--
Carlo Milanesi
http://digilander.libero.it/carlmila
I have a solution
That is not a solution to the question you have in the
subject line.
You are asking whether the contained class can have access
to the
container without any overhead. No, it cannot.
Then you're providing a solution where a particular class
has access
to particular instances of containers.
The fact that you *limit* the access to a certain class
doesn't make
that a solution of "some class accessing its container."
What you have
is a solution where everybody can access globals. That has
been there
for decades.
>that allows the existence of multiple
instances of the container class, the number of such
instances can be specified at run-time. These multiple
instances would be stored in a single global
std::vector<ContainerClass>.
And that's no memory overhead?
>Another single instance global
integer would be used as the current subscript into this
std::vector<ContainerClass>,
How about that one? That is both a memory overhead and a
time
overhead, because you need to manage it in non-zero time.
>specifying which ContainerClass
is being used. There would be no extra overhead in the
use
of either the ContainerClass, nor its ContainedClass.
When an object "uses" the container, it does it so because
some time
has been spent to set the global(s) properly. That is
overhead.
You may have something else in mind but you are not asking
that.
Ali
With my solution there is no additional memory or time
required for the contained class to access its container
over and above the memory and time required for any class to
access any other class.
In article <QW*****************@newsfe14.phx>,
Peter Olcott <No****@SeeScreen.comwrote:
>
<ac******@gmail.comwrote in message
news:f0**********************************@m3g2000 hsc.googlegroups.com...
>>
>>that allows the existence of multiple
instances of the container class, the number of such
instances can be specified at run-time. These multiple
instances would be stored in a single global
std::vector<ContainerClass>.
And that's no memory overhead?
>>Another single instance global
integer would be used as the current subscript into this
std::vector<ContainerClass>,
How about that one? That is both a memory overhead and a
time
overhead, because you need to manage it in non-zero time.
>>specifying which ContainerClass
is being used. There would be no extra overhead in the
use
of either the ContainerClass, nor its ContainedClass.
When an object "uses" the container, it does it so because
some time
has been spent to set the global(s) properly. That is
overhead.
With my solution there is no additional memory or time
required for the contained class to access its container
over and above the memory and time required for any class to
access any other class.
Uh?
Interesting solution. So if I make is very difficult for any class to
access any other class, then I can solve your problem since all the
book keeping and dereferencing needed for a class to access its
container will not be "over and above" what is needed for any other
classes. ?!?
Sorry but you are lying to yourself:
- having globals is overhead.
- having single instance globals is overhead
- having a global container is overhead.
- having a global container of containers is overhead (vector<ContainerClass>)
- having a global integer that is used as index into a vecotr is
overhead, you need to call vector.at(global_int). That is not free.
So that reduces your statement to: "I have a solution that has no
overhead that I don't ignore nor any that I am not unaware of."
Yannick
On Jun 15, 11:18*am, "Peter Olcott" <NoS...@SeeScreen.comwrote:
[snip]
I am hoping that
there might be some obscure C++ syntax that provides the
capability that I am seeking, without the need to resort to
the single global instance of the container to provide
access.
Did you ever stop to consider the possibility that your
goal is ill chosen? Making an object know that it is
contained in a container is not a good design plan.
An object should not be doing different things based
on how it is being held.
The phrase "obscure C++ syntax" ought to be a warning
signal in your own mind that you are approaching things
from the wrong end.
Maybe you need to refactor things so that you don't need
to do this.
Socks
On Jun 16, 8:27*am, ytrem...@nyx.nyx.net (Yannick Tremblay) wrote:
In article <QWg5k.5453$r_2.2...@newsfe14.phx>,
Peter Olcott <NoS...@SeeScreen.comwrote:
<acehr...@gmail.comwrote in message
news:f0**********************************@m3g2000h sc.googlegroups.com...
>that allows the existence of multiple
instances of the container class, the number of such
instances can be specified at run-time. These multiple
instances would be stored in a single global
std::vector<ContainerClass>.
And that's no memory overhead?
>Another single instance global
integer would be used as the current subscript into this
std::vector<ContainerClass>,
How about that one? That is both a memory overhead and a
time
overhead, because you need to manage it in non-zero time.
>specifying which ContainerClass
is being used. There would be no extra overhead in the
use
of either the ContainerClass, nor its ContainedClass.
When an object "uses" the container, it does it so because
some time
has been spent to set the global(s) properly. That is
overhead.
With my solution there is no additional memory or time
required for the contained class to access its container
over and above the memory and time required for any class to
access any other class.
Uh? *
Interesting solution. *So if I make is very difficult for any class to
access any other class, then I can solve your problem since all the
book keeping and dereferencing needed for a class to access its
container will not be "over and above" what is needed for any other
classes. *?!?
Sorry but you are lying to yourself:
- having globals is overhead. *
- having single instance globals is overhead
- having a global container is overhead.
- having a global container of containers is overhead (vector<ContainerClass>)
- having a global integer that is used as index into a vecotr is
overhead, you need to call vector.at(global_int). *That is not free.
So that reduces your statement to: "I have a solution that has no
overhead that I don't ignore nor any that I am not unaware of."
Yannick- Hide quoted text -
- Show quoted text -
http://en.wikipedia.org/wiki/Computational_overhead
Overhead is only the EXTRA cost over-and-above providing the basic
functionality.
My solution (although clumsy) has no EXTRA cost over and above the
normal cost of one class accessing another class.
The most typical solution would require that a pointer to the
container be passed to the contained class. This typical solution does
require an EXTRA cost over-and-above the basic cost of one class
accessing another class. The pointer takes memory, and it must also be
copied.
On Jun 16, 9:51*am, Puppet_Sock <puppet_s...@hotmail.comwrote:
On Jun 15, 11:18*am, "Peter Olcott" <NoS...@SeeScreen.comwrote:
[snip]
I am hoping that
there might be some obscure C++ syntax that provides the
capability that I am seeking, without the need to resort to
the single global instance of the container to provide
access.
Did you ever stop to consider the possibility that your
goal is ill chosen? Making an object know that it is
contained in a container is not a good design plan.
An object should not be doing different things based
on how it is being held.
The phrase "obscure C++ syntax" ought to be a warning
signal in your own mind that you are approaching things
from the wrong end.
Maybe you need to refactor things so that you don't need
to do this.
Socks
I am completely certain that my design is optimal in this specific
case even though it necessarily breaks some of the established rules.
The only reason that I even need to have the contained class is so
that I can overload the operator<() on it, and thus use std::sort().
I am beginning to think that my clumsy solution is the only possible
way (that can be implemented in C++) for providing access to a
contained classe's container that does not require any additional
space or time over-and-above the essential time and space required for
one class to access another.
"Jerry Coffin" <jc*****@taeus.comwrote in message
news:MP************************@news.sunsite.dk...
In article <2X*****************@newsfe11.phx>,
No****@SeeScreen.com
says...
>>
"Jerry Coffin" <jc*****@taeus.comwrote in message
news:MP************************@news.sunsite.dk.. .
In article <ku*****************@newsfe11.phx>,
No****@SeeScreen.com
says...
"Alf P. Steinbach" <al***@start.nowrote in message
[ ... ]
Hm, that sounds like much bullshit and zero
information,
iow., trolling.
www.SeeScreen.com
This technology can be applied to the automated
testing
of
video games. Video games are currently a $37 Billion
annual
market, and all testing is done manually by human
testers.
This looks like it retains the same level of
information
(i.e. none) and
adds only distraction. The question is exactly why you
require zero
overhead for this particular aspect of a program. The
annual revenues of
video games has nothing whatsoever to do with the
question
at hand.
I was directly addressing your last remark, which itself
avoided rather than addressed the issue at hand.
This was the first post I'd made to this thread, so none
of your remarks
shows any sign of addressing anything I'd said previously.
>You really
don't need to know these details to answer my question.
The
question is how can a contained class access its
container
without adding any overhead? It seems like you are saying
(in a very convoluted way) that you simply don't know.
Good
enough, no need for further discussion.
I'm not saying I do or don't know -- I simply pointed out
a serious
problem with your post. Unfortunately, I don't have a
direct answer to
your question, largely because I don't think your question
is entirely
clear -- in particular, while you say absolutely no
overhead is allowed,
you don't say whether it's purely time overhead, space
overhead, or both
that must be eliminated to qualify.
The somewhat clumsy solution that I derived takes zero extra
space and zero extra time over-and-above the space and time
required for a typical class to access another.
My guess is that there is no real answer -- if there is a
possibility of
more than one collection to which an object might belong,
_something_
must record which for the program to know -- and no matter
how careful
one is to minimize that, it must still exist. Likewise
if/when (for one
example) an object is moved from one collection to
another, that
something must be updated to match -- and, again, no
matter how
carefully that update time is optimized, it can never be
reduced to
zero.
The extra time and space required for a contained class to
access its container over-and-above the time and space
required for a typical class to access another can be and
has been reduced to zero. There is a very slight extra time
and extra space cost for switching between multiple
containers if and only if there is more than one such
container.
>
--
Later,
Jerry.
The universe is a figment of its own imagination.
PeteOlcott wrote:
On Jun 16, 9:51 am, Puppet_Sock <puppet_s...@hotmail.comwrote:
>On Jun 15, 11:18 am, "Peter Olcott" <NoS...@SeeScreen.comwrote:
[snip]
>>I am hoping that
there might be some obscure C++ syntax that provides the
capability that I am seeking, without the need to resort to
the single global instance of the container to provide
access.
Did you ever stop to consider the possibility that your
goal is ill chosen? Making an object know that it is
contained in a container is not a good design plan.
An object should not be doing different things based
on how it is being held.
The phrase "obscure C++ syntax" ought to be a warning
signal in your own mind that you are approaching things
from the wrong end.
Maybe you need to refactor things so that you don't need
to do this.
Socks
I am completely certain that my design is optimal in this specific
case even though it necessarily breaks some of the established rules.
The only reason that I even need to have the contained class is so
that I can overload the operator<() on it, and thus use std::sort().
The point that people are trying to make is that you don't necessary
need "optimal" at this level. It is not impossible you do, but often
times the inexperienced programmer will think they need to make low
optimizations, which is often wrong, and leads to a slower/less stable
product.
>
I am beginning to think that my clumsy solution is the only possible
way (that can be implemented in C++) for providing access to a
contained classe's container that does not require any additional
space or time over-and-above the essential time and space required for
one class to access another.
It may be the only way to implement the particular design you're
insisting on. It is definitely not the only way to implement a solution
to your particular problem.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
In article <5dd80816-49c4-442d-a25c-076b6c260305
@y21g2000hsf.googlegroups.com>, Pe********@gmail.com says...
[ ... ]
The only reason that I even need to have the contained class is so
that I can overload the operator<() on it, and thus use std::sort().
You can use std::sort without having an overloaded operator< for the
type. You can create the comparison as either a function or a functor,
and then pass it as the third parameter to std::sort. For example:
#include <vector>
#include <algorithm>
#include <iostream>
class X {
int y;
public:
X(int a=0) : y(a) {}
operator int() const { return y; }
};
struct less {
bool operator()(X const &a, X const &b) {
return (int)a < (int)b;
}
};
int main() {
std::vector<Xx;
for (int i=0; i<20; i++)
x.push_back(rand());
std::sort(x.begin(), x.end(), less());
std::copy(x.begin(), x.end(),
std::ostream_iterator<int>(std::cout, "\n"));
return 0;
}
--
Later,
Jerry.
The universe is a figment of its own imagination.
On Jun 17, 1:00*am, Jerry Coffin <jcof...@taeus.comwrote:
In article <5dd80816-49c4-442d-a25c-076b6c260305
@y21g2000hsf.googlegroups.com>, PeteOlc...@gmail.com says...
[ ... ]
The only reason that I even need to have the contained class is so
that I can overload the operator<() on it, and thus use std::sort().
You can use std::sort without having an overloaded operator< for the
type. You can create the comparison as either a function or a functor,
and then pass it as the third parameter to std::sort. For example:
#include <vector>
#include <algorithm>
#include <iostream>
class X {
* * * * int y;
public:
* * * * X(int a=0) : y(a) {}
* * * * operator int() const { return y; }
};
struct less {
* * * * bool operator()(X const &a, X const &b) {
* * * * * * * * return (int)a < (int)b;
* * * * }
};
int main() {
* * * * std::vector<Xx;
* * * * for (int i=0; i<20; i++)
* * * * * * * * x.push_back(rand());
* * * * std::sort(x.begin(), x.end(), less());
* * * * std::copy(x.begin(), x.end(),
* * * * * * * * std::ostream_iterator<int>(std::cout, "\n")); *
* * * * return 0;
}
--
* * Later,
* * Jerry.
The universe is a figment of its own imagination.
What about the case where the contained class must store its data in
its container?
In article <293706b4-cbee-4cc0-bbe2-0b2c6ba42191
@z72g2000hsb.googlegroups.com>, Pe********@gmail.com says...
[ ... ]
What about the case where the contained class must store its data in
its container?
I'm afraid I don't understand what you're asking.
--
Later,
Jerry.
The universe is a figment of its own imagination.
On Jun 17, 8:30*am, PeteOlcott <PeteOlc...@gmail.comwrote:
[snips]
What about the case where the contained class must store its data in
its container?
It's not even a little clear what you mean.
Do you mean: The objects in the container stick copies
of themselves into the same container? If so, then you
have a pathological design that should be refactored.
Do you mean: Actual copies of the objects are stored in
the container, as opposed to pointers to the objects?
If that's the issue, and you are concerned about such
things as excess effort involved in swapping copies
instead of pointers, there are many ways of proceeding.
Or do you mean something else?
Socks
On Jun 17, 9:45*am, Puppet_Sock <puppet_s...@hotmail.comwrote:
On Jun 17, 8:30*am, PeteOlcott <PeteOlc...@gmail.comwrote:
[snips]
What about the case where the contained class must store its data in
its container?
It's not even a little clear what you mean.
Do you mean: The objects in the container stick copies
of themselves into the same container? If so, then you
have a pathological design that should be refactored.
Do you mean: Actual copies of the objects are stored in
the container, as opposed to pointers to the objects?
If that's the issue, and you are concerned about such
things as excess effort involved in swapping copies
instead of pointers, there are many ways of proceeding.
Or do you mean something else?
Socks
Here is what I mean. For this specific use it is about the highest
performance (space and time) possible. A Large number of Contained
elements can be read in and written to disk as a single block read or
block write. Also all of the extra memory allocation overhead that
would normally be associated with the individual Contained elements
has been reduced to making two large allocations.
#define uint8 unsigned char
#define uint32 unsigned int
ContainedClass {
uint32 Offset;
bool operator<(const ContainedClass& CC);
}
ContainerClass {
uint32 Length; // All ContainedClass elements are the same Length
std::vector<uint8Bytes;
std::vector<ContainedClassContained;
uint8& operator[](uint32 N){ return Bytes[N]; };
void sort(){ std::sort(Contained.begin(), Contained.end()) };
} Container;
bool ContainedClass::operator<(const ContainedClass& CC)
{
uint32 Last = this->Offset + Container.Length;
for (int N = this->Offset, M = CC.Offset; N < Last; N++, M++)
if (Container[N] < Container[M])
return true;
else if (Container[N] Container[M])
return false;
return false; // They must be Equal, thus Not(LessThan)
}
On Jun 17, 2:03*pm, PeteOlcott <PeteOlc...@gmail.comwrote:
On Jun 17, 9:45*am, Puppet_Sock <puppet_s...@hotmail.comwrote:
On Jun 17, 8:30*am, PeteOlcott <PeteOlc...@gmail.comwrote:
[snips]
What about the case where the contained class must store its data in
its container?
It's not even a little clear what you mean.
Do you mean: The objects in the container stick copies
of themselves into the same container? If so, then you
have a pathological design that should be refactored.
Do you mean: Actual copies of the objects are stored in
the container, as opposed to pointers to the objects?
If that's the issue, and you are concerned about such
things as excess effort involved in swapping copies
instead of pointers, there are many ways of proceeding.
Or do you mean something else?
Socks
Here is what I mean. For this specific use it is about the highest
performance (space and time) possible. A Large number of Contained
elements can be read in and written to disk as a single block read or
block write. Also all of the extra memory allocation overhead that
would normally be associated with the individual Contained elements
has been reduced to making two large allocations.
Ok, I have to say your response had a lot of words in it,
but didn't come near to answering the question. And, after
nearly 30 posts in this thread, we finally illicit some
part of the actual spec. You seem to be talking about
writing stuff to disk, and reading it back, in an efficient
manner, when you have a bunch of objects stored in a
container class of some kind.
#define uint8 *unsigned char
#define uint32 unsigned int
ContainedClass {
* uint32 Offset;
* bool operator<(const ContainedClass& CC);
}
ContainerClass {
* *uint32 Length; *// All ContainedClass elements are the same Length
* *std::vector<uint8Bytes;
* *std::vector<ContainedClassContained;
* *uint8& operator[](uint32 N){ return Bytes[N]; };
* *void sort(){ std::sort(Contained.begin(), Contained.end()) };
} Container;
bool ContainedClass::operator<(const ContainedClass& CC)
{
* uint32 Last = this->Offset + Container.Length;
* for (int N = this->Offset, M = CC.Offset; N < Last; N++, M++)
* * if (Container[N] < Container[M])
* * * return true;
* * else if (Container[N] Container[M])
* * * return false;
return false; *// They must be Equal, thus Not(LessThan)
}
Though your sample code does not seem to be related to the
issue of reading from or writing to disk. Plus, what you
posted sure won't compile.
If what you want to do is an efficient read/write of a large
block of data, there are a variety of approaches. None of
them need the object to know it is contained in a container.
Is that what you are on about? Storing and reading back
a std container of objects?
Socks
On Jun 17, 2:43*pm, Puppet_Sock <puppet_s...@hotmail.comwrote:
On Jun 17, 2:03*pm, PeteOlcott <PeteOlc...@gmail.comwrote:
On Jun 17, 9:45*am, Puppet_Sock <puppet_s...@hotmail.comwrote:
On Jun 17, 8:30*am, PeteOlcott <PeteOlc...@gmail.comwrote:
[snips]
What about the case where the contained class must store its data in
its container?
It's not even a little clear what you mean.
Do you mean: The objects in the container stick copies
of themselves into the same container? If so, then you
have a pathological design that should be refactored.
Do you mean: Actual copies of the objects are stored in
the container, as opposed to pointers to the objects?
If that's the issue, and you are concerned about such
things as excess effort involved in swapping copies
instead of pointers, there are many ways of proceeding.
Or do you mean something else?
Socks
Here is what I mean. For this specific use it is about the highest
performance (space and time) possible. A Large number of Contained
elements can be read in and written to disk as a single block read or
block write. Also all of the extra memory allocation overhead that
would normally be associated with the individual Contained elements
has been reduced to making two large allocations.
Ok, I have to say your response had a lot of words in it,
but didn't come near to answering the question. And, after
nearly 30 posts in this thread, we finally illicit some
part of the actual spec. You seem to be talking about
writing stuff to disk, and reading it back, in an efficient
manner, when you have a bunch of objects stored in a
container class of some kind.
#define uint8 *unsigned char
#define uint32 unsigned int
ContainedClass {
* uint32 Offset;
* bool operator<(const ContainedClass& CC);
}
ContainerClass {
* *uint32 Length; *// All ContainedClass elements are the same Length
* *std::vector<uint8Bytes;
* *std::vector<ContainedClassContained;
* *uint8& operator[](uint32 N){ return Bytes[N]; };
* *void sort(){ std::sort(Contained.begin(), Contained.end()) };
} Container;
bool ContainedClass::operator<(const ContainedClass& CC)
{
* uint32 Last = this->Offset + Container.Length;
* for (int N = this->Offset, M = CC.Offset; N < Last; N++, M++)
* * if (Container[N] < Container[M])
* * * return true;
* * else if (Container[N] Container[M])
* * * return false;
return false; *// They must be Equal, thus Not(LessThan)
}
Though your sample code does not seem to be related to the
issue of reading from or writing to disk. Plus, what you
posted sure won't compile.
If what you want to do is an efficient read/write of a large
block of data, there are a variety of approaches. None of
them need the object to know it is contained in a container.
Is that what you are on about? Storing and reading back
a std container of objects?
Socks- Hide quoted text -
- Show quoted text -- Hide quoted text -
- Show quoted text -
Think about it as storage, retrieval, allocation, access, and
manipulation of strings such that the space and time requirements are
at the current edge of hardware capability. Multiple GB of data stored
in RAM and retrieved from disk. A slight modification to the provided
code, and these strings could vary in length.
PeteOlcott schrieb:
Here is what I mean. For this specific use it is about the highest
performance (space and time) possible. A Large number of Contained
elements can be read in and written to disk as a single block read or
block write. Also all of the extra memory allocation overhead that
would normally be associated with the individual Contained elements
has been reduced to making two large allocations.
#define uint8 unsigned char
#define uint32 unsigned int
typedef unsigned char uint8;
typedef unsigned int uint32;
>
ContainedClass {
uint32 Offset;
bool operator<(const ContainedClass& CC);
}
ContainerClass {
uint32 Length; // All ContainedClass elements are the same Length
std::vector<uint8Bytes;
std::vector<ContainedClassContained;
uint8& operator[](uint32 N){ return Bytes[N]; };
void sort(){ std::sort(Contained.begin(), Contained.end()) };
} Container;
This code doesn't compile, but assuming a working version of this code,
you could use std::sort with a functor with a pointer to its contained
class (untested! code):
struct ContainedLess
{
ContainedLess(const ContainerClass* container_) :
container(container_) {}
bool operator()(const ContainedClass& c1, const ContainedClass& c2)
const
{
// compare c1 and c2, use member 'container'
// to access container class
const uint8* p1 = &container->Bytes[c1.Offset];
const uint8* p2 = &container->Bytes[c2.Offset];
const uint8* end = p1 + container->Length;
for (; p1 != end; ++p1, ++p2)
{
// ...
}
}
private:
const ContainerClass* container;
};
void ContainerClass::sort()
{
std::sort(Contained.begin(), Contained.end(), ContainedLess(this));
}
It also would be a good idea to make some members of the classes private.
>
bool ContainedClass::operator<(const ContainedClass& CC)
{
uint32 Last = this->Offset + Container.Length;
for (int N = this->Offset, M = CC.Offset; N < Last; N++, M++)
if (Container[N] < Container[M])
return true;
else if (Container[N] Container[M])
return false;
return false; // They must be Equal, thus Not(LessThan)
}
--
Thomas
"Thomas J. Gritzan" <ph*************@gmx.dewrote in
message news:g3**********@newsreader2.netcologne.de...
PeteOlcott schrieb:
>Here is what I mean. For this specific use it is about
the highest
performance (space and time) possible. A Large number of
Contained
elements can be read in and written to disk as a single
block read or
block write. Also all of the extra memory allocation
overhead that
would normally be associated with the individual
Contained elements
has been reduced to making two large allocations.
#define uint8 unsigned char
#define uint32 unsigned int
typedef unsigned char uint8;
typedef unsigned int uint32;
>>
ContainedClass {
uint32 Offset;
bool operator<(const ContainedClass& CC);
}
ContainerClass {
uint32 Length; // All ContainedClass elements are the
same Length
std::vector<uint8Bytes;
std::vector<ContainedClassContained;
uint8& operator[](uint32 N){ return Bytes[N]; };
void sort(){ std::sort(Contained.begin(),
Contained.end()) };
} Container;
This code doesn't compile, but assuming a working version
of this code, you could use std::sort with a functor with
a pointer to its contained class (untested! code):
struct ContainedLess
{
ContainedLess(const ContainerClass* container_) :
container(container_) {}
bool operator()(const ContainedClass& c1, const
ContainedClass& c2) const
{
// compare c1 and c2, use member 'container'
// to access container class
const uint8* p1 = &container->Bytes[c1.Offset];
const uint8* p2 = &container->Bytes[c2.Offset]; const
uint8* end = p1 + container->Length;
for (; p1 != end; ++p1, ++p2)
{
// ...
}
}
private:
const ContainerClass* container;
};
void ContainerClass::sort()
{
std::sort(Contained.begin(), Contained.end(),
ContainedLess(this));
}
It also would be a good idea to make some members of the
classes private.
That would be the first attempt at actually answering my
original question. I was guessing that the answer might have
something to do with functors. The solution does look pretty
clean, far cleaner than the solution that I derived.
My only question would be whether or not it avoided the
overhead of initializing the pointer to the container upon
every comparison. I would estimate that you would already
know this answer, knowing more clearly the underlying
semantics of the syntax that you specified.
>
>>
bool ContainedClass::operator<(const ContainedClass& CC)
{
uint32 Last = this->Offset + Container.Length;
for (int N = this->Offset, M = CC.Offset; N < Last;
N++, M++)
if (Container[N] < Container[M])
return true;
else if (Container[N] Container[M])
return false;
return false; // They must be Equal, thus Not(LessThan)
}
--
Thomas
In article <g3**********@newsreader2.netcologne.de>,
Thomas J. Gritzan <ph*************@gmx.dewrote:
>PeteOlcott schrieb:
>#define uint8 unsigned char
#define uint32 unsigned int
typedef unsigned char uint8;
typedef unsigned int uint32;
If you are lucky :-(
Sorry, slightly switching topic but although the typedef are an
improvement over the #define, neither are quite safe. Most safe to
rely on the platform standard headers to have it right:
#include <stdint.h // might be optional on your platform
uint32_t aSafe32bitsIntegerThatWillNotSuddentlyBecome64bits Or16Or8;
In article <71**********************************@e53g2000hsa. googlegroups.com>,
PeteOlcott <Pe********@gmail.comwrote:
[deleted attempts at explaining that everything has a cost that has
been totally ignored]
>Also my solution for multiple instances of ContainerClasses providing
access to themselves to their ContainedClasses has no additional space
or time cost involved in the specific instance of this provided
access. There is a slight additional space and time cost in providing
multiple instances of the ContainerClass, but, this additional cost
does not directly pertain to providing this access. Instead this
additional cost only pertains to the provision of multiple instances
of the ContainerClass. The singleton case of this ContainerClass has
no additional costs of any kind what-so-ever.
Sorry Pete but this come forward as: "my solution is perfect in all
ways" and sadly even as: "I am perfect in all ways"
So I am afraid that all we can conclude is that although your solution
has a cost, you think it has none and it is perfect. Despite several
peoples attempting to show you otherwise, you refuse to see any cost
to it.
An alternative approach has been suggested when you finally posted
some example code and clarified your requirements to something
realistic. IMO, the proposed solution with an external comparison
function is an improvement which at least from a maintenance point of
view demonstrate that your original solution was not perfect.
However, since it is your code and your project, you are perfectly
free to use the solution of your choice.
Cheers,
Yannick
On Jun 19, 9:45*am, ytrem...@nyx.nyx.net (Yannick Tremblay) wrote:
In article <71264dda-c688-4891-b2f8-98592cbc1...@e53g2000hsa.googlegroups..com>,
PeteOlcott *<PeteOlc...@gmail.comwrote:
[deleted attempts at explaining that everything has a cost that has
been totally ignored]
Also my solution for multiple instances of ContainerClasses providing
access to themselves to their ContainedClasses has no additional space
or time cost involved in the specific instance of this provided
access. There is a slight additional space and time cost in providing
multiple instances of the ContainerClass, but, this additional cost
does not directly pertain to providing this access. Instead this
additional cost only pertains to the provision of multiple instances
of the ContainerClass. The singleton case of this ContainerClass has
no additional costs of any kind what-so-ever.
Sorry Pete but this come forward as: "my solution is perfect in all
ways" and sadly even as: "I am perfect in all ways"
So I am afraid that all we can conclude is that although your solution
has a cost, you think it has none and it is perfect. * Despite several
peoples attempting to show you otherwise, you refuse to see any cost
to it. *
An alternative approach has been suggested when you finally posted
some example code and clarified your requirements to something
realistic. * IMO, the proposed solution with an external comparison
function is an improvement which at least from a maintenance point of
view demonstrate that your original solution was not perfect.
However, since it is your code and your project, you are perfectly
free to use the solution of your choice.
Cheers,
Yannick
I agree that the alternative solution is superior to my solution form
the maintenance point of view, and that my solution is quite clumsy
from this point of view. It is an objective fact that my solution has
no ADDTIONAL
PeteOlcott schrieb:
On Jun 19, 9:45 am, ytrem...@nyx.nyx.net (Yannick Tremblay) wrote:
>In article <71264dda-c688-4891-b2f8-98592cbc1...@e53g2000hsa.googlegroups.com>,
PeteOlcott <PeteOlc...@gmail.comwrote:
[deleted attempts at explaining that everything has a cost that has
been totally ignored]
>>Also my solution for multiple instances of ContainerClasses providing
access to themselves to their ContainedClasses has no additional space
or time cost involved in the specific instance of this provided
access. There is a slight additional space and time cost in providing
multiple instances of the ContainerClass, but, this additional cost
does not directly pertain to providing this access. Instead this
additional cost only pertains to the provision of multiple instances
of the ContainerClass. The singleton case of this ContainerClass has
no additional costs of any kind what-so-ever.
Sorry Pete but this come forward as: "my solution is perfect in all
ways" and sadly even as: "I am perfect in all ways"
So I am afraid that all we can conclude is that although your solution
has a cost, you think it has none and it is perfect. Despite several
peoples attempting to show you otherwise, you refuse to see any cost
to it.
An alternative approach has been suggested when you finally posted
some example code and clarified your requirements to something
realistic. IMO, the proposed solution with an external comparison
function is an improvement which at least from a maintenance point of
view demonstrate that your original solution was not perfect.
However, since it is your code and your project, you are perfectly
free to use the solution of your choice.
Cheers,
Yannick
I agree that the alternative solution is superior to my solution form
the maintenance point of view, and that my solution is quite clumsy
from this point of view. It is an objective fact that my solution has
no ADDTIONAL
test
On Jun 19, 9:45*am, ytrem...@nyx.nyx.net (Yannick Tremblay) wrote:
In article <71264dda-c688-4891-b2f8-98592cbc1...@e53g2000hsa.googlegroups..com>,
PeteOlcott *<PeteOlc...@gmail.comwrote:
[deleted attempts at explaining that everything has a cost that has
been totally ignored]
Also my solution for multiple instances of ContainerClasses providing
access to themselves to their ContainedClasses has no additional space
or time cost involved in the specific instance of this provided
access. There is a slight additional space and time cost in providing
multiple instances of the ContainerClass, but, this additional cost
does not directly pertain to providing this access. Instead this
additional cost only pertains to the provision of multiple instances
of the ContainerClass. The singleton case of this ContainerClass has
no additional costs of any kind what-so-ever.
Sorry Pete but this come forward as: "my solution is perfect in all
ways" and sadly even as: "I am perfect in all ways"
So I am afraid that all we can conclude is that although your solution
has a cost, you think it has none and it is perfect. * Despite several
peoples attempting to show you otherwise, you refuse to see any cost
to it. *
An alternative approach has been suggested when you finally posted
some example code and clarified your requirements to something
realistic. * IMO, the proposed solution with an external comparison
function is an improvement which at least from a maintenance point of
view demonstrate that your original solution was not perfect.
However, since it is your code and your project, you are perfectly
free to use the solution of your choice.
Cheers,
Yannick
Google Groups posting screwed up and posted my last message before I
had finsihed typing it.
I agree that the alternative solution is far superior to the clumsy
solution that I derived from a code maintenance point of view, yet it
is also an objective fact that the singleton solution that I proposed
has no ADDTIONAL space or time cost over-and-above the typical case of
one class accessing another, because it is exactly this same typical
case of one class accessing another, nothing more and nothing less.
The only issue left to resolve is whether or not this proposed
solution also has zero (or negligible) ADDITIONAL cost.
In either case this solution would be greatly superior to the solution
that I derived. If the proposed solution must copy a pointer to the
container for every single comparision, then the proposed solution
would be superior from a code maintenance point of view, and inferior
from a time cost point of view.
"test0r" <ch***********@gmx.netwrote in message
news:2b***************************@news.usenext.de ...
PeteOlcott schrieb:
>On Jun 19, 9:45 am, ytrem...@nyx.nyx.net (Yannick
Tremblay) wrote:
>>In article
<71264dda-c688-4891-b2f8-98592cbc1...@e53g2000hsa.googlegroups.com>,
PeteOlcott <PeteOlc...@gmail.comwrote:
[deleted attempts at explaining that everything has a
cost that has
been totally ignored]
Also my solution for multiple instances of
ContainerClasses providing
access to themselves to their ContainedClasses has no
additional space
or time cost involved in the specific instance of this
provided
access. There is a slight additional space and time
cost in providing
multiple instances of the ContainerClass, but, this
additional cost
does not directly pertain to providing this access.
Instead this
additional cost only pertains to the provision of
multiple instances
of the ContainerClass. The singleton case of this
ContainerClass has
no additional costs of any kind what-so-ever.
Sorry Pete but this come forward as: "my solution is
perfect in all
ways" and sadly even as: "I am perfect in all ways"
So I am afraid that all we can conclude is that although
your solution
has a cost, you think it has none and it is perfect.
Despite several
peoples attempting to show you otherwise, you refuse to
see any cost
to it.
An alternative approach has been suggested when you
finally posted
some example code and clarified your requirements to
something
realistic. IMO, the proposed solution with an external
comparison
function is an improvement which at least from a
maintenance point of
view demonstrate that your original solution was not
perfect.
However, since it is your code and your project, you are
perfectly
free to use the solution of your choice.
Cheers,
Yannick
I agree that the alternative solution is superior to my
solution form
the maintenance point of view, and that my solution is
quite clumsy
from this point of view. It is an objective fact that my
solution has
no ADDTIONAL
test
Test results, the ContainedLess constructor is called only
once, thus the proposed is the solution is the one that I
have been looking for, it is a superb solution in every
aspect.
"Yannick Tremblay" <yt******@nyx.nyx.netwrote in message
news:12*************@irys.nyx.net...
In article <g3**********@newsreader2.netcologne.de>,
Thomas J. Gritzan <ph*************@gmx.dewrote:
>>PeteOlcott schrieb:
>>#define uint8 unsigned char
#define uint32 unsigned int
typedef unsigned char uint8;
typedef unsigned int uint32;
If you are lucky :-(
Sorry, slightly switching topic but although the typedef
are an
improvement over the #define, neither are quite safe.
Most safe to
rely on the platform standard headers to have it right:
The whole purpose of this convention is to provide a
cross-platform single standard, so your suggestion would
defeat this purpose. Besides what could be unsafe about the
above constructs?
#include <stdint.h // might be optional on your platform
uint32_t
aSafe32bitsIntegerThatWillNotSuddentlyBecome64bits Or16Or8;
On Jun 19, 4:29*am, ytrem...@nyx.nyx.net (Yannick Tremblay) wrote:
In article <g3bvrg$qn...@newsreader2.netcologne.de>,
Thomas J. Gritzan <phygon_antis...@gmx.dewrote:
PeteOlcott schrieb:
#define uint8 *unsigned char
#define uint32 unsigned int
typedef unsigned char uint8;
typedef unsigned int uint32;
If you are lucky :-(
Sorry, slightly switching topic but although the typedef are an
improvement over the #define, neither are quite safe. *Most safe to
rely on the platform standard headers to have it right:
#include <stdint.h*// might be optional on your platform
uint32_t aSafe32bitsIntegerThatWillNotSuddentlyBecome64bits Or16Or8;
I forgot that I was talking in a generic C++ forum, I rarely do this.
I almost always talk in the MFC forum. Of cource my #define statements
would be redefined for each of the differing platforms. The idea is
the uint32 is always an unsigned 32-bit integer no matter what
platform you may be on.
Peter Olcott wrote:
"Yannick Tremblay" <yt******@nyx.nyx.netwrote in message
news:12*************@irys.nyx.net...
>In article <g3**********@newsreader2.netcologne.de>,
Thomas J. Gritzan <ph*************@gmx.dewrote:
>>PeteOlcott schrieb:
#define uint8 unsigned char
#define uint32 unsigned int
typedef unsigned char uint8;
typedef unsigned int uint32;
If you are lucky :-(
Sorry, slightly switching topic but although the typedef
are an
improvement over the #define, neither are quite safe.
Most safe to
rely on the platform standard headers to have it right:
The whole purpose of this convention is to provide a
cross-platform single standard, so your suggestion would
defeat this purpose. Besides what could be unsafe about the
above constructs?
Platform *standard* headers. Meaning if the platform implements the
standard, the file stdint.h should exist. In this file, it will define
uint32_t appropriately, whether it is a system that needs to use
"unsigned long int", or "unsigned long long", or "unsigned short" to do
so.
Both the #define and typedefs above may change the size if you change
compilers, but the stdint.h definitions will be consistent, since they
are managed by the platform developers.
>
>#include <stdint.h // might be optional on your platform
uint32_t
aSafe32bitsIntegerThatWillNotSuddentlyBecome64bit sOr16Or8;
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
On 2008-06-20 12:14:28 -0400, Daniel Pitts
<ne******************@virtualinfinity.netsaid:
Platform *standard* headers. Meaning if the platform implements the
standard, the file stdint.h should exist. In this file, it will define
uint32_t appropriately, whether it is a system that needs to use
"unsigned long int", or "unsigned long long", or "unsigned short" to do
so.
Just a small clarification: it will define uint32_t only if the
implementation has an integral type that's exactly 32 bits wide. If you
need at least 32 bits, use uint_least32_t.
--
Pete
Roundhouse Consulting, Ltd. ( www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
( www.petebecker.com/tr1book) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Nobody |
last post by:
I have a website that is built around a web-application that my
company purchased. My company has full ownership and administrative
rights to this software and its corresponding files. It uses...
|
by: N?ant Humain |
last post by:
I have just begun learning Python so that I can write a simple script
to make modification of a file used by another Python script easier.
This file is basically a list of regular expressions. What...
|
by: New MSSQL DBA |
last post by:
hi all, I am considering what should be the best way of implementing
the following requirement.
I've got a SQL2K production server. Now I've got another machine as the
standby machine for this...
|
by: Michiel Alsters |
last post by:
Hello everybody,
I hope anybody can help me. I'll try to give a brief overview of my
problem. I have running a program that performs a heavy calculation.
To give the user feedback what the...
|
by: planetthoughtful |
last post by:
Hi All,
As always, my posts come with a 'Warning: Newbie lies ahead!'
disclaimer...
I'm wondering if it's possible, using raw_input(), to provide a
'default' value with the prompt?
I would...
|
by: Lee |
last post by:
Once the business logic has been written and the basic elements are
built into a page, what is the recommended way to provide the site
innards to graphics design people without providing source...
|
by: Billy |
last post by:
I'm using the POST method to submit a simple form html page with yes/no
and checkbox fields to an asp response page which stores the values in
a new dim string, then uses it to build a new table...
|
by: Adam Sandler |
last post by:
Hello,
Having an issue with my ASP.Net page.
I use some COTS, which for all intents and purposes, simply makes a
jpeg file and physically places it in a directory on the web server.
The...
|
by: AKS |
last post by:
Hi! Here's a small test case (for Firefox):
var o = {
p: {
func: function () {},
},
test: function () {
var msg = ;
var d = new Date;
|
by: watches0898 |
last post by:
Edwards Garments Company is one popular industry specific designer
specializing in work wear that ranges from chef coats to chef hats to
separates to housecleaning uniforms. Edwards Garments...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |
