First off. Kudos! Your idea of implementing a variant type as a set of related "concept representative types" is amazing and I look forward to using it. I can't wait until "concepts" become an official part of the c++ standard. A full set of your "concept representative types" should probably join them!
So far I've just started playing with "any_regular_t", "regular", and "poly<regular>" and had a few questions:</regular>
1) The tutorial on any_regular_t says that we can assign to it from any regular type for example:
adobe::regular my_value;
my_value = 4;
However, I get the following compiler error on g++ 4.4.3 and 4.6.3 with the latest ASL 1.0.43:
test.cpp: In function âint main()â:
test.cpp:21: error: no match for âoperator=â in âmy_value = 4â
/data/cmda/afsd/chm/adobe_root/adobe_source_libraries/adobe/poly_regular.hpp:85: note: candidates are: adobe::regular& adobe::regular::operator=(const adobe::regular&)
I can obviously work around this by doing:
my_value = adobe::regular(4);
or
my_value.assign(4);
Is this on purpose or are there plans to overload operator= for any type T somewhere (basically just the "assign" function" anyway)? Or am I forgetting to include something?
My example is with "adobe::regular" but I get the same message from "any_regular_t" as well.
2) I don't understand the reason for having the poly< > wrapper class. Is it just to hide the implementation details of poly_base? Is it really needed? Can I just use the handle classes "regular", "copyable", "serializable" etc. directly instead?
3) I was also curious why the constructors that accept any type are explicit? Wouldn't they be more convenient to use if implicit conversions were allowed? Did you run into some cases where implicit conversion became a problem?
Thanks for any help you can give.
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The poly wrapper supports the construction of richer (non-intrusive)
runtime polymorphic interfaces than simply Regular or Copyable. One example
in the platform libraries is the poly Placeable concept, which requires a
measure() operation. See, for example:
On Sat, Nov 16, 2013 at 11:14 AM, Christophe Malek malekc@users.sf.netwrote:
...
2) I don't understand the reason for having the poly< > wrapper class. Is
it just to hide the implementation details of poly_base? Is it really
needed? Can I just use the handle classes "regular", "copyable",
"serializable" etc. directly instead?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-11-24
Hi Mat,
Thanks for replying to my 2nd question. However, I'm still not entirely sure I understand the "poly" wrapper's function. The richer placeable interface can also be called directly from its handle class "placeable" instead of using poly<placeable> or poly_placeable_t. I assume it is to provide the non-intrusiveness you mentioned.</placeable>
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On Sat, Nov 16, 2013 at 11:14 AM, Christophe Malek malekc@users.sf.netwrote:
First off. Kudos! Your idea of implementing a variant type as a set of
related "concept representative types" is amazing and I look forward to
using it. I can't wait until "concepts" become an official part of the c++
standard. A full set of your "concept representative types" should probably
join them!
So far I've just started playing with "any_regular_t", "regular", and
"poly" and had a few questions:
1) The tutorial on any_regular_t says that we can assign to it from any
regular type for example:
adobe::regular my_value;
my_value = 4;
However, I get the following compiler error on g++ 4.4.3 and 4.6.3 with
the latest ASL 1.0.43:
test.cpp: In function âint main()â:
test.cpp:21: error: no match for âoperator=â in âmy_value = 4â
/data/cmda/afsd/chm/adobe_root/adobe_source_libraries/adobe/poly_regular.hpp:85:
note: candidates are: adobe::regular& adobe::regular::operator=(const
adobe::regular&)
I can obviously work around this by doing:
my_value = adobe::regular(4);
or
my_value.assign(4);
Is this on purpose or are there plans to overload operator= for any type T
somewhere (basically just the "assign" function" anyway)? Or am I
forgetting to include something?
My example is with "adobe::regular" but I get the same message from
"any_regular_t" as well.
At one point I made everything explicit - I don't recall now if it was to
resolve a particular issue or more likely because I was on a "make
everything explicit binge". I'll open an issue to put it back.
2) I don't understand the reason for having the poly< > wrapper class. Is
it just to hide the implementation details of poly_base? Is it really
needed? Can I just use the handle classes "regular", "copyable",
"serializable" etc. directly instead?
3) I was also curious why the constructors that accept any type are
explicit? Wouldn't they be more convenient to use if implicit conversions
were allowed? Did you run into some cases where implicit conversion became
a problem?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-12-04
Thanks Sean! I understand the urge to make everything explicit, I must admit that implicit conversions make me a little nervous too but hopefully they are for the best. Fingers crossed. :)
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First off. Kudos! Your idea of implementing a variant type as a set of related "concept representative types" is amazing and I look forward to using it. I can't wait until "concepts" become an official part of the c++ standard. A full set of your "concept representative types" should probably join them!
So far I've just started playing with "any_regular_t", "regular", and "poly<regular>" and had a few questions:</regular>
1) The tutorial on any_regular_t says that we can assign to it from any regular type for example:
adobe::regular my_value;
my_value = 4;
However, I get the following compiler error on g++ 4.4.3 and 4.6.3 with the latest ASL 1.0.43:
test.cpp: In function âint main()â:
test.cpp:21: error: no match for âoperator=â in âmy_value = 4â
/data/cmda/afsd/chm/adobe_root/adobe_source_libraries/adobe/poly_regular.hpp:85: note: candidates are: adobe::regular& adobe::regular::operator=(const adobe::regular&)
I can obviously work around this by doing:
my_value = adobe::regular(4);
or
my_value.assign(4);
Is this on purpose or are there plans to overload operator= for any type T somewhere (basically just the "assign" function" anyway)? Or am I forgetting to include something?
My example is with "adobe::regular" but I get the same message from "any_regular_t" as well.
2) I don't understand the reason for having the poly< > wrapper class. Is it just to hide the implementation details of poly_base? Is it really needed? Can I just use the handle classes "regular", "copyable", "serializable" etc. directly instead?
3) I was also curious why the constructors that accept any type are explicit? Wouldn't they be more convenient to use if implicit conversions were allowed? Did you run into some cases where implicit conversion became a problem?
Thanks for any help you can give.
The poly wrapper supports the construction of richer (non-intrusive)
runtime polymorphic interfaces than simply Regular or Copyable. One example
in the platform libraries is the poly Placeable concept, which requires a
measure() operation. See, for example:
http://stlab.adobe.com/structadobe_1_1placeable.html
http://www.emarcus.org/#mpool_2007
http://www.emarcus.org/#gpce_2007
On Sat, Nov 16, 2013 at 11:14 AM, Christophe Malek malekc@users.sf.netwrote:
...
Hi Mat,
Thanks for replying to my 2nd question. However, I'm still not entirely sure I understand the "poly" wrapper's function. The richer placeable interface can also be called directly from its handle class "placeable" instead of using poly<placeable> or poly_placeable_t. I assume it is to provide the non-intrusiveness you mentioned.</placeable>
On Sat, Nov 16, 2013 at 11:14 AM, Christophe Malek malekc@users.sf.netwrote:
At one point I made everything explicit - I don't recall now if it was to
resolve a particular issue or more likely because I was on a "make
everything explicit binge". I'll open an issue to put it back.
Thanks Sean! I understand the urge to make everything explicit, I must admit that implicit conversions make me a little nervous too but hopefully they are for the best. Fingers crossed. :)