Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Automagic determination of definition based on definition location.

Reply
Thread Tools

Automagic determination of definition based on definition location.

 
 
Jon Slaughter
Guest
Posts: n/a
 
      10-26-2005

At the bottom of the page on

http://ootips.org/yonat/4dev/smart-pointers.html

It is noted that one would use different types of pointers based on
different "locations" in the code. What I'm wondering is if there is a way
to have the compiler automatically determine which type to use depending on
its location such as

class T
{
MyUberPointer<int> i;
}

vs.

void func()
{
myUberPointer<int> i;
}


so that MyUberPointer uses a copied pointer while myUberPointer uses an auto
pointer

one might have some policy based parameter so that one could override the
default, but in this case the default is "location" dependent. i.e., it
would be nice if there was an implicit parameter passed to templates that
held the location of its decleration similar to the way the this pointer
works... then one could have seperate template definitions depending on the
location. Hence one could easily have "polymorphism" of types based on
"location". I do know one can easily do this by having some extra parameter
such as


class T
{
UberPointer<int,1> i;
}

vs.

void func()
{
UberPointer<int,0> i;
}

but ofcourse this isn't the best way.


Jon


 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      10-26-2005
Jon Slaughter wrote:
> At the bottom of the page on
>
> http://ootips.org/yonat/4dev/smart-pointers.html
>
> It is noted that one would use different types of pointers based on
> different "locations" in the code. What I'm wondering is if there is a way
> to have the compiler automatically determine which type to use depending on
> its location such as
>
> class T
> {
> MyUberPointer<int> i;
> }
>
> vs.
>
> void func()
> {
> myUberPointer<int> i;
> }
>
>
> so that MyUberPointer uses a copied pointer while myUberPointer uses an auto
> pointer
>
> one might have some policy based parameter so that one could override the
> default, but in this case the default is "location" dependent. i.e., it
> would be nice if there was an implicit parameter passed to templates that
> held the location of its decleration similar to the way the this pointer
> works... then one could have seperate template definitions depending on the
> location. Hence one could easily have "polymorphism" of types based on
> "location". I do know one can easily do this by having some extra parameter
> such as
>
>
> class T
> {
> UberPointer<int,1> i;
> }
>
> vs.
>
> void func()
> {
> UberPointer<int,0> i;
> }
>
> but ofcourse this isn't the best way.


Why isn't it? Imagine that you want to use an auto pointer inside
a class or a copied pointer inside a function. What then? Suddenly the
system (or the compiler) is choosing for you and you seem to have no
control over the result. Develop a policy template/class and use it.
First, it's explicit, so you have full control. Second, it's self-
documenting:

void func()
{
UberPointer<int,AutoPointer> i;
}

class T
{
UberPointer<int,CopyPointer> i;
};

More on policy-based programming in "Modern C++ Design" and elsewhere.

V
 
Reply With Quote
 
 
 
 
mlimber
Guest
Posts: n/a
 
      10-26-2005

Jon Slaughter wrote:
> At the bottom of the page on
>
> http://ootips.org/yonat/4dev/smart-pointers.html
>
> It is noted that one would use different types of pointers based on
> different "locations" in the code. What I'm wondering is if there is a way
> to have the compiler automatically determine which type to use depending on
> its location such as
>
> class T
> {
> MyUberPointer<int> i;
> }
>
> vs.
>
> void func()
> {
> myUberPointer<int> i;
> }
>
>
> so that MyUberPointer uses a copied pointer while myUberPointer uses an auto
> pointer
>
> one might have some policy based parameter so that one could override the
> default, but in this case the default is "location" dependent. i.e., it
> would be nice if there was an implicit parameter passed to templates that
> held the location of its decleration similar to the way the this pointer
> works... then one could have seperate template definitions depending on the
> location. Hence one could easily have "polymorphism" of types based on
> "location". I do know one can easily do this by having some extra parameter
> such as
>
>
> class T
> {
> UberPointer<int,1> i;
> }
>
> vs.
>
> void func()
> {
> UberPointer<int,0> i;
> }
>
> but ofcourse this isn't the best way.
>
>
> Jon


There's no way to determine the context at compile time that I know of,
and there probably shouldn't be. IMHO, the latter code *is* actually
the best way (though not with 1 and 0; meaningful policy names would be
better) because having the same code behave differently in different
contexts could easily lead to implicit (read: hard-to-find) bugs.

Cheers! --M

 
Reply With Quote
 
Jon Slaughter
Guest
Posts: n/a
 
      10-26-2005

