git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
To: David Kastrup <dak@gnu.org>
Cc: Dmitry Potapov <dpotapov@nbs-eng.ru>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Marco Costalba <mcostalba@gmail.com>,
	Pierre Habouzit <madcoder@debian.org>,
	Frank Lichtenheld <frank@lichtenheld.de>,
	Alex Unleashed <alex@flawedcode.org>, Kyle Rose <krose@krose.org>,
	Miles Bader <miles@gnu.org>,
	Dmitry Kakurin <dmitry.kakurin@gmail.com>,
	Git <git@vger.kernel.org>
Subject: Re: [OT] Re: C++ *for Git*
Date: Mon, 24 Sep 2007 01:10:59 +0200	[thread overview]
Message-ID: <200709240110.59680.robin.rosenberg.lists@dewire.com> (raw)
In-Reply-To: <85ejgpkr13.fsf@lola.goethe.zz>

söndag 23 september 2007 skrev David Kastrup:
> Dmitry Potapov <dpotapov@nbs-eng.ru> writes:
> 
> > On Sun, Sep 23, 2007 at 09:54:10AM -0700, Linus Torvalds wrote:
> >
> >>  - the stuff C++ *does* have is usually nasty. Implicit
> >>  initializers and destructors and the magic lifetime rules of
> >>  objects etc
> >
> > I am not sure what is wrong with initializers and destructors in
> > C++, but certainly there is no magic lifetime rules in C++, as it is
> > fully determined by the scope.
> 
> It has been some time since I last looked, but the lifetime of objects
> constructed in return statements was a moving target through several
> standards.  The last standard I bothered looking at had the object
> survive until the statement with the function call expression ended:
> quite a strange synchronization point with regard to language design.

The idea is that you should be able to use temporaries by reference and
trust them to be valid over function calls end even function returns, so 
you can write efficient matrix math libraries that do not copy data much while
retaining value semantics with overloaded operators. It is a purely practical
matter, what actually works and is efficient, not dogmatic language "design".

Earlier versions failed to make up something useful here.

> > In fact, other high level languages that use GC have much more
> > unpredictable lifetime rules for objects.
> 
> Mostly objects are alive as long as you can refer to them.  Not really
> complicated.

What could be simpler, besides all static variables.

-- robin

  reply	other threads:[~2007-09-23 23:09 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-22 10:42 C++ *for Git* Dmitry Kakurin
2007-09-22 11:11 ` David Kastrup
2007-09-22 12:48 ` Johannes Schindelin
2007-09-22 15:23   ` Marco Costalba
2007-09-23  4:54     ` Dmitry Kakurin
2007-09-22 15:15 ` Kyle Rose
2007-09-22 18:08   ` Miles Bader
2007-09-22 18:25     ` [OT] " Kyle Rose
2007-09-22 19:11       ` David Kastrup
2007-09-22 22:50       ` Alex Unleashed
2007-09-23  2:09         ` Frank Lichtenheld
2007-09-23  6:25           ` David Brown
2007-09-23  7:23             ` David Kastrup
2007-09-23  9:29               ` Marco Costalba
2007-09-23  9:42                 ` David Kastrup
2007-09-23  9:50                   ` Marco Costalba
2007-09-23 10:45                 ` Pierre Habouzit
2007-09-23 13:42                   ` Marco Costalba
2007-09-23 14:23                     ` Nicolas Pitre
2007-09-23 14:45                       ` Marco Costalba
2007-09-23 14:37                     ` David Kastrup
2007-09-23 15:15                       ` Marco Costalba
2007-09-23 17:49                       ` Paul Franz
2007-09-23 16:54                     ` Linus Torvalds
2007-09-23 18:05                       ` Marco Costalba
2007-09-23 18:30                         ` David Kastrup
2007-09-23 18:43                           ` Marco Costalba
2007-09-23 19:11                             ` David Kastrup
2007-09-23 21:22                       ` Dmitry Potapov
2007-09-23 21:31                         ` David Kastrup
2007-09-23 23:10                           ` Robin Rosenberg [this message]
2007-09-23 22:25                         ` Reece Dunn
2007-09-24 10:46                           ` Dmitry Potapov
2007-09-22 22:24   ` Martin Langhoff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200709240110.59680.robin.rosenberg.lists@dewire.com \
    --to=robin.rosenberg.lists@dewire.com \
    --cc=alex@flawedcode.org \
    --cc=dak@gnu.org \
    --cc=dmitry.kakurin@gmail.com \
    --cc=dpotapov@nbs-eng.ru \
    --cc=frank@lichtenheld.de \
    --cc=git@vger.kernel.org \
    --cc=krose@krose.org \
    --cc=madcoder@debian.org \
    --cc=mcostalba@gmail.com \
    --cc=miles@gnu.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).