git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
To: "Marco Costalba" <mcostalba@gmail.com>
Cc: "Linus Torvalds" <torvalds@linux-foundation.org>,
	"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: Sun, 23 Sep 2007 21:11:30 +0200	[thread overview]
Message-ID: <857imhmc2l.fsf@lola.goethe.zz> (raw)
In-Reply-To: <e5bfff550709231143m7eb351bx4cf1c60d1247cc3d@mail.gmail.com> (Marco Costalba's message of "Sun\, 23 Sep 2007 20\:43\:25 +0200")

"Marco Costalba" <mcostalba@gmail.com> writes:

> On 9/23/07, David Kastrup <dak@gnu.org> wrote:
>> "Marco Costalba" <mcostalba@gmail.com> writes:
>>
>> > And BTW
>> >
>> > template <typename T>
>> >
>> > is the thing in C++ that more remembers me of opaque pointers and
>> > their use in C, the difference is that the first is fully type
>> > checked.
>>
>> Not really.  The difference is that the first generates new (and
>> optimized) code for every type which is something you can only do
>> using macros in C.  Class programming is similar to opaque pointers
>> (in particular concerning the generated code) but templates are really
>> more like macros, as their instantiation generates specialized code,
>> not at all like the handling of opaque pointers.
>
> Probably if I had written like this was more clear:
>
> template <typename T>  int some_function(T* p);

Huh?  How is this supposed to support your point?  There is nothing
like an opaque pointer involved here.  The point of opaque pointers is
that they can stand for a variety of types, whereas each template
instantiation can only substitute a single type.

> And regarding 'new' code for each type I would like to remember that
> template instantations of different types can be removed by
> compiler/linker when the instantations are the same (i.e. produce
> the same binary instuctions), this could happen for function
> templates that handle pointers, as example.

Hardly.  The type constraints/virtual function tables of any called
function depending on T will be different.  And if indeed nothing
depends on T at all inside of the template, it is pointless not to
declare it as void *p in the first place: the type of *p will never be
used then.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

  reply	other threads:[~2007-09-23 19:11 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 [this message]
2007-09-23 21:22                       ` Dmitry Potapov
2007-09-23 21:31                         ` David Kastrup
2007-09-23 23:10                           ` Robin Rosenberg
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=857imhmc2l.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --cc=alex@flawedcode.org \
    --cc=dmitry.kakurin@gmail.com \
    --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).