Date: Sun, 30 Apr 2023 23:37:22 -0700
This seems to work.
https://wandbox.org/permlink/AxbjJtysQDG1AuaS
Excerpt:
#include <vector>
template<class t>
concept win = true;
namespace std {
template<win t, win a>
class vector<t, a> {
public:
void found_our_own() {}
};
}
On Sun, Apr 30, 2023 at 10:23 PM Jayesh Badwaik via Ext <
ext_at_[hidden]> wrote:
> > In many places the computer, compiler, and tool use is determined by
> the professor - and despite our efforts, many professors prefer older tool
> chains with which they are familiar, usually what they get "right out of
> the box" or a "teching environment" in which it is hard to add new
> components.
>
> We can distribute compilers which are easy to install. Something similar
> to `rustup` here https://rustup.rs/cwhere you can install the compiler
> you need for your system with a single command.
>
> I have been testing out such a system here: https://gitlab.com/cupstack/
> Where installing a compiler is as simple as
> `cupstack.sh --compiler $COMPILER --version $VERSION --prefix
> $ABS_TMP_DIR/opt/cupstack`.
>
> That would incentives teacher to use latest version of compilers..
>
>
>
> On Mon, 1 May 2023, 00:09 Bjarne Stroustrup via Ext, <ext_at_[hidden]>
> wrote:
>
>> Contracts will not arrive any day soon and remember that not all students
>> have access to the latest compilers and the latest tools.
>>
>> In many places the computer, compiler, and tool use is determined by the
>> professor - and despite our efforts, many professors prefer older tool
>> chains with which they are familiar, usually what they get "right out of
>> the box" or a "teching environment" in which it is hard to add new
>> components. Many also prefer to teach an older style of C++. That's what
>> I'm up against. I always have problems with getting people to use a
>> "non-standard" header file, even when that header contains nothing
>> non-standard. Setting options is often a no-no. Note that this can be
>> reasonable. It is hard to teach a couple of hundred students using a couple
>> of dozen different tool chains. I have done it. It is hard, and we can't
>> impose that on everybody.
>>
>> Range-checking compiler options are great. I recommend them, but they are
>> not standard and setting options is difficult for some students.
>>
>> Part of the problem is that some students have never written a line of
>> code in their lives, for some their "coding" experience is radically
>> different from C++ (mine-craft anyone?), and some absolutely freeze in
>> terror when faced with a command window. A crash without an error message
>> is very hard for a student to cope with in the first couple of weeks. Not
>> all debuggers can be described as novice friendly.
>>
>> Part of the problem is scale. I'm not talking abut me teaching a dozen
>> students. I'm thinking of dozens or hundreds of courses taught be teachers
>> and TAs with varying backgrounds,with an aggregate of thousands of
>> students, and an approach and support text that might be used several years
>> from now.
>>
>> Just FYI: this has worked for more than a decade; not perfectly, of
>> course, but with a reasonable degree of success.
>>
>>
>> On 4/30/2023 12:50 PM, Andrew Tomazos via SG20 wrote:
>>
>> On Mon, May 1, 2023 at 2:15 AM Gabriel Dos Reis via Ext <
>> ext_at_[hidden]> wrote:
>>
>>> Ideally, students should be taught practices they can deploy in
>>> production setting. While sanitizers and fuzzers have become accepted
>>> elements of the dev toolbox, they can't be deployed in production. That is
>>> part of why it is critical that we have a standard mechanism for turning
>>> bound checking on - or better yet, have bound checking on by default and
>>> have mechanism to opt out, after profiling data have shown that's what is
>>> needed.
>>>
>>
>> If/when we ship contracts, aren't we going to eventually add them to the
>> standard library to check preconditions? and bounds-checking of the
>> standard containers would be amongst them? Isn't turning contracts
>> on-and-off exactly that standard mechanism to turn bounds checking
>> on-and-off? Or are we talking about bound-checking at the lower
>> builtin-array level?
>>
>>
>> _______________________________________________
>> Ext mailing list
>> Ext_at_[hidden]
>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
>> Link to this post: http://lists.isocpp.org/ext/2023/04/21189.php
>>
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
> Searchable archives: http://lists.isocpp.org/ext/2023/05/index.php
>
https://wandbox.org/permlink/AxbjJtysQDG1AuaS
Excerpt:
#include <vector>
template<class t>
concept win = true;
namespace std {
template<win t, win a>
class vector<t, a> {
public:
void found_our_own() {}
};
}
On Sun, Apr 30, 2023 at 10:23 PM Jayesh Badwaik via Ext <
ext_at_[hidden]> wrote:
> > In many places the computer, compiler, and tool use is determined by
> the professor - and despite our efforts, many professors prefer older tool
> chains with which they are familiar, usually what they get "right out of
> the box" or a "teching environment" in which it is hard to add new
> components.
>
> We can distribute compilers which are easy to install. Something similar
> to `rustup` here https://rustup.rs/cwhere you can install the compiler
> you need for your system with a single command.
>
> I have been testing out such a system here: https://gitlab.com/cupstack/
> Where installing a compiler is as simple as
> `cupstack.sh --compiler $COMPILER --version $VERSION --prefix
> $ABS_TMP_DIR/opt/cupstack`.
>
> That would incentives teacher to use latest version of compilers..
>
>
>
> On Mon, 1 May 2023, 00:09 Bjarne Stroustrup via Ext, <ext_at_[hidden]>
> wrote:
>
>> Contracts will not arrive any day soon and remember that not all students
>> have access to the latest compilers and the latest tools.
>>
>> In many places the computer, compiler, and tool use is determined by the
>> professor - and despite our efforts, many professors prefer older tool
>> chains with which they are familiar, usually what they get "right out of
>> the box" or a "teching environment" in which it is hard to add new
>> components. Many also prefer to teach an older style of C++. That's what
>> I'm up against. I always have problems with getting people to use a
>> "non-standard" header file, even when that header contains nothing
>> non-standard. Setting options is often a no-no. Note that this can be
>> reasonable. It is hard to teach a couple of hundred students using a couple
>> of dozen different tool chains. I have done it. It is hard, and we can't
>> impose that on everybody.
>>
>> Range-checking compiler options are great. I recommend them, but they are
>> not standard and setting options is difficult for some students.
>>
>> Part of the problem is that some students have never written a line of
>> code in their lives, for some their "coding" experience is radically
>> different from C++ (mine-craft anyone?), and some absolutely freeze in
>> terror when faced with a command window. A crash without an error message
>> is very hard for a student to cope with in the first couple of weeks. Not
>> all debuggers can be described as novice friendly.
>>
>> Part of the problem is scale. I'm not talking abut me teaching a dozen
>> students. I'm thinking of dozens or hundreds of courses taught be teachers
>> and TAs with varying backgrounds,with an aggregate of thousands of
>> students, and an approach and support text that might be used several years
>> from now.
>>
>> Just FYI: this has worked for more than a decade; not perfectly, of
>> course, but with a reasonable degree of success.
>>
>>
>> On 4/30/2023 12:50 PM, Andrew Tomazos via SG20 wrote:
>>
>> On Mon, May 1, 2023 at 2:15 AM Gabriel Dos Reis via Ext <
>> ext_at_[hidden]> wrote:
>>
>>> Ideally, students should be taught practices they can deploy in
>>> production setting. While sanitizers and fuzzers have become accepted
>>> elements of the dev toolbox, they can't be deployed in production. That is
>>> part of why it is critical that we have a standard mechanism for turning
>>> bound checking on - or better yet, have bound checking on by default and
>>> have mechanism to opt out, after profiling data have shown that's what is
>>> needed.
>>>
>>
>> If/when we ship contracts, aren't we going to eventually add them to the
>> standard library to check preconditions? and bounds-checking of the
>> standard containers would be amongst them? Isn't turning contracts
>> on-and-off exactly that standard mechanism to turn bounds checking
>> on-and-off? Or are we talking about bound-checking at the lower
>> builtin-array level?
>>
>>
>> _______________________________________________
>> Ext mailing list
>> Ext_at_[hidden]
>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
>> Link to this post: http://lists.isocpp.org/ext/2023/04/21189.php
>>
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
> Searchable archives: http://lists.isocpp.org/ext/2023/05/index.php
>
Received on 2023-05-01 06:37:35