Hi, Von: Branko Čibej [mailto:br...@wandisco.com]
> The problem (or "problem") with C++ is that it's *extremely* hard to > code things correctly in an exception-safe manner. Otherwise I'd be > all for using it, these days (especially with C++11) you have a > language that's in some ways horrible to use, but when used correctly > can provide huge benefits. But it takes years of single-minded > language-lawyerish hacking to get to the "used correctly" phase. Fully agreed. > In the past I'd thought about embedding Python into our sources, but > Python still (after 20 years ...) depends on a global interpreter > lock which pretty much kills any chance of lockless thread-safe code. One could use one interpreter instance per SVN client... > These days, I suppose we'd be looking at something like Go, which can > be linked with C/C++ and also natively export functions that can be > called from C/C++. As far as I can see, Go always comes with Garbage Collection instead of a deterministic memory management. Also, as far as I can see, Go does not go as far as Rust with what the compiler can check at compiletime. Best regards Markus Schaber CODESYS® a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com CODESYS forum: http://forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. > -----Ursprüngliche Nachricht----- > Gesendet: Freitag, 13. März 2015 10:35 > An: dev@subversion.apache.org > Betreff: Re: AW: Convenient array & hash iterators & accessors > > On 13.03.2015 10:05, Bert Huijben wrote: > > > >> -----Original Message----- > >> From: Branko Čibej [mailto:br...@wandisco.com] > >> Sent: vrijdag 13 maart 2015 08:53 > >> To: dev@subversion.apache.org > >> Subject: Re: AW: Convenient array & hash iterators & accessors > >> > >> On 13.03.2015 08:43, Markus Schaber wrote: > >>> Hi, > >>> > >>> > >>> > >>> I just wanted to throw „Rust“ into the discussion. > >>> > >>> > >>> > >>> Rust seems to have a very expressive type model, which allows to > >>> handle most of the memory management automatically and compile- > time- > >> safe. > >>> > >>> > >>> It also allows to go very “low level” / “lean” (they even wrote > >>> bootloaders and POC Kernels with it). > >>> > >>> > >>> > >>> It is compiled to native code, and has rather good C interfacing > >>> capabilities. > >>> > >>> > >>> > >>> > >>> > >>> On the other hand, I tend to oppose C++. While it feels “natural” > to > >>> “upgrade” from C to C++, the mere complexity of that language > makes > >>> it very difficult, at least if a project does not restrict itself > to > >>> a very well thought, strictly defined subset. > >>> > >>> > >>> > >>> Grüße, > >>> > >>> Markus > >>> > >>> > >>> > >>> *Von:*Erik Huelsmann [mailto:ehu...@gmail.com] > >>> *Gesendet:* Freitag, 6. März 2015 22:37 > >>> *An:* Julian Foad > >>> *Cc:* Branko Čibej; dev@subversion.apache.org > >>> *Betreff:* Re: Convenient array & hash iterators & accessors > >>> > >>> > >>> > >>> > >>> > >>> > It would make sense to design type-safe, light-weight > container and > >>> > iterator template wrappers around the APR structures if we > >>> decided to > >>> > write code in C++. Since we're not, "explicit is better > than > >>> > implicit". > >>> > >>> I understand the point. I note that "explicit" is not a > binary > >>> quality: there are degrees of it. > >>> > >>> I suppose I want to be writing in a higher level language. > Maybe I > >>> should just go ahead and really do so. > >>> > >>> > >>> > >>> Exactly. There's been talk about doing so for much too long > without > >>> action (other than attempts - including my own) to find a way to > >>> "upgrade" C to something less verbose and more expressive. > >>> > >>> > >>> > >>> I've been long thinking that there are specific areas which are > >>> more-or-less stand-alone, might be a good place to start this > >>> strategy. One place like that might qualify is the piece of code > >>> that deduces the eligeable revisions in merge tracking. That's > the > >>> code I'm thinking you're now working in? > >>> > >>> > >>> > >>> What kind of language were you thinking about? One of the > languages > >>> that came to mind is 'lua' which seems to have a pretty strong > focus > >>> on being integratable with C code. For lua there are also tools > to > >>> embed the compiled bytecode in a C library so the entire > higherlevel > >>> language can be fully encapsulated inside our libraries. > >>> > >> Why not Groovy (soon to be incubating at the ASF). That way we > keep > >> things in the family, and we're likely to eventually move > everything > >> to a JVM-based implementation instead of this silly native- > compiled, > >> last century stuff. > > I wouldn't have a problem with requiring a small bytecode > interpreter/stack machine inside libsvn_*, but a full JVM is > certainly not something that can be embedded in every application. > That changes the entire process requirements. > > > > I don't think multiple JVMs can run in the same process (especially > different versions), and attaching to an existing VM introduces > different problems. In AnkhSVN I run Subversion inside a process that > potentially has multiple .Net runtimes loaded, and until Visual > Studio is redesigned into a 64 bit process somewhere in the far > future I certainly can't just load a JVM in the process. > > > > TortoiseSVN has similar (if not stricter) limitations, but it is > > already multi process to avoid having to integrate everything into > > every process. (Not sure how much of Subversion they still load in > > every process that uses explorer infrastructure) > > > > I don't see a problem using something internally, and still > providing a 100% C compatible api... > > > > A good subset of C++ to introduce more type safety would be a good > option... But I can't think of a good way to define the subset and > really limit us to such a subset... > > And using more and more C++ will shrink the pool of developers that > would be able to join. > > > > By developing our own macro world in C we would have the same > problem though... > > The problem (or "problem") with C++ is that it's *extremely* hard to > code things correctly in an exception-safe manner. Otherwise I'd be > all for using it, these days (especially with C++11) you have a > language that's in some ways horrible to use, but when used correctly > can provide huge benefits. But it takes years of single-minded > language-lawyerish hacking to get to the "used correctly" phase. > > In the past I'd thought about embedding Python into our sources, but > Python still (after 20 years ...) depends on a global interpreter > lock which pretty much kills any chance of lockless thread-safe code. > > These days, I suppose we'd be looking at something like Go, which can > be linked with C/C++ and also natively export functions that can be > called from C/C++. > > -- Brane
