First a correction: we get the database information via the
configuration or the db_traits.
template<typename T>
struct something
{
using database = typename db_traits<T>::database;
};
Second the implementation guard idea: I need more time for a feedback.
I hesitate to say this or that is on my wishlist, because the degree of
importance isn't clear enough for me. Perhaps I can help to avoid an
"ex falso quodlibet" effect regarding the interpretation of c++ features.
Regards, matthias
Am 04.07.20 um 00:15 schrieb gmhwxi:
>>I would say traits are type properties
I like your description :)
######
Let me use some pseudo code to illustrate a kind of support for traits
that can be quickly implemented for ATS3.
Say we have a template:
#extern
fun
<a:type>
foo(x: a): void
And we have two different implementations for foo:
impltmp
{a}
foo(x) = (* first *)
impltmp
<a>
foo(x) = (* second *)
Now we have two instances of foo in our code:
val () = foo<int>(100)
val () = foo<string>("100")
Say that the first instance should use the first implementation of foo
and the second instance should use the second implementation of foo.
To achieve this, we could introduce a trait called FOO2 for the second
implementation:
impltmp
<a>
FOO2(a) => foo(x) = (* second *) // the pseudo syntax means that this
implementation is guarded by FOO2(a)
Let FOO2 be given the following implementations:
impltmp
{a:type}
FOO2<a> = true
impltmp
FOO2<int> = false
To compile the instance foo<int>, the second implementation is first
picked; but the guard FOO2<int> is false;
so this implementation is skipped and the first implementation is
picked next.
######
Using traits for constructing guards is a low-hanging fruit. We could
certainly think of ways for traits to be used to
guide template resolution in a more profound manner.
--Hongwei
On Friday, July 3, 2020 at 4:29:29 PM UTC-4, Matthias Wolff wrote:
C++ Term Traits:
I would say traits are type properties
struct oracle;
struct postgres;
template<typename T>
void print_database(T t /* value only for type deduction --
avoiding explicit <>*/)
{
/*Type resolution: database is unknown at this stage, database
is a dependend type, but type dependend */
if constexpr (is_same<typename T::database,oracle>::value) {
cout << "oracle" << endl; return; }
else if constexpr (is_same<typename
T::database,postgres>::value) { cout << "postgres" << endl; return;}
else { static_assert("Unsupported type"); }
}
struct abc
{
};
struct def
{
};
template<typename T>
struct db_traits;
template<>
struct db_traits<abc>
{
using database = oracle;
};
template<>
struct db_traits<def>
{
using database = postgres;
};
template<typename T>
struct something
{
using database = typename T::database;
};
int main()
{
something<abc> s;
print_database(s);
return 0;
}
Typetraits are lightweight information because the implementations
of the types/structs/classes
are not of interest. Types are only names in this context.
Remark: Generic programming is like any abstraction if only one
example is available.
It makes things more complicated. But looking on universal
properties it's clear it needs
a bunch of examples to get a benefit. So many developers can live
without it. But everyone
will try it - the "feature" effect.
C++ term concepts:
It's relatively new, available since C++-20. It an improvement in
the area specification of
templated constructions. Typically, in the C++ world it's
forbidden to use a mathematical
vocabulary. Make better specifications seems to be the goal. I
have no personal experiences.
Remark2: C++ concepts is an additional feature but not a concept.
The world of C++ scientists
is restricted by C++. It's more a (distinct) feeling: replace
concepts by ats-proofing.
Be sure, other c++ developers will tell you other things.
Am 03.07.20 um 20:10 schrieb gmhwxi:
Traits:
Based on my understanding, traits in C++ can be implemented in a
more or less
straightforward manner. To me, traits are an template-based
approach for generating
ifdef-guards used in C.
However, I would prefer to take a deeper look at the template
resolution algorithm. Traits are
a bit like band-aid used at surface. One can expect to achieve a
lot more if there is a logical way
to affect the manner in which template code is replaced with
non-template code.
Concepts:
It is a feature mainly for statically debugging templates. I am
looking into it. Debugging templates
statically is a big thing; I prefer something with clearer
semantics. Let's wait and see.
--
You received this message because you are subscribed to the
Google Groups "ats-lang-users" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/337ff3b2-40ed-43cc-9e0f-d62cfa6e4a42o%40googlegroups.com
<https://groups.google.com/d/msgid/ats-lang-users/337ff3b2-40ed-43cc-9e0f-d62cfa6e4a42o%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "ats-lang-users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/556bda1e-a680-4a87-aeb4-7b023c8d9714o%40googlegroups.com
<https://groups.google.com/d/msgid/ats-lang-users/556bda1e-a680-4a87-aeb4-7b023c8d9714o%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"ats-lang-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/150bb718-e3b8-85b9-811f-16adafcb15f1%40bejocama.de.
