On 7/10/20 1:55 am, Gedare Bloom wrote: > On Mon, Oct 5, 2020 at 4:02 PM Chris Johns <chr...@rtems.org> wrote: >> >> On 5/10/20 6:36 pm, Sebastian Huber wrote: >>> On 03/10/2020 08:23, chr...@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?
I do not know but the names will change. :) I feel we should be OK with editor comments if they are needed. In this case we can avoid them for other reasons. >>> 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. MSVC supports the standard's naming. > 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. I do not know the history to suitably debate the merits. The C++ standards people made this change for C++ as the early versions of C++ such as cfront 3.0 used .h. They may document the reason. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
