Hi Jiri, I was talking about a specific implementation, namely libc++. If you check, e.g., the https://github.com/llvm-mirror/libcxx/blob/master/include/cstdlib header, you can see that they include <stdlib.h> and then in namespace std import it's symbols using the keyword "using". (The <stdlib.h> itself is a wrapper that does the C linkage declaration.) This way, when you include <cstdlib>, you will have both global namespace and std namespace versions of every symbol.
What I did is basically what you just suggested, I placed the include itself in namespace std and thus every symbol is imported only into this namespace :) What Linux (and other) does (#ifdef __cplusplus) is non-standard, but convenient and fairly trivial to implement (I didn't want to invade libc and was thus thinking about having <helenos/cloc> instead of <loc.h> and import it into namespace ::hel or something like that, but either is possible and easy to do). S pozdravem, Jaroslav Jindrak On 11 October 2017 at 12:06, Jiri Svoboda <[email protected]> wrote: > 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]> > 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 > > > _______________________________________________ > 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
