Hi,
Von: Branko Čibej [mailto:brane_at_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.schaber@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_at_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:brane_at_wandisco.com]
> >> Sent: vrijdag 13 maart 2015 08:53
> >> To: dev_at_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:ehuels_at_gmail.com]
> >>> *Gesendet:* Freitag, 6. März 2015 22:37
> >>> *An:* Julian Foad
> >>> *Cc:* Branko Čibej; dev_at_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
Received on 2015-03-13 11:41:51 CET