Larry McVoy <lm(a)mcvoy.com> wrote: |On Wed, Nov 29, 2017 at 08:00:55PM +0100, Steffen Nurpmeso wrote: |> Larry McVoy <lm(a)mcvoy.com> wrote: |>|On Mon, Nov 27, 2017 at 07:06:51PM -0500, Ron Natalie wrote: |>|> 1977 marks my entry into the world of UNIX. I've always stated \ |>|> there was |>|> only one person who truly understood nroff and he was dead. |>|> I mourn the fact that of all the UNIX greats I've met, I missed out on |>|> Ossanna. |> |>|I think one could argue that James Clark has a pretty good handle on |>|roff (having written the GNU version of nroff/troff/tbl/eqn/pic etc). |> |> And Werner Lemberg, who carried the torch for the last almost two |> decades. He brought in some really great improvements, like |> arguments for strings, which allows to write pretty much TeX like |> a.k.a. inline if you want to (as in "this is \*[I talic] text"). | |Yep. James exited stage left and Werner stepped in. I mean no disrespect |to anyone, I was just saying that James has a really good handle on roff, |he redid it all. I admire him for doing so (even though I curse the fact |that he did it in C++). The original source was no free code back then, so he did it for the free and open software world. Thankfully. And i do not know, i mean C++ was in 1989-1992, when he did most of the work as far as i can tell from a shallow look, a class, later template extension layer for plain C, not that overly huge stands-by-itself monster that i call it now. I am absolutely in favour and a of classes and objects, the encapsulation they provide, the method-on-object rather than object-on-function that you have with C. (Multiple) Inheritance including automatic upcasts (to the given parent). Virtual function pointer tables, automatically managed. And "simple" templates. For example, myself, in the process of creating my own fork, can write (globbering the global namespace) color &assign_rgb(rf_ui32 r, rf_ui32 g, rf_ui32 b){ m_scheme = scheme_rgb; return set_red(r).set_green(g).set_blue(b); } color &set_red(rf_ui32 c){ rf_ASSERT(scheme() == scheme_rgb); m_comps[0] = rf_min(c, max_val); return *this; } ... instead of rf_color *rf_color_assign_rgb(rf_color *self, rf_ui32 r, ....){ self->c_scheme = rf_COLOR_SCHEME_RGB; self->c_comps[0] = rf_MIN(r, rf_COLOR_MAX_VAL); ... return self; } and programming all that out over and over again. (Or using macros with side-effects. Or relying on inline functions.) And that is a simple object with a short name. References are unfortunate in my opinion, but you will not see any light if you try doing C++ without them because they are omnipresent for core functionality like standard copy constructors etc. Like many other things, including the complete departure from an underlaying C standard. C++03/C99 or so i would have appreciated. But as long as -fno-rtti -fno-exceptions is possible i can somehow live with it. (Let aside the fact that i have to live with it no matter what bloat the C++ standard introduces next.) And then C is not what it was no more, too, and unfortunately the usage-makes-fun guideline from what Plan9 documents and extends onto ISO C89 was not what the ISO C people looked at when they did. Well. Maybe if he would have known what C++ ends up as he would have used C instead? That would be an interesting question. Myself i currently appreciate coming back to a C++ codebase, however, because thinking in objects is my personal way of dealing with programming, that is how i really got used to it, anyway. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)