From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by hurricane.the-brannons.com (Postfix) with ESMTP id 0B05977BDE for ; Sat, 15 Feb 2014 00:53:20 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta08.westchester.pa.mail.comcast.net with comcast id SYp61n0011GhbT858Ysbww; Sat, 15 Feb 2014 08:52:35 +0000 Received: from eklhad ([107.5.36.150]) by omta07.westchester.pa.mail.comcast.net with comcast id SYsb1n0053EMmQj3TYsb9i; Sat, 15 Feb 2014 08:52:35 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke User-Agent: edbrowse/3.5.1 Date: Sat, 15 Feb 2014 03:52:37 -0500 Message-ID: <20140115035237.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392454355; bh=4AjavE6HUqxMeeadzouARG/6TidqPU5rUT6B1ZmUed4=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=UEdltbWq2aTLEFNayxaR0zSQr7WgB4qGOxj9hrZLdfwbZ7SmLjjPcwa9g/ZLEC9Zr RSf2CVMtsMyIerbftN7iEJFI/GsSYqYElQP/0Io5gayVNO3RB9iumKoBVSg1Xu8UdK 775/zgRJP73+A1X/U+yR6fjm4dKKnpN7Cr0a3WC08l7vnJ9FeUGNhLsQoCSTfNspOg xhT1axLal0kQDc0zPpgAm5fUG+Y5YjQSYH04pdXl4wRej4RrUnDpSQshPPvZcZSNa7 zml+Jl7CjY+Iq0JwkZwKPVKixQ+o8k5cIUTveqGZ9oHKxh1bvJIylivMpel1Zas+CM leMihWSvxZIGw== Subject: [Edbrowse-dev] extern "C"{} X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Karl Dahlke List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 08:53:21 -0000 I've seen it manyh times, but I don't understand what this does. I would guess that the prototypes enclosed are C functions, not C++, so the C++ compiler will call them with the C conventions. That would make sense, but then 1. Couldn't we just put it around eb.p? We don't really need it in eb.h. That would let us indent eb.h if we like, and be a bit clearer perhaps. 2. there are a few functions like set_global_property_string that are C++ functions, but are declared in eb.p, in eb.h, and inside extern "C"{}. In fact this one is declared twice, in eb.p and ebjs.p, one inside extern "C"{} and the other time not. So I guess I don't know what this does, and why we seem to get away with using it inconsistently. Karl Dahlke