Hi Jaroslav,
"
1) Libposix vs native
The C++ standard cites multiple (but not all) ISO C headers. One of the
ideas I had was to have the ones included
in the standard as they are now (in the root include directory as <c*>
headers) and the rest (ipc, fibrils, ...) in an
include/helenos directory (again as <c*>). This would allow us to include
them directly, because otherwise we would
have to use:
extern "C" {
#include <native_header>
}
every time we'd need this functionality.
"
That's incorrect. You can use either <stdlib.h> or <cstdlib> from a C++
program (on real implementations, at least, not sure about the standard),
but the difference is that if you use <stdlib.h>, the symbols won't be
inside a namespace. If you use <cstdlib>, the symbols will be placed in the
"::std" namespace.
With Linux system headers you can use them directly, again (because they
themselves contain #ifdef _cpp extern "C" { #endif guards) and the symbols
won't be inside a namespace.
Clearly you need to do what's mandated by the standard (cxyz wrappers for
xyz.h headers with ::std namespace) for the headers enumerated by the
standard. For HelenOS specific headers you can obviously
do what you want.
I suggest it does not make sense to have a two sets of headers. And we don't
care about backward compatibility (namespaces vs no namespaces). We could
make libc headers compatible with C++ and since we're not bound with
backward compatiblity, we can export the symbols in an appropriate
namespace, if we wish.
So, for example, if you wanted to use the location service, you could just
include <loc.h> from C++ and get the symbols inside some ::xx::yy namespace.
Is that a good idea? What should the namespace name be like? I don't know,
I'm not a C++ guy. Maybe you should research some OS written in C++ such as
Haiku (or even consult Haiku developers) to get some inspiration.
As far as dependency, because ideally libc should implement the standard and
libposix should just forward it, you should be able to use one or the other.
In reality this does not work. For example, libc is missing scanf family of
functions. There is a scanf family implementation in libposix, but it's very
ugly and I suggest against moving it to libc as it is (which would be
difficult, anyway).
Best regards,
Jiri
"
I will have to research libposix a little bit more (at the moment
libposix is an alias to magic for me :), but it should be possible (atleast
for the standard headers) to use the same
libposix macro in makefiles (seeing as the linkage would be specified in the
<c*> headers and the rest should be
identical to linking it in C). Luckily, I opted to not include the headers
into the global namespace and then one by
one use them (using ::NAME) them in the std namespace which does not bound
us to specific API (well, it binds
the application using it, but the libcpp wrapper headers should be usable in
both ways). To be honest I'm not really
sure why libc++ decided to do this as they include the symbols twice in the
global and std namespaces this way.
As for the question asked by JiriS to my section 6.10: As far as I know, it
does not, because the actual inclusion
of C in C++ really only needs extern "C" {} around the include - the C++
standard provides those <c*> headers mostly for
convenience (and consistence, as C++ standard headers lack an extension).
2) Porting
Originally when I came to MD to discuss the posibility of writing this
thesis, I intended to write the entire
standard library from scratch (the main reason for choosing this topic was
because I wanted to write the
standard library and have a use for that implementation :), but as MD
pointed out, some stuff like containers
and algorithms are mostly template based and would be redundant to implement
them from scratch
(given the limited amount of time I have for this thesis).
However, one idea I was coining in my head since after that discussion was
to implement the non-STL stuff
from scratch in libcpp (which would allow us to include it in the mainline)
and port the STL in a separate
library that would be part of coastline - and possibly do something similar
to what libustl has done:
provide alternative implementations from scratch for containers which would
meet the standard API but
would be implemented in a simplified manner (e.g. stubs, containers
implemented over vector etc.) and
leave the actual implementation of these modules for a post-thesis time.
(The idea is that programs would
work without using the libc++ STL from coastline, albeit at e.g. worse
speed.)
3) Demonstrator
I was mostly meaning what I wrote in the type of if there is a C++ program
that would really stretch the
library (i.e. use most of its features) it tends to be very 3rd party
dependend. However, your answer gave me
the idea of choosing multiple smaller programs (and no, I don't know why I
didn't think of it before :) that
demonstrate different parts of the library (+ unit tests).
4) Compilers
Supporting clang should not be that hard as far as I'm not concerned, cross-
g++ is already bundled
in the toolchain script, but adding cross-clang++ should not be a problem
(assuming it's not already
downloaded by the script) and luckily for as (again, afaik) clang++ should
be fully compatible with
g++ expectations of the C++ runtime (clang defaults to it on Linux). I only
mentioned that because
the I'm not very versed in the matter of HelenOS build system (and even the
working of autotool.py,
I hacked the cross-g++ into the parts where cross-gcc is defined for
generated makefiles), but now
that I progressed a bit (that part was written earlier when adding cross-g++
seemed super hard), it
doesn't seem that complicated to do.
5) C++ coding style
I was asking more in the way of the stuff written from scratch using more C+
+ coding style, example:
In HelenOS cstyle, pointers should be declared as follows:
char *c;
However, in modern C++ the (generally, not by all) followed style is (e.g.
used in libc++):
char* c;
Which is because the C style is used for declaring multiple variables at the
start of a function:
char c, *cptr1, cc, *cptr2;
Which is potentially problematic in C++ as simple declaration (and with
default constructor a definition)
can have side effects (constructors).
6) Libc++ vs libstdc++
Since BSD/MIT is more preferred, libc++ would probably be better as it is
licensed under both and
libstdc++ is licensed under GPL. Plus, libc++ has much, MUCH better source
code (i.e. more readable,
with better formatting and mainly more consistent - libstdc++ mixes many
coding styles together).
Also, thanks for the link jzr, that one should come in very handy :)
(Additionally, I'm a huge clang/llvm/libc++ fan!)
Again, thank you very much for your input :)
S pozdravem,
Jaroslav Jindrak
On 10 October 2017 at 17:37, Jiří Zárevúcky <[email protected]
(mailto:[email protected])> wrote:
"Hello Jaroslav!
Nice to see someone working on this, and thanks for linking in the ML.
I can help answer some of the questions.
The state of HelenOS libc and libposix is far from ideal, and it's going to
keep evolving in the coming months. Ideally, libc should eventually be
compatible with C and C++ standard (if not outright compliant), and
at the very least not have outright conflicts with the POSIX standard.
Insofar as a subset of C++ library can be viewed as a wrapper for C
library, I think it would be adequate for that subset's completeness to
match what's implemented in libc and/or libposix. If you think a part
of C standard library is needed for your work to be successful, it should be
implemented in libc first (and I'll be happy to review and possibly
integrate your work).
When it comes to particular implementation, I'd personally prefer
LLVM's libc++. You should refrain from using GPL-licenced code,
but BSD and MIT are fair game (so long as you follow their
requirements). I'm not entirely sure about Apache.
Also, this page might come in handy:
https://clang.llvm.org/docs/Toolchain.html
(https://clang.llvm.org/docs/Toolchain.html)
It's in the best interest of maintainability to keep changes from
upstream code to a minimum. For example, conditional sections
should not be removed unless it's necessary, and it might be
better to provide pthreads API implemented using fibrils, than
to change the caller directly. Currently, libposix has empty stubs
for pthread API, but having a fibril-backed libpthread as a
separate library is something I'd like to have.
For compiler support, I'm currently reviving clang (see my latest
commits to mainline), so if possible, you should strive to support
cross-gcc and clang. You can safely ignore everything else.
Last, but not least, I'm available most afternoons/evenings on
our IRC channel, so I invite you to pop in anytime and ask any
questions. My nickname on IRC is jzr.
-- jzr
On 10 October 2017 at 16:06, Jaroslav Jindrák <[email protected]
(mailto:[email protected])> wrote:
> Hi Martin,
>
> I'm sending you a research/progress file I've written so far that
documents
> my progress.
> It includes information on the things I have already done, possible
porting
> sources, discussion
> of the portability of the different modules (i.e. standard headers) and
> section 6 contains a few
> questions I wanted to ask you (mostly regarding the direction you'd like
> this thesis to take - if you
> do have preference).
>
> PS. Since HelenOS is a community project, I decided to CC the helenos-
devel
> mailing list in the
> case somebody else would be interested (or would want to voice their
> preference in the matters
> discussed). (Although I'm not sure how that'd be incorporated into the
> thesis.)
>
> If you prefer to meet in person to discuss this, let me know and I'll come
> to MS.
>
> S pozdravem,
> Jaroslav Jindrak
>
> _______________________________________________
> HelenOS-devel mailing list
> [email protected](mailto:[email protected])
> http://lists.modry.cz/listinfo/helenos-devel
(http://lists.modry.cz/listinfo/helenos-devel)
>
"
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
"_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
