Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39590
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain at.wakwak.com designates 219.103.130.24 as permitted sender)
Message-ID: <48965634.9010900@at.wakwak.com>
Date: Mon, 04 Aug 2008 10:07:00 +0900
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Marcus Boerger <helly@php.net>
Cc: Felipe Pena <felipensp@gmail.com>, internals@lists.php.net
References: <1217769121.5923.10.camel@pena> <1124407685.20080803184656@marcus-boerger.de>
In-Reply-To: <1124407685.20080803184656@marcus-boerger.de>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Const-correctness
From: moriyoshi@at.wakwak.com (Moriyoshi Koizumi)

Marcus Boerger wrote:
> Overall you do a ton of 'struct * const var' which only means that you are
> going to copy the pointer explicitly. Now functions that use a pointer in a
> loop and increment it cannot optimize the code anymore and are forced to use
> an additional real variable on the stack. So unless you have a very smart
> compiler, the result is an increased stack size. Generally speaking I prefer
> const on the reight and mid (between *'s) only. But others prefer it to denote
> that not even the passed in pointer gets modifed and this sometimes even makes
> debugging easier.

That's not necessarily true. In contrast to the volatile qualifier, the 
const qualifier in this context is just a semantic thing. So if your 
function has a immutable argument variable, it probably gets compiled a 
procedure that receives the argument in the registers and use it 
mutatively as long as no side-effects are possible. (of cource how it 
compiles depends on the target platform)

Having that said, I don't think it makes any sense to make pointer 
variables immutable, while marking the referent immutable greatly 
reduces tiny errors. Compilers are often smarter in this case.

Moriyoshi
-- 
Moriyoshi Koizumi <moriyoshi@at.wakwak.com>