"mlimber" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
>
> Jon Slaughter wrote:
>> At the bottom of the page on
>>
>> http://ootips.org/yonat/4dev/smart-pointers.html
>>
>> It is noted that one would use different types of pointers based on
>> different "locations" in the code. What I'm wondering is if there is a
>> way
>> to have the compiler automatically determine which type to use depending
>> on
>> its location such as
>>
>> class T
>> {
>> MyUberPointer<int> i;
>> }
>>
>> vs.
>>
>> void func()
>> {
>> myUberPointer<int> i;
>> }
>>
>>
>> so that MyUberPointer uses a copied pointer while myUberPointer uses an
>> auto
>> pointer
>>
>> one might have some policy based parameter so that one could override the
>> default, but in this case the default is "location" dependent. i.e., it
>> would be nice if there was an implicit parameter passed to templates that
>> held the location of its decleration similar to the way the this pointer
>> works... then one could have seperate template definitions depending on
>> the
>> location. Hence one could easily have "polymorphism" of types based on
>> "location". I do know one can easily do this by having some extra
>> parameter
>> such as
>>
>>
>> class T
>> {
>> UberPointer<int,1> i;
>> }
>>
>> vs.
>>
>> void func()
>> {
>> UberPointer<int,0> i;
>> }
>>
>> but ofcourse this isn't the best way.
>>
>>
>> Jon

>
> There's no way to determine the context at compile time that I know of,
> and there probably shouldn't be. IMHO, the latter code *is* actually
> the best way (though not with 1 and 0; meaningful policy names would be
> better) because having the same code behave differently in different
> contexts could easily lead to implicit (read: hard-to-find) bugs.
>
> Cheers! --M
>


Yeah, maybe your right I guess ultimately it could cause more problems
than it would solve and theres probably no case where you really need it.

Jon


 
Reply With Quote
 
Jon Slaughter
Guest
Posts: n/a
 
      10-26-2005

"Victor Bazarov" <(E-Mail Removed)> wrote in message
news:0_N7f.43290$(E-Mail Removed)01.us.t o.verio.net...
> Jon Slaughter wrote:
>> At the bottom of the page on
>>
>> http://ootips.org/yonat/4dev/smart-pointers.html
>>
>> It is noted that one would use different types of pointers based on
>> different "locations" in the code. What I'm wondering is if there is a
>> way to have the compiler automatically determine which type to use
>> depending on its location such as
>>
>> class T
>> {
>> MyUberPointer<int> i;
>> }
>>
>> vs.
>>
>> void func()
>> {
>> myUberPointer<int> i;
>> }
>>
>>
>> so that MyUberPointer uses a copied pointer while myUberPointer uses an
>> auto pointer
>>
>> one might have some policy based parameter so that one could override the
>> default, but in this case the default is "location" dependent. i.e., it
>> would be nice if there was an implicit parameter passed to templates that
>> held the location of its decleration similar to the way the this pointer
>> works... then one could have seperate template definitions depending on
>> the location. Hence one could easily have "polymorphism" of types based
>> on "location". I do know one can easily do this by having some extra
>> parameter such as
>>
>>
>> class T
>> {
>> UberPointer<int,1> i;
>> }
>>
>> vs.
>>
>> void func()
>> {
>> UberPointer<int,0> i;
>> }
>>
>> but ofcourse this isn't the best way.

>
> Why isn't it? Imagine that you want to use an auto pointer inside
> a class or a copied pointer inside a function. What then? Suddenly the
> system (or the compiler) is choosing for you and you seem to have no
> control over the result.


Ofcourse I never said one couldn't override the default.

> Develop a policy template/class and use it.
> First, it's explicit, so you have full control. Second, it's self-
> documenting:
>
> void func()
> {
> UberPointer<int,AutoPointer> i;
> }
>
> class T
> {
> UberPointer<int,CopyPointer> i;
> };
>



Yeah, I guess its probably the better way simply because it makes it
explicit and I suppose there is no case that one could need seperate code
for a class and for a function(local variable). Though I can't see it
causing major problems if the programmer really knows what he is doing but
ofcourse thats a pipe dream

(I did think of the policy based design and thought I mentioned it but I
guess I didn't).

> More on policy-based programming in "Modern C++ Design" and elsewhere.
>
> V


Thanks,
Jon


 
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
[ANN] rcodetools 0.5.0 (TDD++, automagic assertions, 100% accurate completion, doc/code browsing...) Mauricio Fernandez Ruby 4 02-08-2007 10:27 AM
[ANN] rcodetools 0.4.1 (TDD++, automagic assertions, accurate completion, doc/code browsing...) Mauricio Fernandez Ruby 2 01-14-2007 05:23 PM
[ANN] rcodetools 0.4.0: TDD++, automagic assertions, 100% accurate completion, doc/code browsing... Mauricio Fernandez Ruby 4 12-30-2006 07:19 PM
[ANN] xmpfilter 0.3.0: automagic Test::Unit assertions and RSpec expectations Mauricio Fernandez Ruby 1 10-16-2006 10:22 AM
Automagic class prototyping Aleks Kissinger Ruby 6 07-26-2006 09:53 PM



Advertisments