Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Providing a no-overhead way for a contained class to access its container?

Reply
Thread Tools

Providing a no-overhead way for a contained class to access its container?

 
 
PeteOlcott
Guest
Posts: n/a
 
      06-19-2008
On Jun 19, 9:45*am, (E-Mail Removed) (Yannick Tremblay) wrote:
> In article <(E-Mail Removed)..com>,
>
> PeteOlcott *<(E-Mail Removed)> wrote:
>
> [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
 
Reply With Quote
 
 
 
 
test0r
Guest
Posts: n/a
 
      06-19-2008
PeteOlcott schrieb:
> On Jun 19, 9:45 am, (E-Mail Removed) (Yannick Tremblay) wrote:
>> In article <(E-Mail Removed)>,
>>
>> PeteOlcott <(E-Mail Removed)> wrote:
>>
>> [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
 
Reply With Quote
 
 
 
 
PeteOlcott
Guest
Posts: n/a
 
      06-19-2008
On Jun 19, 9:45*am, (E-Mail Removed) (Yannick Tremblay) wrote:
> In article <(E-Mail Removed)..com>,
>
> PeteOlcott *<(E-Mail Removed)> wrote:
>
> [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.
 
Reply With Quote
 
Peter Olcott
Guest
Posts: n/a
 
      06-19-2008

"test0r" <(E-Mail Removed)> wrote in message
news:2ba59$485a76b4$d51738fe$(E-Mail Removed) ...
> PeteOlcott schrieb:
>> On Jun 19, 9:45 am, (E-Mail Removed) (Yannick
>> Tremblay) wrote:
>>> In article
>>> <(E-Mail Removed)>,
>>>
>>> PeteOlcott <(E-Mail Removed)> wrote:
>>>
>>> [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.


 
Reply With Quote
 
Peter Olcott
Guest
Posts: n/a
 
      06-20-2008

"Yannick Tremblay" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> In article <g3bvrg$qn9$(E-Mail Removed)>,
> Thomas J. Gritzan <(E-Mail Removed)> wrote:
>>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;
>
>
>



 
Reply With Quote
 
PeteOlcott
Guest
Posts: n/a
 
      06-20-2008
On Jun 19, 4:29*am, (E-Mail Removed) (Yannick Tremblay) wrote:
> In article <g3bvrg$(E-Mail Removed)>,
> Thomas J. Gritzan <(E-Mail Removed)> wrote:
>
> >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.
 
Reply With Quote
 
Daniel Pitts
Guest
Posts: n/a
 
      06-20-2008
Peter Olcott wrote:
> "Yannick Tremblay" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> In article <g3bvrg$qn9$(E-Mail Removed)>,
>> Thomas J. Gritzan <(E-Mail Removed)> wrote:
>>> 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
>> aSafe32bitsIntegerThatWillNotSuddentlyBecome64bits Or16Or8;
>>
>>
>>

>
>



--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
"An attempt was made to access a socket in a way forbidden by its access permissions" exiter Computer Support 3 02-27-2012 08:36 PM
Its a bird, its a plane, its.. um, an Attribute based System? thunk Ruby 14 04-03-2010 10:08 AM
Its a bird, its a plane, its.. um, an Attribute based System? thunk Ruby 0 04-01-2010 10:25 PM
Its a bird, its a plane, no ummm, its a Ruide thunk Ruby 1 03-30-2010 11:10 AM
Providing services for 802.11b and 802.11g on the cisco 1200 access points Chris Davies Cisco 6 06-15-2004 01:42 PM



Advertisments