[PATCH v4] cpukit/librcxx: Add a C++ thread interface with attributes

[Gedare Bloom]

On Mon, Oct 5, 2020 at 4:02 PM Chris Johns <chrisj at rtems.org> wrote:
>
> On 5/10/20 6:36 pm, Sebastian Huber wrote:
> > On 03/10/2020 08:23, chrisj at rtems.org wrote:
> >
> >> diff --git a/cpukit/include/rtems/c++/error b/cpukit/include/rtems/c++/error
> >> new file mode 100644
> >> index 0000000000..8b9d875e0f
> >> --- /dev/null
> >> +++ b/cpukit/include/rtems/c++/error
> >> @@ -0,0 +1,65 @@
> >> +/* -*- C++ -*-
> >> + * SPDX-License-Identifier: BSD-2-Clause
> >> + *
> >> + * Copyright (C) 2020 Chris Johns (http://contemporary.software)
> >> + *
> >> + * Redistribution and use in source and binary forms, with or without
> >> + * modification, are permitted provided that the following conditions
> >> + * are met:
> >
> > Could you please use the new file template:
> >
> > https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#c-c-header-file-template
> >
>
> Sure.
>
> > Do we really need editor-specific comments in the header files?
>
> Does it matter?
>

That depends. Is the filetype comment embedding standardized across
common editors?

> > Maybe just use a *.h or *.hpp header file name?
>
> The file namea are inline with the names C++ uses.
>

This is related. For example, Windows does not do well with
extensionless filenames. Neither do humans. It makes us have to guess
unless we open with our tools. I get that the C++ committee likes the
#include <something> without the .h/.hpp/.* but I find it annoying. I
also won't find these files with
find . -name "*.h*"
or any kind of regex for that matter. I'm not convinced about these
extensionless filenames at all.

> Chris
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel