Hi Jaroslav,
first, thank you for involving us, the community! That's what we'd love to
see with all the student projects (but most often is not the case). Of
course the only authority for your thesis is you and M.D. All we can/try to
give you is advice on what we'd like to see - so that we can get the most
out of your work. So thank you!
We, as the community, love to support you as much as we can. Please find my
comments below.
I've been following your launchpad branch. Thank you for posting your code.
I would also like to note that I love reading thesis drafts. I am quite
capable of reviewing both HelenOS-related content and English spelling/
grammar. So once you have some draft of (parts) of the thesis, if you send
them my way, I'm more than happy to review. [Please send early, not 48 hours
before submitting :-)]
Cheers and best regards,
Jiri
6. Questions & thoughts
=======================
6.1 Standard API compatibility?
===============================
Since HelenOS uses the "not using old/bad APIs" doctrine, do we want
to change the API like in the C library or shall we use the C++ standard
wherever possible and suitable?
-----------------------------
HelenOS libc *should* provide
- ISO C standard APIs
- our own OS-specific or alternative APIs, as long as they don't conflict
libposix should complement those with UNIX/GNU/POSIX extras
I would expect the C++ library to provide ISO C++ standard APIs. It should
be optionally possible to use the C++ lib + libposix to help port C++
applications from Linux that expect UNIX-like functionality on top of C++
standard.
6.2 Parts of vs. whole stdlib?
==============================
My idea was to find the best implementation to port and to port as much
as we can (without making the process too easy :), however, picking parts
of different implementations is possible too, though it would increase the
complexity of the project due to different macros etc. the implementations
use (+ it would be quite inconsistent). If libc++ is the only viable
option (like it seems to me right now seeing as libstdc++ is GPL and
the other implementations are old/no longer developed) this question
becomes irrelevant and we would simply port everything from it directly.
----------------------
My preference would be either have a completely new implementation written
from scratch
or to have a port of one existing library that has very simple changes from
the original
(i.e. to make syncing with upstream changes as simple as possible).
These two variants are optimal from a maintainability perspective.
If you are porting code, preferred licenses are BSD style or MIT style.
6.3 Libposix vs. native API?
============================
As far as I know libposix is just for initial ports of applications
and Vojta is thinking abour rewriting it, so I assume using the
HelenOS native C API would be preferable? (This also ties to the
<c*> headers, which wrap the C library - shall we use native API?)
------------------------------
Ideally you'd have both. If you want to choose one, I'd say libposix
environment makes more sense. Since the purpose of C++ library is
to port applications to HelenOS, not write native code,
they will most likely also need libposix (or am I wrong?)
6.4 Mainline or coastline?
==========================
Where would libcpp be? I'm asking because of the potential
license conflicts with the existing C++ stdlibs listed in section 5.
-----------------
Depends on whether it's a ground up implementation or
port.
6.5 Version of the standard?
============================
My thoughts were to first aim for C++11 standard so that we don't
have parts of C++11, C++14 and C++17 and the implementation can be
considered complete in the context of the standard (i.e. a specific
version of it). Is that feasible thinking?
Note that by this I don't mean the ported stuff (it would be stupid
to discard parts of the ported library :), but the stuff that would be
written from scratch - is there a pool for optional work similarly to
the software project (i.e. if we have enough time we'd implement this
newer functionality)?
---------
Not going to answer this one
6.6 Copying files
=================
Some implementations (e.g. libc++) include conditionally compiled
code (#ifdef WIN, ...). Since these are completely irrelevant to us,
should we remove all of them? This would mean that HelenOS versions
of those files would be incompatible with the upstream, however that
is already caused if we use its native API.
-------------------
Ideally the code would be split to newly written files and existing code
with minimum changes. Then obviously you don't remove these from mostly
unmodified files.
6.7 Demonstrator
================
I was trying to find a suitable demonstrator C++ program (mostly on github),
however most suitable programs use 3rd party libraries or are very limited
in their scope (e.g. just vector/map, IO and language builtins) and don't
seem
to cover much of the standard. Would writing an artificial application for
this
(or even a set of unit tests) be suitable?
-----------------
Unit tests would be great.
Artificial application - well you probably want something to demonstrate for
your thesis defense. An existing application would probably look best.
If that's complicated, not sure, maybe either a simple command line tool
(think cp)
or a very simple GUI application (think Xeyes)?
6.8 Compilers
=============
In my implementation, I modified the build system (primarily tools/autotool.
py)
to use the GNU C++ compiler and disregarded clang/native/etc. as lower
priority
goal (as I assume most people compile HelenOS with gcc). Are these other
compilers
still maintained (i.e. should I somehow implement those too)?
----------------------------------
Clang should work for ia32/amd64. But I think supporting GCC and Clang is
quite
a lofty goal.
6.9 C++ Style
=============
After already writing several files in the library, I noticed that my
HelenOS
vim settings only apply to C, not C++ (e.g. the library contains expanded
tabs
with width of 4 spaces) and out of habit I used my C++ coding style. I can
refactor
this with little to no effor, however if we decide to go with libc++, which
uses
a coding style that is very similar to my own, wouldn't it be smarter to
just
have the entire library unified under this coding style (which would then
differ from most of HelenOS C code - but would be 100% consistent with
HelenOS C++ code :)?
--------------------
If you try to port a third-party library with minimum changes, it probably
doesn't make sense to try an enforce Helenos C style on it.
6.10 Libc wrappers
==================
While several C++ standard C headers are missing from HelenOS, the HelenOS
native API provides a plethora of additional headers. Do we want those
included?
It would mean they would be available in C++ with C linkage in the form of
<cexample> if they are names <example.h>. If so, all of them? Or should we
cherry pick (e.g. a poll amongst the HelenOS devs)?
-----------------
Does Linux or any other OS provide something similar?
---------- Původní e-mail ----------
Od: Jaroslav Jindrák <[email protected]>
Komu: Martin Decky <[email protected]>
Datum: 10. 10. 2017 16:09:37
Předmět: [HelenOS-devel] [HelenOS] C++ Port Thesis
"
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
