Hi,
thank you for your replies. As for your reactions:
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. 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]>
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
>
> 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]> 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]
> > http://lists.modry.cz/listinfo/helenos-devel
> >
>
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
