Boost logo

Boost :

Subject: Re: [boost] [Experimental Boost.DI] [v1.0.0 released] [Looking for a Review Manager] Your C+14 Dependency Injection library with no overhead and compile time creation guarantee!
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-02-24 10:31:10


On Wednesday, February 24, 2016 at 6:39:52 AM UTC-6, Krzysztof Jusiak wrote:
>
> On Tue, Feb 23, 2016 at 10:23 PM, Andrey Semashev <andrey...._at_[hidden]
> <javascript:>
> > wrote:
>
> > On Tue, Feb 23, 2016 at 10:19 PM, Steven Watanabe <watan..._at_[hidden]
> <javascript:>>
> > wrote:
> > > AMDG
> > > On 02/23/2016 10:43 AM, Krzysztof Jusiak wrote:
> > >> On Tue, Feb 23, 2016 at 3:43 PM, Steven Watanabe <watan..._at_[hidden]
> <javascript:>>
> > >> wrote:
> > >>
> > >>> * What does CPP(SPLIT) mean? CPP, CPP(BTN), and CPP(SHOW) too.
> > >>>
> > >>
> > >> CPP uses Java Script to show the code, highlight it and let it test
> > online.
> > >
> > > I can understand needing javascript to
> > > test the code online and I can sort of
> > > justify using it for higlighting
> >
> > I can't. Highlighting is static content, there is no need for JS for
> that.
> >
>
> I created a ticket do display the code without JS ->
> https://github.com/boost-experimental/di/issues/208.
> However, highlighting will require JS to be enabled.
> I get your point that it might be done statically, however, mkdocs is
> using
> JS for it and I don't see a huge reason to change it.
>

Mkdocs can use pygments to highlight code blocks statically. However, I've
found that highlight.js does a much better job at highlighting. It seems
pygments would get confused by C++ syntax easily.
 

>
> Anyway, on this note, I really do not understand why requirement of Java
> Script is such a big thing?
> Data shows that only 1-2% of people don't have it enabled either way, so
> it's a really small number of people affected.
> Almost all pages are using Java Script in some way either way, so why
> Boost
> can't take advantage of it as others languages do?
>
> IMHO, maybe a bit controversial, not being more aggressive with the web
> tools available is one of the reasons why
> C++ is still considered old fashioned and so hard to work with.
>
> These days we can do so much better, Modern C++ allow us to code in a more
> productive way than even before, but it's hard
> to show all these benefits for new/old users with a boring/old fashion
> documentation.
>
> Therefore, Boost.DI doc is so interactive...
> * You can comment on the page
> * You have a chat to discuss issues
> * Finally you can run the code in your browser!
>

But how does the documentation deal with versioning? When you go back to a
previous version how does all the interaction work then? Also, how does it
work with offline documentation browsing such as Dash/Zeal?
 

>
> IMHO this type of documentation is more appealing to the average users as
> they can easily see how the library works and how good modern C++ becomes.
>
> What I mean by that, is that they can easily spot that the library...
> * Compiles quickly -> you can change it online and see!
> * Error messages are short and nice -> again, You can tryi 5 sec and seen
> the result!
> * Can be integrated easily -> it's done on the web, how hard it can be?
> (Boost.DI therefore is just one header and no dependencies)
> * Has support via comments/chats -> You don't have to subscribe to lists
> etc...
>
> I think Boost and C++ can win a lot by showing how good Modern C++ is,
> especially right now, when languages like Rust/Nim/Go/D
> are already showing how easily they are in comparison to OLD C++!
> It will come with a bit of cost, like enabling JS, but I think it's the
> cost worth taking!
>
> BTW. I would really appreciate comments about the library too.
>
> Cheers, Kris
>
>
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> > http://lists.boost.org/mailman/listinfo.cgi/boost
> >
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk