From verthan@miel.mot.com Thu Aug 01 14:05:49 2002 Received: from mail by ftoomsh.progsoc.uts.edu.au with spam-scanned (Exim 3.35 #1 (Debian)) id 17a7Ce-0001Ay-00 for ; Thu, 01 Aug 2002 14:05:47 +1000 Received: from motgate.mot.com ([129.188.136.100]) by ftoomsh.progsoc.uts.edu.au with esmtp (Exim 3.35 #1 (Debian)) id 17a7Cc-0001Al-00 for ; Thu, 01 Aug 2002 14:04:42 +1000 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id XAA21893 for ; Tue, 30 Jul 2002 23:56:33 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id XAA25988 for ; Tue, 30 Jul 2002 23:56:30 -0700 (MST)] Received: from pcwks152 (pcwks152.miel.mot.com [217.1.125.118]) by miel.mot.com (8.9.3/8.9.3) with SMTP id MAA14907 for ; Wed, 31 Jul 2002 12:26:00 +0530 (IST) From: "Goverthanan" To: Message-ID: <000501c238c4$2bf22470$767d01d9@miel.mot.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C238F2.45AA6070" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Subject: [LC++]sizeof... Sender: tuxcpprogramming-admin@lists.linux.org.au Errors-To: tuxcpprogramming-admin@lists.linux.org.au X-BeenThere: tuxcpprogramming@lists.linux.org.au X-Mailman-Version: 2.0.3 Precedence: bulk Reply-To: tuxcpprogramming@lists.linux.org.au X-Reply-To: List-Help: List-Post: List-Subscribe: , List-Id: The Linux C++ Programming List List-Unsubscribe: , List-Archive: Date: Mon Aug 5 21:11:32 2002 X-Original-Date: Thu, 1 Aug 2002 00:27:51 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C238F2.45AA6070 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit RE: [LC++]Scoping questionHi, Can anyone tell me whats the alternative for sizeof function i can use to get the size of the variable... Rgds. ------=_NextPart_000_0006_01C238F2.45AA6070 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable RE: [LC++]Scoping question
Hi,
Can anyone=20 tell me whats the alternative for sizeof function i can use to get the = size of=20 the variable...
 
Rgds.
------=_NextPart_000_0006_01C238F2.45AA6070-- From lloy0076@rebel.net.au Mon Aug 05 21:48:36 2002 Received: from mail by ftoomsh.progsoc.uts.edu.au with spam-scanned (Exim 3.35 #1 (Debian)) id 17bgLf-0000wv-00; Mon, 05 Aug 2002 21:48:32 +1000 Received: from news.tellurian.com.au ([203.20.69.66] helo=rebel.net.au ident=root) by ftoomsh.progsoc.uts.edu.au with esmtp (Exim 3.35 #1 (Debian)) id 17bgLe-0000wr-00; Mon, 05 Aug 2002 21:48:30 +1000 Received: from rebel.net.au (dialup-6.rebel.net.au [203.20.69.76]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id VAA02933; Mon, 5 Aug 2002 21:34:14 +0930 Message-ID: <3D4E685D.457944EB@rebel.net.au> From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: linuxcprogramming@lists.linux.org.au, tuxcpprogramming@lists.linux.org.au Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.0 required=5.0 tests=FROM_ENDS_IN_NUMS version=2.20 X-Spam-Level: * Subject: [LC++]List Information Sender: tuxcpprogramming-admin@lists.linux.org.au Errors-To: tuxcpprogramming-admin@lists.linux.org.au X-BeenThere: tuxcpprogramming@lists.linux.org.au X-Mailman-Version: 2.0.3 Precedence: bulk Reply-To: tuxcpprogramming@lists.linux.org.au List-Help: List-Post: List-Subscribe: , List-Id: The Linux C++ Programming List List-Unsubscribe: , List-Archive: Date: Mon Aug 5 22:06:25 2002 X-Original-Date: Mon, 05 Aug 2002 21:28:21 +0930 It appears that the list servers went down and that noone actually noticed it until I pointed out that these lists were not working. I don't host these lists and I am currently evaluating whether I should shift the lists (again) or wait to see whether the list servers become stable again. I apologise for the downtime. DSL -- We are not the United States' ally We are the 53rd sovereign state of the Federation From ianezz@kinsale.sodalia.it Mon Aug 05 22:55:45 2002 Received: from mail by ftoomsh.progsoc.uts.edu.au with spam-scanned (Exim 3.35 #1 (Debian)) id 17bhOg-0002Oy-00 for ; Mon, 05 Aug 2002 22:55:44 +1000 Received: from kinsale.sodalia.it ([193.70.237.166]) by ftoomsh.progsoc.uts.edu.au with esmtp (Exim 3.35 #1 (Debian)) id 17bhOf-0002OQ-00 for ; Mon, 05 Aug 2002 22:55:41 +1000 Received: (from ianezz@localhost) by kinsale.sodalia.it (8.8.6/8.8.6) id PAA19951; Mon, 5 Aug 2002 15:55:53 +0200 (METDST) From: ianezz@kinsale.sodalia.it MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15694.33767.584682.557143@kinsale.sodalia.it> To: tuxcpprogramming@lists.linux.org.au Subject: Re: [LC++]sizeof... In-Reply-To: <000501c238c4$2bf22470$767d01d9@miel.mot.com> References: <000501c238c4$2bf22470$767d01d9@miel.mot.com> X-Mailer: VM 7.05 under Emacs 21.1.1 X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.20 X-Spam-Level: Sender: tuxcpprogramming-admin@lists.linux.org.au Errors-To: tuxcpprogramming-admin@lists.linux.org.au X-BeenThere: tuxcpprogramming@lists.linux.org.au X-Mailman-Version: 2.0.3 Precedence: bulk Reply-To: tuxcpprogramming@lists.linux.org.au List-Help: List-Post: List-Subscribe: , List-Id: The Linux C++ Programming List List-Unsubscribe: , List-Archive: Date: Mon Aug 5 22:56:08 2002 X-Original-Date: Mon, 5 Aug 2002 15:55:51 +0200 Goverthanan, pigiando tasti a caso sul citofono, ha scritto: > Can anyone tell me whats the alternative for sizeof function i can > use to get the size of the variable... sizeof() is an operator of the language, not a function, and unless you know in advance how many bytes a certain type requires, there's no way around it (i.e. only the compiler knows -- this is true expecially for structs and classes). May I ask you why are you trying to avoid using sizeof()? -- | \ \ | ___|_ |_ | ianezz AT sodalia.it | _ \ | \ | _| / / Visita il LinuxTrent a _|_/ _\_| _|____|___|___| http://www.linuxtrent.it From psasi@corp.untd.com Mon Aug 05 23:06:43 2002 Received: from mail by ftoomsh.progsoc.uts.edu.au with spam-scanned (Exim 3.35 #1 (Debian)) id 17bhZI-0002ia-00 for ; Mon, 05 Aug 2002 23:06:43 +1000 Received: from cs1.hyd.office.juno.com ([64.136.14.32]) by ftoomsh.progsoc.uts.edu.au with esmtp (Exim 3.35 #1 (Debian)) id 17bhZH-0002iG-00 for ; Mon, 05 Aug 2002 23:06:39 +1000 Received: from hydmail2.hyd.office.juno.com (hydmail2.hyd.office.juno.com [64.136.14.20]) by cs1.hyd.office.juno.com (8.8.6.Beta0/8.8.7/juno-1.2) with ESMTP id SAAAA02646 for ; Mon, 5 Aug 2002 18:36:10 +0530 (IST) Received: by hydmail2.hyd.office.juno.com with Internet Mail Service (5.5.2653.19) id <36YB3DQW>; Mon, 5 Aug 2002 18:36:10 +0530 Message-ID: From: "Palaka, Sasidhar" To: "'tuxcpprogramming@lists.linux.org.au'" Subject: RE: [LC++]sizeof... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: tuxcpprogramming-admin@lists.linux.org.au Errors-To: tuxcpprogramming-admin@lists.linux.org.au X-BeenThere: tuxcpprogramming@lists.linux.org.au X-Mailman-Version: 2.0.3 Precedence: bulk Reply-To: tuxcpprogramming@lists.linux.org.au List-Help: List-Post: List-Subscribe: , List-Id: The Linux C++ Programming List List-Unsubscribe: , List-Archive: Date: Mon Aug 5 23:11:05 2002 X-Original-Date: Mon, 5 Aug 2002 18:36:06 +0530 How about implementing this way, Say, you want to know the size of 'char'. Look at the following skeleton code. char* p; char* q, q = p+1; return q-p; Basically the idea is to increment the pointer and then subtract to give the size. -----Original Message----- From: ianezz@kinsale.sodalia.it [mailto:ianezz@kinsale.sodalia.it] Sent: Monday, August 05, 2002 7:26 PM To: tuxcpprogramming@lists.linux.org.au Subject: Re: [LC++]sizeof... Goverthanan, pigiando tasti a caso sul citofono, ha scritto: > Can anyone tell me whats the alternative for sizeof function i can > use to get the size of the variable... sizeof() is an operator of the language, not a function, and unless you know in advance how many bytes a certain type requires, there's no way around it (i.e. only the compiler knows -- this is true expecially for structs and classes). May I ask you why are you trying to avoid using sizeof()? -- | \ \ | ___|_ |_ | ianezz AT sodalia.it | _ \ | \ | _| / / Visita il LinuxTrent a _|_/ _\_| _|____|___|___| http://www.linuxtrent.it _______________________________________________ This is the Linux C++ Programming List : http://lists.linux.org.au/listinfo/tuxcpprogramming List From ianezz@kinsale.sodalia.it Tue Aug 06 00:19:17 2002 Received: from mail by ftoomsh.progsoc.uts.edu.au with spam-scanned (Exim 3.35 #1 (Debian)) id 17bihX-00040y-00 for ; Tue, 06 Aug 2002 00:19:17 +1000 Received: from kinsale.sodalia.it ([193.70.237.166]) by ftoomsh.progsoc.uts.edu.au with esmtp (Exim 3.35 #1 (Debian)) id 17bihW-00040M-00 for ; Tue, 06 Aug 2002 00:19:14 +1000 Received: (from ianezz@localhost) by kinsale.sodalia.it (8.8.6/8.8.6) id RAA20306; Mon, 5 Aug 2002 17:19:33 +0200 (METDST) From: ianezz@kinsale.sodalia.it MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15694.38788.667595.289442@kinsale.sodalia.it> To: tuxcpprogramming@lists.linux.org.au Subject: RE: [LC++]sizeof... In-Reply-To: References: X-Mailer: VM 7.05 under Emacs 21.1.1 X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.20 X-Spam-Level: Sender: tuxcpprogramming-admin@lists.linux.org.au Errors-To: tuxcpprogramming-admin@lists.linux.org.au X-BeenThere: tuxcpprogramming@lists.linux.org.au X-Mailman-Version: 2.0.3 Precedence: bulk Reply-To: tuxcpprogramming@lists.linux.org.au List-Help: List-Post: List-Subscribe: , List-Id: The Linux C++ Programming List List-Unsubscribe: , List-Archive: Date: Tue Aug 6 00:21:05 2002 X-Original-Date: Mon, 5 Aug 2002 17:19:32 +0200 Palaka, Sasidhar, pigiando tasti a caso sul citofono, ha scritto: > Basically the idea is to increment the pointer and then subtract to give the > size. Try it with an `int'... the difference between pointers is in bytes/sizeof(pointed type)... so it gives back always `1'. Of course you could try casting the pointers to some unsigned type large enough before subtracting them, but then how do you know how much is ``large enough''? Use sizeof() and live in peace. -- | \ \ | ___|_ |_ | ianezz AT sodalia.it | _ \ | \ | _| / / Visita il LinuxTrent a _|_/ _\_| _|____|___|___| http://www.linuxtrent.it From psasi@corp.untd.com Tue Aug 06 01:00:22 2002 Received: from mail by ftoomsh.progsoc.uts.edu.au with spam-scanned (Exim 3.35 #1 (Debian)) id 17bjLI-0004gW-00 for ; Tue, 06 Aug 2002 01:00:22 +1000 Received: from cs1.hyd.office.juno.com ([64.136.14.32]) by ftoomsh.progsoc.uts.edu.au with esmtp (Exim 3.35 #1 (Debian)) id 17bjLG-0004gI-00 for ; Tue, 06 Aug 2002 01:00:18 +1000 Received: from hydmail2.hyd.office.juno.com (hydmail2.hyd.office.juno.com [64.136.14.20]) by cs1.hyd.office.juno.com (8.8.6.Beta0/8.8.7/juno-1.2) with ESMTP id UAAAA27463 for ; Mon, 5 Aug 2002 20:30:14 +0530 (IST) Received: by hydmail2.hyd.office.juno.com with Internet Mail Service (5.5.2653.19) id <36YB3D4R>; Mon, 5 Aug 2002 20:30:13 +0530 Message-ID: From: "Palaka, Sasidhar" To: "'tuxcpprogramming@lists.linux.org.au'" Subject: RE: [LC++]sizeof... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: tuxcpprogramming-admin@lists.linux.org.au Errors-To: tuxcpprogramming-admin@lists.linux.org.au X-BeenThere: tuxcpprogramming@lists.linux.org.au X-Mailman-Version: 2.0.3 Precedence: bulk Reply-To: tuxcpprogramming@lists.linux.org.au List-Help: List-Post: List-Subscribe: , List-Id: The Linux C++ Programming List List-Unsubscribe: , List-Archive: Date: Tue Aug 6 01:01:05 2002 X-Original-Date: Mon, 5 Aug 2002 20:30:11 +0530 Hi, Thanks for correcting me, you are right. I missed out that type casting part. But, say if I am interested in implementing 'sizeof' as an exercise question, Is there any other way out apart from what I suggested? Thanks, Sasi. -----Original Message----- From: ianezz@kinsale.sodalia.it [mailto:ianezz@kinsale.sodalia.it] Sent: Monday, August 05, 2002 8:50 PM To: tuxcpprogramming@lists.linux.org.au Subject: RE: [LC++]sizeof... Palaka, Sasidhar, pigiando tasti a caso sul citofono, ha scritto: > Basically the idea is to increment the pointer and then subtract to give the > size. Try it with an `int'... the difference between pointers is in bytes/sizeof(pointed type)... so it gives back always `1'. Of course you could try casting the pointers to some unsigned type large enough before subtracting them, but then how do you know how much is ``large enough''? Use sizeof() and live in peace. -- | \ \ | ___|_ |_ | ianezz AT sodalia.it | _ \ | \ | _| / / Visita il LinuxTrent a _|_/ _\_| _|____|___|___| http://www.linuxtrent.it _______________________________________________ This is the Linux C++ Programming List : http://lists.linux.org.au/listinfo/tuxcpprogramming List From ianezz@kinsale.sodalia.it Tue Aug 06 01:24:31 2002 Received: from mail by ftoomsh.progsoc.uts.edu.au with spam-scanned (Exim 3.35 #1 (Debian)) id 17bjif-0005CT-00 for ; Tue, 06 Aug 2002 01:24:31 +1000 Received: from kinsale.sodalia.it ([193.70.237.166]) by ftoomsh.progsoc.uts.edu.au with esmtp (Exim 3.35 #1 (Debian)) id 17bjie-0005Bk-00 for ; Tue, 06 Aug 2002 01:24:28 +1000 Received: (from ianezz@localhost) by kinsale.sodalia.it (8.8.6/8.8.6) id SAA20579; Mon, 5 Aug 2002 18:24:47 +0200 (METDST) From: ianezz@kinsale.sodalia.it MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15694.42703.9252.717183@kinsale.sodalia.it> To: tuxcpprogramming@lists.linux.org.au Subject: RE: [LC++]sizeof... In-Reply-To: References: X-Mailer: VM 7.05 under Emacs 21.1.1 X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.20 X-Spam-Level: Sender: tuxcpprogramming-admin@lists.linux.org.au Errors-To: tuxcpprogramming-admin@lists.linux.org.au X-BeenThere: tuxcpprogramming@lists.linux.org.au X-Mailman-Version: 2.0.3 Precedence: bulk Reply-To: tuxcpprogramming@lists.linux.org.au List-Help: List-Post: List-Subscribe: , List-Id: The Linux C++ Programming List List-Unsubscribe: , List-Archive: Date: Tue Aug 6 01:26:05 2002 X-Original-Date: Mon, 5 Aug 2002 18:24:46 +0200 Usando la tastiera di Palaka, Sasidhar, uno sconosciuto ha scritto: > But, say if I am interested in implementing 'sizeof' as an exercise > question, > Is there any other way out apart from what I suggested? Well, you could try int * p; int * q; q = p + 1; return (unsigned long)q - (unsigned long)p; assuming that strange things don't happen when casting a pointer into an unsigned long. Or even int * p; int * q; q = p + 1; return (char *)q - (char *)p; since sizeof(char) should always be 1 byte. -- | \ \ | ___|_ |_ | ianezz AT sodalia.it | _ \ | \ | _| / / Visita il LinuxTrent a _|_/ _\_| _|____|___|___| http://www.linuxtrent.it From lloyd@acm.jhu.edu Sat Aug 17 02:58:23 2002 Received: from mail by ftoomsh.progsoc.uts.edu.au with spam-scanned (Exim 3.35 #1 (Debian)) id 17fkQX-0005xd-00 for ; Sat, 17 Aug 2002 02:58:23 +1000 Received: from centaur.acm.jhu.edu ([128.220.223.65]) by ftoomsh.progsoc.uts.edu.au with esmtp (Exim 3.35 #1 (Debian)) id 17fkQX-0005xM-00 for ; Sat, 17 Aug 2002 02:58:21 +1000 Received: from sol.galaxy.acm.jhu.edu (sol.galaxy.acm.jhu.edu [128.220.223.70]) by centaur.acm.jhu.edu (Postfix) with ESMTP id 0489C13E98 for ; Fri, 16 Aug 2002 12:58:18 -0400 (EDT) Received: by sol.galaxy.acm.jhu.edu (Postfix, from userid 528) id 1A55DD81F; Fri, 16 Aug 2002 12:58:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by sol.galaxy.acm.jhu.edu (Postfix) with ESMTP id 0808A78B5 for ; Fri, 16 Aug 2002 12:58:16 -0400 (EDT) From: Jack Lloyd X-X-Sender: To: Message-ID: X-GPG-Key-ID: 4DCDF398 X-GPG-Key-Fingerprint: 2DD2 95F9 C7E3 A15E AF29 80E1 D6A9 A5B9 4DCD F398 X-Red-Robot-Approved: CRUSH ALL HU-MANS! Organization: JHU ACM/CS/SRL MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK,PORN_10 version=2.20 X-Spam-Level: Subject: [LC++]Impressions of ACE? Sender: tuxcpprogramming-admin@lists.linux.org.au Errors-To: tuxcpprogramming-admin@lists.linux.org.au X-BeenThere: tuxcpprogramming@lists.linux.org.au X-Mailman-Version: 2.0.3 Precedence: bulk Reply-To: tuxcpprogramming@lists.linux.org.au List-Help: List-Post: List-Subscribe: , List-Id: The Linux C++ Programming List List-Unsubscribe: , List-Archive: Date: Sat Aug 17 03:01:05 2002 X-Original-Date: Fri, 16 Aug 2002 12:58:15 -0400 (EDT) Hi, Has anyone here used ACE (http://www.cs.wustl.edu/~schmidt/ACE-overview.html)? Any impressions? I've heard many people like it. Looking at the tutorials, I'm somewhat disapoined that it doesn't use namespaces (I guess it's been around too long for that), and the ACE_XXX_RETURN stuff seems rather odd (I can't believe ACE doesn't use exceptions given it's heavy use of templates). But, OTOH, I haven't heard about any similiar C++ networking abstraction libraries (that are free (preferably BSD or LGPL), portable, and stable). So if anyone has any knowledge of any... -Jack From Torsten@Rennett.de Sat Aug 17 19:06:35 2002 Received: from mail by ftoomsh.progsoc.uts.edu.au with spam-scanned (Exim 3.35 #1 (Debian)) id 17fzXW-0007K5-00 for ; Sat, 17 Aug 2002 19:06:34 +1000 Received: from mailout07.sul.t-online.com ([194.25.134.83]) by ftoomsh.progsoc.uts.edu.au with esmtp (Exim 3.35 #1 (Debian)) id 17fzXV-0007Jz-00 for ; Sat, 17 Aug 2002 19:06:34 +1000 Received: from fwd01.sul.t-online.de by mailout07.sul.t-online.com with smtp id 17fzXD-0003Rj-0F; Sat, 17 Aug 2002 11:06:15 +0200 Received: from Rennett.de (08990480538-0001@[217.80.233.157]) by fmrl01.sul.t-online.com with esmtp id 17fzX7-04QyuGC; Sat, 17 Aug 2002 11:06:09 +0200 Message-ID: <3D5E11D9.F668961B@Rennett.de> From: Torsten Rennett Organization: Ingenieurbuero RENNETT X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: tuxcpprogramming@lists.linux.org.au Subject: Re: [LC++]Impressions of ACE? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: 08990480538-0001@t-dialin.net Sender: tuxcpprogramming-admin@lists.linux.org.au Errors-To: tuxcpprogramming-admin@lists.linux.org.au X-BeenThere: tuxcpprogramming@lists.linux.org.au X-Mailman-Version: 2.0.3 Precedence: bulk Reply-To: tuxcpprogramming@lists.linux.org.au List-Help: List-Post: List-Subscribe: , List-Id: The Linux C++ Programming List List-Unsubscribe: , List-Archive: Date: Sat Aug 17 19:11:06 2002 X-Original-Date: Sat, 17 Aug 2002 11:05:29 +0200 Hi Jack, Jack Lloyd wrote: > > Hi, > > Has anyone here used ACE > (http://www.cs.wustl.edu/~schmidt/ACE-overview.html)? Any impressions? I've I'm currently using ACE in a Client/Server-Project and I'm really satisfied. Thanks to the portability of ACE the program is running on Linux and NCR Unix (AT&T) and the Clients also on Windows NT and Windows 2000. To compile the Clients under Windows (same source code as for Unix with some #ifdefs) I used gcc-2.95.3 and MinGW. Some adjustments were necessary but now it runs fine. > heard many people like it. Looking at the tutorials, I'm somewhat > disapoined that it doesn't use namespaces (I guess it's been around too > long for that), and the ACE_XXX_RETURN stuff seems rather odd (I can't > believe ACE doesn't use exceptions given it's heavy use of templates). I think the documentation of ACE could be a bit better. But now there is a new book about ACE: Douglas C. Schmidt and Stephen D. Huston: "C++ Network Programming, Volume I: Mastering Complexity with ACE and Patterns" Addison Wesley, 2002; C++ In-Depth Series ISBN: 0-201-60464-7 http://www.awprofessional.com/catalog/product.asp?product_id={1E34F487-4285-4C05-9BF9-B55195F3C83F} Upcoming ACE publications: - "Volume II: Systematic Reuse with ACE and Frameworks" (Addison Wesley) - "The ACE programmer's Guide" (Addison Wesley) And also the following might be of interest: Douglas Schmidt, Michael Stal, Hans Rohnert, Frank Buschmann: "Pattern-oriented Software Architecture Vol 2: Patterns for Concurrent and Networked Objects" John Wiley and Sons, 15. August 2000 ISBN: 0471606952 > But, OTOH, I haven't heard about any similiar C++ networking abstraction > libraries (that are free (preferably BSD or LGPL), portable, and stable). > So if anyone has any knowledge of any... IMHO there is no alternative to ACE if you are programming in C++. If you have to develop a distributed network application using CORBA also consider using TAO - The ACE ORB. Torsten -- Ingenieurbuero RENNETT -- innovative Software-Entwicklung -- Torsten Rennett Ludwig-Thoma-Weg 14 E-Mail: mailto:Torsten@Rennett.de D-85551 Heimstetten Telefon: +49-89-90480538 From mark@austrics.com.au Thu Aug 29 17:29:51 2002 Received: from mail by ftoomsh.progsoc.uts.edu.au with spam-scanned (Exim 3.35 #1 (Debian)) id 17kJkR-0007Im-00 for ; Thu, 29 Aug 2002 17:29:50 +1000 Received: from fw.austrics.com.au ([150.101.99.165] ident=postfix) by ftoomsh.progsoc.uts.edu.au with esmtp (Exim 3.35 #1 (Debian)) id 17kJkQ-0007Ij-00 for ; Thu, 29 Aug 2002 17:29:46 +1000 Received: from blaze.lan.austrics.com.au (blaze.lan.austrics.com.au [192.168.1.2]) by fw.austrics.com.au (Postfix) with ESMTP id 280EB126EE3 for ; Thu, 29 Aug 2002 16:59:45 +0930 (CST) Received: from localhost.localdomain (mark@research [192.168.1.36]) by blaze.lan.austrics.com.au (8.9.2/8.9.2) with ESMTP id RAA26600 for ; Thu, 29 Aug 2002 17:04:24 +0930 (CST) From: Dr Mark H Phillips To: Tux C++ Programming Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Message-Id: <1030606341.24586.2737.camel@research> Mime-Version: 1.0 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Subject: [LC++]Producing a log of routine entry and exit Sender: tuxcpprogramming-admin@lists.linux.org.au Errors-To: tuxcpprogramming-admin@lists.linux.org.au X-BeenThere: tuxcpprogramming@lists.linux.org.au X-Mailman-Version: 2.0.3 Precedence: bulk Reply-To: tuxcpprogramming@lists.linux.org.au List-Help: List-Post: List-Subscribe: , List-Id: The Linux C++ Programming List List-Unsubscribe: , List-Archive: Date: Thu Aug 29 17:31:06 2002 X-Original-Date: 29 Aug 2002 17:02:20 +0930 Hi, For debugging purposes, I wished to provide a standard means of logging the entry into, and exit from, each of my routines. This log should give the name of the routine, and calling signature. On entry it should print the input parameters, and on exit, the output parameters. My current way of doing this is like this: int myRoutine(string& retString, int a, char b) { cout<<"entering myRoutine(string&, int, char)\n" <<" second param: "<; Thu, 29 Aug 2002 19:38:05 +1000 Received: from ns1.centrictelecom.com ([217.150.98.2]) by ftoomsh.progsoc.uts.edu.au with esmtp (Exim 3.35 #1 (Debian)) id 17kLkW-0000mK-00 for ; Thu, 29 Aug 2002 19:38:00 +1000 Received: from [217.150.100.138.6026] (helo=mailgate) by ns1.centrictelecom.com with esmtp (Exim 3.22 #1) id 17kLdp-0002vU-00 for tuxcpprogramming@lists.linux.org.au; Thu, 29 Aug 2002 10:31:05 +0100 Received: from [89.0.0.95] by (MailGate 3.5.172) with ESMTP; Thu, 29 Aug 2002 10:35:58 +0100 Received: by warhol with Internet Mail Service (5.5.2448.0) id <3NBT2SPL>; Thu, 29 Aug 2002 10:37:11 +0100 Message-ID: From: Vincent Penquerc'h To: "'tuxcpprogramming@lists.linux.org.au'" Subject: RE: [LC++]Producing a log of routine entry and exit MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24F3F.A6700670" X-Spam-Status: No, hits=0.2 required=5.0 tests=MIME_NULL_BLOCK version=2.20 X-Spam-Level: Sender: tuxcpprogramming-admin@lists.linux.org.au Errors-To: tuxcpprogramming-admin@lists.linux.org.au X-BeenThere: tuxcpprogramming@lists.linux.org.au X-Mailman-Version: 2.0.3 Precedence: bulk Reply-To: tuxcpprogramming@lists.linux.org.au List-Help: List-Post: List-Subscribe: , List-Id: The Linux C++ Programming List List-Unsubscribe: , List-Archive: Date: Thu Aug 29 19:41:05 2002 X-Original-Date: Thu, 29 Aug 2002 10:37:08 +0100 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C24F3F.A6700670 Content-Type: text/plain; charset="windows-1252" > For debugging purposes, I wished to provide a standard means of > logging the entry into, and exit from, each of my routines. This > log should give the name of the routine, and calling signature. > On entry it should print the input parameters, and on exit, the > output parameters. class EntryExitLogger { private: string name; public: EntryExitLogger(const char *name): name(name) { fprintf(stderr,"Entering %s\n",name); } ~EntryExitLogger() { fprintf(stderr,"Exiting %s\n",name); } }; #define EELOG EntryExitLogger entry_exit_logger(__PRETTY_FUNCTION__); void foo() { EELOG // Do stuff } __PRETTY_FUNCTION__ may not be the right spelling, check the docs. If you want the parameters, then it becomes way more complicated. If you want an automated thing, your best bet is to either modify the code to GCC to insert such code (yuck) or have some code to interpret the function signature and peek on the stack what it says is there (probably rather flaky). -- Vincent Penquerc'h ------_=_NextPart_001_01C24F3F.A6700670 Content-Type: text/html; charset="windows-1252" RE: [LC++]Producing a log of routine entry and exit

> For debugging purposes, I wished to provide a standard means of
> logging the entry into, and exit from, each of my routines.  This
> log should give the name of the routine, and calling signature.
> On entry it should print the input parameters, and on exit, the
> output parameters.

class EntryExitLogger {
private:
  string name;
public:
  EntryExitLogger(const char *name): name(name)
  {
    fprintf(stderr,"Entering %s\n",name);
  }
  ~EntryExitLogger()
  {
    fprintf(stderr,"Exiting %s\n",name);
  }
};

#define EELOG EntryExitLogger entry_exit_logger(__PRETTY_FUNCTION__);

void foo()
{
  EELOG
  // Do stuff
}

__PRETTY_FUNCTION__ may not be the right spelling, check the docs.


If you want the parameters, then it becomes way more complicated.
If you want an automated thing, your best bet is to either modify
the code to GCC to insert such code (yuck) or have some code to
interpret the function signature and peek on the stack what it says
is there (probably rather flaky).

--
Vincent Penquerc'h

------_=_NextPart_001_01C24F3F.A6700670-- From charlesrandle@hotmail.com Fri Aug 30 02:35:56 2002 Received: from mail by ftoomsh.progsoc.uts.edu.au with spam-scanned (Exim 3.35 #1 (Debian)) id 17kSGw-00071n-00 for ; Fri, 30 Aug 2002 02:35:56 +1000 Received: from f64.law3.hotmail.com ([209.185.241.64] helo=hotmail.com) by ftoomsh.progsoc.uts.edu.au with esmtp (Exim 3.35 #1 (Debian)) id 17kSGv-00071d-00 for ; Fri, 30 Aug 2002 02:35:53 +1000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 29 Aug 2002 09:34:20 -0700 Received: from 208.163.62.10 by lw3fd.law3.hotmail.msn.com with HTTP; Thu, 29 Aug 2002 16:34:19 GMT X-Originating-IP: [208.163.62.10] From: "Charles Randle" To: tuxcpprogramming@lists.linux.org.au Bcc: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_3028_7b73_6a45" Message-ID: X-OriginalArrivalTime: 29 Aug 2002 16:34:20.0291 (UTC) FILETIME=[ECD67530:01C24F79] X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Subject: [LC++]C++ Callback Problems Sender: tuxcpprogramming-admin@lists.linux.org.au Errors-To: tuxcpprogramming-admin@lists.linux.org.au X-BeenThere: tuxcpprogramming@lists.linux.org.au X-Mailman-Version: 2.0.3 Precedence: bulk Reply-To: tuxcpprogramming@lists.linux.org.au List-Help: List-Post: List-Subscribe: , List-Id: The Linux C++ Programming List List-Unsubscribe: , List-Archive: Date: Fri Aug 30 02:36:05 2002 X-Original-Date: Thu, 29 Aug 2002 11:34:19 -0500 This is a multi-part message in MIME format. ------=_NextPart_000_3028_7b73_6a45 Content-Type: text/plain; format=flowed Hi All , I have attached the following two files : "callback.hpp" and "cbtest.cpp" The first is a source file which attempts at implementing callback in C++ and the second is a test file. Whenever I compile the test file I get the following error : make -k cbtest g++ cbtest.cpp -o cbtest cbtest.cpp: In function `int main(int, const char* const*)': cbtest.cpp:20: no matching function for call to `xgx_support::gx_callback:: make_M2(A&, void (A::*)())' callback.hpp:182: candidates are: static xgx_support::gx_callback xgx_support::gx_callback::make_M2(CLIENT&, CLIENTMEMBER&) [with CLIENT = A, CLIENTMEMBER = void (A::*)()] make: *** [cbtest] Error 1 Compilation exited abnormally with code 2 at Thu Aug 29 11:18:48 Can anyone tell me what I am doing wrong ? Using GNU gcc version 3.2 Looking forward to your responses. Best Regards, Charles Randle _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ------=_NextPart_000_3028_7b73_6a45 Content-Type: application/octet-stream; name="callback.hpp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="callback.hpp" I2lmICFkZWZpbmVkIChfX0NBTExCQUNLX18pCiNkZWZpbmUgICAgICAgX19D QUxMQkFDS19fCgojaW5jbHVkZSAiaW5jbHVkZS5ocHAiCiNpbmNsdWRlICJm YWlsdXJlLmhwcCIKCgpuYW1lc3BhY2UgeGd4X3N1cHBvcnQgewoKCiAgY2xh c3MgZ3hfY291bnRlZEJvZHkgewogIHB1YmxpYzoKICAgIGd4X2NvdW50ZWRC b2R5KCkgOiBjb3VudGVyKDApIHt9CiAgICB2aXJ0dWFsIH5neF9jb3VudGVk Qm9keSgpIHt9CiAgICB2b2lkIGluYygpIHRocm93KCkgeyBjb3VudGVyKys7 fQogICAgdm9pZCBkZWMoKSB0aHJvdygpIHsgY291bnRlci0tO30KICAgIHVu c2lnbmVkIGludCBjb3VudCgpIGNvbnN0IHRocm93KCkge3JldHVybiBjb3Vu dGVyO30KICBwcml2YXRlOgogICAgdW5zaWduZWQgaW50IGNvdW50ZXI7CiAg fTsKCgoKICBjbGFzcyBneF9jYWxsYmFja0Jhc2VCb2R5IDogcHVibGljIGd4 X2NvdW50ZWRCb2R5IHsKICBwdWJsaWM6CiAgICBneF9jYWxsYmFja0Jhc2VC b2R5KCkge30KICAgIHZpcnR1YWwgfmd4X2NhbGxiYWNrQmFzZUJvZHkoKSB7 fQogICAgdmlydHVhbCB2b2lkIG9wZXJhdG9yICgpKCkgY29uc3QgPSAwOwog IH07CgoKCiAgY2xhc3MgZ3hfY2FsbGJhY2sgewogIHB1YmxpYzoKCiAgICBn eF9jYWxsYmFjayhneF9jYWxsYmFja0Jhc2VCb2R5ICpwdHIpIDogZW50aXR5 KHB0cikge2luY0VudGl0eUNvdW50KCk7fQogICAgZ3hfY2FsbGJhY2soZ3hf Y2FsbGJhY2sgY29uc3QgJiBhcmcpIDogZW50aXR5KGFyZy5lbnRpdHkpIHtp bmNFbnRpdHlDb3VudCgpO30KICAgIH5neF9jYWxsYmFjaygpIHsgZGVjRW50 aXR5Q291bnQoKTtlbnRpdHkgPSAwO3JldHVybjt9CiAgICB2b2lkIG9wZXJh dG9yICgpKCkgeyAoKmVudGl0eSkoKTt9CiAgICB2b2lkIGluY0VudGl0eUNv dW50KCkgdGhyb3coKSB7ZW50aXR5LT5pbmMoKTtyZXR1cm47fQogICAgdm9p ZCBkZWNFbnRpdHlDb3VudCgpIHRocm93KCkge2VudGl0eS0+ZGVjKCk7aWYo IWVudGl0eS0+Y291bnQoKSkgZGVsZXRlIGVudGl0eTtyZXR1cm47fQoKICAg IHRlbXBsYXRlIDxjbGFzcyBDTElFTlQsY2xhc3MgQ0xJRU5UTUVNQkVSPgog ICAgc3RhdGljIGd4X2NhbGxiYWNrIG1ha2VfTTIoQ0xJRU5UICYsQ0xJRU5U TUVNQkVSICYpOwoKICAgIHRlbXBsYXRlIDxjbGFzcyBDTElFTlQsY2xhc3Mg Q0xJRU5UTUVNQkVSLGNsYXNzIFBBUkFNRVRFUj4KICAgIHN0YXRpYyBneF9j YWxsYmFjayBtYWtlX00zUChDTElFTlQgJixDTElFTlRNRU1CRVIgJixQQVJB TUVURVIgJik7CgogICAgdGVtcGxhdGUgPGNsYXNzIENMSUVOVCxjbGFzcyBD TElFTlRNRU1CRVIsY2xhc3MgUkVTVUxUPgogICAgc3RhdGljIGd4X2NhbGxi YWNrIG1ha2VfTTNSKENMSUVOVCAmLENMSUVOVE1FTUJFUiAmLFJFU1VMVCAm KTsKCiAgICB0ZW1wbGF0ZSA8Y2xhc3MgQ0xJRU5ULGNsYXNzIENMSUVOVE1F TUJFUixjbGFzcyBQQVJBTUVURVIsY2xhc3MgUkVTVUxUPgogICAgc3RhdGlj IGd4X2NhbGxiYWNrIG1ha2VfTTQoQ0xJRU5UICYsQ0xJRU5UTUVNQkVSICYs UEFSQU1FVEVSICYsUkVTVUxUICYpOwoKICAgIHRlbXBsYXRlIDxjbGFzcyBG VU5DVElPTj4KICAgIHN0YXRpYyBneF9jYWxsYmFjayBtYWtlX0YoRlVOQ1RJ T04gJik7CgogICAgdGVtcGxhdGUgPGNsYXNzIEZVTkNUSU9OLGNsYXNzIFBB UkFNRVRFUj4KICAgIHN0YXRpYyBneF9jYWxsYmFjayBtYWtlX0YyUChGVU5D VElPTiAmLFBBUkFNRVRFUiAmKTsKCiAgICB0ZW1wbGF0ZSA8Y2xhc3MgRlVO Q1RJT04sY2xhc3MgUkVTVUxUPgogICAgc3RhdGljIGd4X2NhbGxiYWNrIG1h a2VfRjJSKEZVTkNUSU9OICYsUkVTVUxUICYpOwoKICAgIHRlbXBsYXRlIDxj bGFzcyBGVU5DVElPTixjbGFzcyBQQVJBTUVURVIsY2xhc3MgUkVTVUxUPgog ICAgc3RhdGljIGd4X2NhbGxiYWNrIG1ha2VfRjMoRlVOQ1RJT04gJixQQVJB TUVURVIgJixSRVNVTFQgJik7CgogIHByaXZhdGU6CiAgICBneF9jYWxsYmFj a0Jhc2VCb2R5ICplbnRpdHk7CiAgfTsKCgoKICB0ZW1wbGF0ZSA8Y2xhc3Mg Q0xJRU5ULGNsYXNzIE1FTUJFUj4KICBjbGFzcyBneF9tZW1iZXJDQiA6IHB1 YmxpYyBneF9jYWxsYmFja0Jhc2VCb2R5IHsKICBwdWJsaWM6CiAgICBneF9t ZW1iZXJDQihDTElFTlQgJmNsbnQsTUVNQkVSICZjbG50bWVtKSA6IGNsaWVu dChjbG50KSxjbGllbnRtZW1iZXIoY2xudG1lbSkge30KICAgIHZpcnR1YWwg dm9pZCBvcGVyYXRvciAoKSAoKSB7ICgoJmNsaWVudCkgLT4qbWVtYmVyKSgp O30KCiAgcHJpdmF0ZToKICAgIENMSUVOVCAmY2xpZW50OwogICAgTUVNQkVS ICZjbGllbnRtZW1iZXI7CiAgfTsKCgoKICB0ZW1wbGF0ZSA8Y2xhc3MgQ0xJ RU5ULGNsYXNzIE1FTUJFUixjbGFzcyBQQVJBTUVURVI+CiAgY2xhc3MgZ3hf bWVtYmVyQ0JQIDogcHVibGljIGd4X2NhbGxiYWNrQmFzZUJvZHkgewogIHB1 YmxpYzoKICAgIGd4X21lbWJlckNCUChDTElFTlQgJmNsbnQsTUVNQkVSICZj bG50bWVtLFBBUkFNRVRFUiAmcGFybSkgOiBjbGllbnQoY2xudCksY2xpZW50 bWVtYmVyKGNsbnRtZW0pLHBhcmFtZXRlcihwYXJtKSB7fQogICAgdmlydHVh bCB2b2lkIG9wZXJhdG9yICgpICgpIHsgKCgmY2xpZW50KSAtPiptZW1iZXIp KHBhcmFtZXRlcik7fQoKICBwcml2YXRlOgogICAgQ0xJRU5UICZjbGllbnQ7 CiAgICBNRU1CRVIgJmNsaWVudG1lbWJlcjsKICAgIFBBUkFNRVRFUiAmcGFy YW1ldGVyOwogIH07CgoKCiAgdGVtcGxhdGUgPGNsYXNzIENMSUVOVCxjbGFz cyBNRU1CRVIsY2xhc3MgUkVTVUxUPgogIGNsYXNzIGd4X21lbWJlckNCUiA6 IHB1YmxpYyBneF9jYWxsYmFja0Jhc2VCb2R5IHsKICBwdWJsaWM6CiAgICBn eF9tZW1iZXJDQlIoQ0xJRU5UICZjbG50LE1FTUJFUiAmY2xudG1lbSxSRVNV TFQgJnJlcykgOiBjbGllbnQoY2xudCksY2xpZW50bWVtYmVyKGNsbnRtZW0p LHJlc3VsdChyZXMpIHt9CiAgICB2aXJ0dWFsIHZvaWQgb3BlcmF0b3IgKCkg KCkgeyAoKCZjbGllbnQpIC0+Km1lbWJlcikocmVzKTt9CgogIHByaXZhdGU6 CiAgICBDTElFTlQgJmNsaWVudDsKICAgIE1FTUJFUiAmY2xpZW50bWVtYmVy OwogICAgUkVTVUxUICZyZXN1bHQ7CiAgfTsKCgoKICB0ZW1wbGF0ZSA8Y2xh c3MgQ0xJRU5ULGNsYXNzIE1FTUJFUixjbGFzcyBQQVJBTUVURVIsY2xhc3Mg UkVTVUxUPgogIGNsYXNzIGd4X21lbWJlckNCUFIgOiBwdWJsaWMgZ3hfY2Fs bGJhY2tCYXNlQm9keSB7CiAgcHVibGljOgogICAgZ3hfbWVtYmVyQ0JQUihD TElFTlQgJmNsbnQsTUVNQkVSICZjbG50bWVtLFBBUkFNRVRFUiAmcGFybSxS RVNVTFQgJnJlcykgOiBjbGllbnQoY2xudCksY2xpZW50bWVtYmVyKGNsbnRt ZW0pLHBhcmFtZXRlcihwYXJtKSxyZXN1bHQocmVzKSB7fQogICAgdmlydHVh bCB2b2lkIG9wZXJhdG9yICgpICgpIHsgKHJlc3VsdCA9ICgmY2xpZW50KSAt PiptZW1iZXIpKHBhcmFtZXRlcik7fQoKICBwcml2YXRlOgogICAgQ0xJRU5U ICZjbGllbnQ7CiAgICBNRU1CRVIgJmNsaWVudG1lbWJlcjsKICAgIFBBUkFN RVRFUiAmcGFyYW1ldGVyOwogICAgUkVTVUxUICZyZXN1bHQ7CiAgfTsKCgoK ICB0ZW1wbGF0ZSA8Y2xhc3MgRlVOQ1RJT04+CiAgY2xhc3MgZ3hfZnVuY3Rp b25DQiA6IHB1YmxpYyBneF9jYWxsYmFja0Jhc2VCb2R5IHsKICBwdWJsaWM6 CiAgICBneF9mdW5jdGlvbkNCKEZVTkNUSU9OICZmdW5jKSA6IGZ1bmN0aW9u KGZ1bmMpIHt9CiAgICB2aXJ0dWFsIHZvaWQgb3BlcmF0b3IoKSAoKSB7IGZ1 bmN0aW9uKCk7fQoKICBwcml2YXRlOgogICAgRlVOQ1RJT04gJmZ1bmN0aW9u OwogIH07CgoKCiAgdGVtcGxhdGUgPGNsYXNzIEZVTkNUSU9OLGNsYXNzIFBB UkFNRVRFUj4KICBjbGFzcyBneF9mdW5jdGlvbkNCUCA6IHB1YmxpYyBneF9j YWxsYmFja0Jhc2VCb2R5IHsKICBwdWJsaWM6CiAgICBneF9mdW5jdGlvbkNC UChGVU5DVElPTiAmZnVuYyxQQVJBTUVURVIgJnBhcm0pIDogZnVuY3Rpb24o ZnVuYykscGFyYW1ldGVyKHBhcm0pIHt9CiAgICB2aXJ0dWFsIHZvaWQgb3Bl cmF0b3IoKSAoKSB7IGZ1bmN0aW9uKHBhcmFtZXRlcik7fQoKICBwcml2YXRl OgogICAgRlVOQ1RJT04gJmZ1bmN0aW9uOwogICAgUEFSQU1FVEVSICZwYXJh bWV0ZXI7CiAgfTsKCgoKICB0ZW1wbGF0ZSA8Y2xhc3MgRlVOQ1RJT04sY2xh c3MgUkVTVUxUPgogIGNsYXNzIGd4X2Z1bmN0aW9uQ0JSIDogcHVibGljIGd4 X2NhbGxiYWNrQmFzZUJvZHkgewogIHB1YmxpYzoKICAgIGd4X2Z1bmN0aW9u Q0JSKEZVTkNUSU9OICZmdW5jKSA6IGZ1bmN0aW9uKGZ1bmMpIHt9CiAgICB2 aXJ0dWFsIHZvaWQgb3BlcmF0b3IoKSAoKSB7IHJlc3VsdCA9IGZ1bmN0aW9u KCk7fQoKICBwcml2YXRlOgogICAgRlVOQ1RJT04gJmZ1bmN0aW9uOwogICAg UkVTVUxUICZyZXN1bHQ7CiAgfTsKCgoKICB0ZW1wbGF0ZSA8Y2xhc3MgRlVO Q1RJT04sY2xhc3MgUEFSQU1FVEVSLGNsYXNzIFJFU1VMVD4KICBjbGFzcyBn eF9mdW5jdGlvbkNCUFIgOiBwdWJsaWMgZ3hfY2FsbGJhY2tCYXNlQm9keSB7 CiAgcHVibGljOgogICAgZ3hfZnVuY3Rpb25DQlBSKEZVTkNUSU9OICZmdW5j LFBBUkFNRVRFUiAmcGFyYSxSRVNVTFQgJnJlcykgOiBmdW5jdGlvbihmdW5j KSxwYXJhbWV0ZXIocGFyYSkscmVzdWx0KHJlcykge30KICAgIHZpcnR1YWwg dm9pZCBvcGVyYXRvcigpICgpIHsgcmVzdWx0ID0gZnVuY3Rpb24ocGFyYW1l dGVyKTt9CgogIHByaXZhdGU6CiAgICBGVU5DVElPTiAmZnVuY3Rpb247CiAg ICBQQVJBTUVURVIgJnBhcmFtZXRlcjsKICAgIFJFU1VMVCAmcmVzdWx0Owog IH07CgoKCiAgdGVtcGxhdGUgPGNsYXNzIENMSUVOVCxjbGFzcyBDTElFTlRN RU1CRVI+CiAgZ3hfY2FsbGJhY2sgZ3hfY2FsbGJhY2s6Om1ha2VfTTIoQ0xJ RU5UICZjLENMSUVOVE1FTUJFUiAmY20pIHsKICAgIHJldHVybiBneF9jYWxs YmFjayhuZXcgZ3hfbWVtYmVyQ0I8Q0xJRU5ULENMSUVOVE1FTUJFUj4oYyxj bSkpOwogIH0KCiAgdGVtcGxhdGUgPGNsYXNzIENMSUVOVCxjbGFzcyBDTElF TlRNRU1CRVIsY2xhc3MgUEFSQU1FVEVSPgogIGd4X2NhbGxiYWNrIGd4X2Nh bGxiYWNrOjptYWtlX00zUChDTElFTlQgJmMsQ0xJRU5UTUVNQkVSICZjbSxQ QVJBTUVURVIgJnApIHsKICAgIHJldHVybiBneF9jYWxsYmFjayhuZXcgZ3hf bWVtYmVyQ0JQPENMSUVOVCxDTElFTlRNRU1CRVIsUEFSQU1FVEVSPihjLGNt LHApKTsKICB9CgogIHRlbXBsYXRlIDxjbGFzcyBDTElFTlQsY2xhc3MgQ0xJ RU5UTUVNQkVSLGNsYXNzIFJFU1VMVD4KICBneF9jYWxsYmFjayBneF9jYWxs YmFjazo6bWFrZV9NM1IoQ0xJRU5UICZjLENMSUVOVE1FTUJFUiAmY20sUkVT VUxUICZyKSB7CiAgICByZXR1cm4gZ3hfY2FsbGJhY2sobmV3IGd4X21lbWJl ckNCUjxDTElFTlQsQ0xJRU5UTUVNQkVSLFJFU1VMVD4oYyxjbSxyKSk7CiAg fQoKICB0ZW1wbGF0ZSA8Y2xhc3MgQ0xJRU5ULGNsYXNzIENMSUVOVE1FTUJF UixjbGFzcyBQQVJBTUVURVIsY2xhc3MgUkVTVUxUPgogIGd4X2NhbGxiYWNr IGd4X2NhbGxiYWNrOjptYWtlX000KENMSUVOVCAmYyxDTElFTlRNRU1CRVIg JmNtLFBBUkFNRVRFUiAmcCxSRVNVTFQgJnIpIHsKICAgIHJldHVybiBneF9j YWxsYmFjayhuZXcgZ3hfbWVtYmVyQ0JQUjxDTElFTlQsQ0xJRU5UTUVNQkVS LFBBUkFNRVRFUixSRVNVTFQ+KGMsY20scCxyKSk7CiAgfQoKICB0ZW1wbGF0 ZSA8Y2xhc3MgRlVOQ1RJT04+CiAgZ3hfY2FsbGJhY2sgZ3hfY2FsbGJhY2s6 Om1ha2VfRihGVU5DVElPTiAmZikgewogICAgcmV0dXJuIGd4X2NhbGxiYWNr KG5ldyBneF9mdW5jdGlvbkNCPEZVTkNUSU9OPihmKSk7CiAgfQoKICB0ZW1w bGF0ZSA8Y2xhc3MgRlVOQ1RJT04sY2xhc3MgUEFSQU1FVEVSPgogIGd4X2Nh bGxiYWNrIGd4X2NhbGxiYWNrOjptYWtlX0YyUChGVU5DVElPTiAmZixQQVJB TUVURVIgJnApIHsKICAgIHJldHVybiBneF9jYWxsYmFjayhuZXcgZ3hfZnVu Y3Rpb25DQlA8RlVOQ1RJT04sUEFSQU1FVEVSPihmLHApKTsKICB9CgogIHRl bXBsYXRlIDxjbGFzcyBGVU5DVElPTixjbGFzcyBSRVNVTFQ+CiAgZ3hfY2Fs bGJhY2sgZ3hfY2FsbGJhY2s6Om1ha2VfRjJSKEZVTkNUSU9OICZmLFJFU1VM VCAmcikgewogICAgcmV0dXJuIGd4X2NhbGxiYWNrKG5ldyBneF9mdW5jdGlv bkNCUjxGVU5DVElPTixSRVNVTFQ+KGYscikpOwogIH0KCiAgdGVtcGxhdGUg PGNsYXNzIEZVTkNUSU9OLGNsYXNzIFBBUkFNRVRFUixjbGFzcyBSRVNVTFQ+ CiAgZ3hfY2FsbGJhY2sgZ3hfY2FsbGJhY2s6Om1ha2VfRjMoRlVOQ1RJT04g JmYsUEFSQU1FVEVSICZyLFJFU1VMVCAmcCkgewogICAgcmV0dXJuIGd4X2Nh bGxiYWNrKG5ldyBneF9mdW5jdGlvbkNCUFI8RlVOQ1RJT04sUEFSQU1FVEVS LFJFU1VMVD4oZixwLHIpKTsKICB9CgoKfSAvL25hbWVzcGFjZSB4Z3hfc3Vw cG9ydAoKI2VuZGlmCg== ------=_NextPart_000_3028_7b73_6a45 Content-Type: application/octet-stream; name="cbtest.cpp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="cbtest.cpp" I2luY2x1ZGUgImNhbGxiYWNrLmhwcCIKCnVzaW5nIG5hbWVzcGFjZSB4Z3hf c3VwcG9ydDsKCmNsYXNzIEEgewpwdWJsaWM6CiAgQSgpe30KICB+QSgpe30K ICB2b2lkIG5vcmV0c25vYXJncygpIHs6OnN0ZDo6Y2VyciA8PCAiTk8gcmV0 dXJucyAmIE5vIEFyZ3MgISEiIDw8IDo6c3RkOjplbmRsO3JldHVybjt9CiAg dm9pZCBub3JldHNhcmdzKGludCBjdikgezo6c3RkOjpjZXJyIDw8ICJOTyBy ZXR1cm5zICYgQXJncyA9ICIgPDwgY3YgPDwgIiAhISIgPDwgOjpzdGQ6OmVu ZGw7cmV0dXJuO30KICBpbnQgIHJldHNub2FyZ3MoKSB7OjpzdGQ6OmNlcnIg PDwgIk5PIHJldHVybnMgJiBObyBBcmdzICEhIiA8PCA6OnN0ZDo6ZW5kbDty ZXR1cm4gNTY7fQogIGludCAgcmV0c2FyZ3MoaW50IGN2KSB7OjpzdGQ6OmNl cnIgPDwgInJldHVybnMgJiBBcmdzID0gIiA8PCBjdiA8PCAiISEiIDw8IDo6 c3RkOjplbmRsO3JldHVybiA1Njt9Cn07CgoKaW50IG1haW4gKGludCBhcmdj LGNoYXIgY29uc3QgKiBjb25zdCAqIGNvbnN0IGFyZ3YpIHsKCiAgQSBvYmpl Y3RBOwoKICBneF9jYWxsYmFjayB0ZXN0MSAoZ3hfY2FsbGJhY2s6Om1ha2Vf TTIob2JqZWN0QSwmQTo6bm9yZXRzbm9hcmdzKSk7CiAgLyoKZ3hfY2FsbGJh Y2sgdGVzdDIgPQpneF9jYWxsYmFjayB0ZXN0MyA9Cmd4X2NhbGxiYWNrIHRl c3Q0ID0KICAqLwoKICAvLyBFeGVjdXRlIG9iamVjdCAKICB0ZXN0MSgpOwp9 Cgo= ------=_NextPart_000_3028_7b73_6a45-- From quang@tapeware.com Fri Aug 30 03:35:27 2002 Received: from mail by ftoomsh.progsoc.uts.edu.au with spam-scanned (Exim 3.35 #1 (Debian)) id 17kTCU-0007qT-00 for ; Fri, 30 Aug 2002 03:35:27 +1000 Received: from mail15.messagelabs.com ([63.210.62.243]) by ftoomsh.progsoc.uts.edu.au with smtp (Exim 3.35 #1 (Debian)) id 17kTCT-0007qM-00 for ; Fri, 30 Aug 2002 03:35:21 +1000 X-VirusChecked: Checked Received: (qmail 27942 invoked from network); 29 Aug 2002 17:35:11 -0000 Received: from mail.tapeware.com (HELO yt-internet.tapeware.com) (4.21.59.10) by server-6.tower-15.messagelabs.com with SMTP; 29 Aug 2002 17:35:11 -0000 Received: from hanoi.tapeware.com (192.168.0.125 [192.168.0.125]) by yt-internet.tapeware.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RXZFLGJL; Thu, 29 Aug 2002 10:35:23 -0700 Content-Type: text/plain; charset="iso-8859-1" From: "Quang Nguyen (Ngo)" To: tuxcpprogramming@lists.linux.org.au, Dr Mark H Phillips Subject: Re: [LC++]Producing a log of routine entry and exit X-Mailer: KMail [version 1.4] References: <1030606341.24586.2737.camel@research> In-Reply-To: <1030606341.24586.2737.camel@research> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200208291036.06567.quang@tapeware.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: tuxcpprogramming-admin@lists.linux.org.au Errors-To: tuxcpprogramming-admin@lists.linux.org.au X-BeenThere: tuxcpprogramming@lists.linux.org.au X-Mailman-Version: 2.0.3 Precedence: bulk Reply-To: tuxcpprogramming@lists.linux.org.au List-Help: List-Post: List-Subscribe: , List-Id: The Linux C++ Programming List List-Unsubscribe: , List-Archive: Date: Fri Aug 30 03:36:07 2002 X-Original-Date: Thu, 29 Aug 2002 10:36:06 +0000 I would recommend using some kind of macros to handle logging/tracing, fo= r=20 example: #if DEBUG #define TRACE0(x,msg)=09=09=09MyTraceFunc(x,msg) #define TRACE1(x,msg,p1)=09=09MyTraceFunc(x,msg,p1) #define TRACE2(x,msg,p1,p2)=09=09MyTraceFunc(x,msg,p1,p2) #define .... #else #define TRACE0(x,msg) #define TRACE1(x,msg,p1) ... #endif x =3D trace mask value so you can filter out certain trace messages p1 =3D parameter 1 p2 =3D parameter 2 etc... void MyTraceFunc(unsigned int traceType, const char *msgFormat, ...) { =09va_list ap; =09va_start(ap, msgFormat); =09switch (traceType) =09{ =09=09case TTYPE_ERROR: =09=09=09vprintf(...); =09=09=09or vsnprintf(...), etc... =09=09=09blah, blah... =09=09=09break; =09=09case TTYTPE_CRITICAL: =09=09=09blah, blah... =09=09=09break; =09.=09default: =09=09=09... =09=09=09break; =09} =09va_end(ap); } Just some idea... -- Quang =09 On Thursday 29 August 2002 07:32 am, Dr Mark H Phillips wrote: > Hi, > > For debugging purposes, I wished to provide a standard means of > logging the entry into, and exit from, each of my routines. This > log should give the name of the routine, and calling signature. > On entry it should print the input parameters, and on exit, the > output parameters. > > My current way of doing this is like this: > > int myRoutine(string& retString, int a, char b) { > cout<<"entering myRoutine(string&, int, char)\n" > <<" second param: "< <<" third param: "< int ret; > > // do stuff here > // including some things like "goto preExit;" > > preExit: > cout<<"exiting myRoutine(string&, int, char)\n" > <<" first param: "< <<" return: "< return ret; > } > > The problem with this is that it requires the use of gotos > which generally should be avoided. It also means I can't > create any objects "on the fly" before preExit, or I get > an error like: > > parsing.h: In function `bool moat::getToken(int &, string &)': > parsing.h:277: jump to label `preExit' > parsing.h:248: from here > parsing.h:274: crosses initialization of `class string myString' > > Now I can think of a range of alternative solutions to this > kind of logging, but they each have their drawbacks: > > 1. Same as above, but replace every instance of "goto preExit;" > with a local copy of the code that currently follows preExit. This > would eliminate gotos, but would make routines very verbose, and > would be wasteful, both in terms of program size, and in terms of > program writing and maintenance. > > 2. Create general routines "entryLog(...)" and "exitLog(...)". Call > entryLog(...) at the start. Then do as in 1, except that "goto preExit= " > is replaced by a call to exitLog(...). This is less wasteful than 1, > but still somewhat so. And the parameters of these calls need to be > very general to cater for all kinds of uses - very tricky to get right, > and involving lots of template variables and function overloading. > > 3. Create a "RoutineLogger" object, instanciated at the beginning of > its routine, and told information about the routine it is responsible > for logging. It has the same scope as the routine it is representing, > so it will be destructed just before the routine exits. In this way > it will automatically be called at the right time without the need for > gotos. This solution sounds really good, except it's very hard to > properly pass it the information needed so it can log properly. > > > Any thoughts? > > Cheers, > > Mark. ________________________________________________________________________ This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Mes= sageLabs=20SkyScan service.=20For=20more=20information=20on=20a=20proactive=20anti-virus=20se= rvice=20working around=20the=20clock,=20around=20the=20globe,=20visit=20http://www.message= labs.com ________________________________________________________________________ From kschin@unf.edu Fri Aug 30 03:53:43 2002 Received: from mail by ftoomsh.progsoc.uts.edu.au with spam-scanned (Exim 3.35 #1 (Debian)) id 17kTUC-00085r-00 for ; Fri, 30 Aug 2002 03:53:42 +1000 Received: from osprey.unf.edu ([139.62.200.198]) by ftoomsh.progsoc.uts.edu.au with esmtp (Exim 3.35 #1 (Debian)) id 17kTUB-00085o-00 for ; Fri, 30 Aug 2002 03:53:39 +1000 Received: from osprey.unf.edu (localhost [127.0.0.1]) by osprey.unf.edu (8.12.1/8.12.1) with ESMTP id g7THrSGL018502; Thu, 29 Aug 2002 13:53:28 -0400 Received: from localhost (kschin@localhost) by osprey.unf.edu (8.12.1/8.12.1/Submit) with ESMTP id g7THrNih018496; Thu, 29 Aug 2002 13:53:23 -0400 X-Authentication-Warning: osprey.unf.edu: kschin owned process doing -bs From: Keith Schincke To: tuxcpprogramming@lists.linux.org.au cc: Dr Mark H Phillips Subject: Re: [LC++]Producing a log of routine entry and exit In-Reply-To: <200208291036.06567.quang@tapeware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: tuxcpprogramming-admin@lists.linux.org.au Errors-To: tuxcpprogramming-admin@lists.linux.org.au X-BeenThere: tuxcpprogramming@lists.linux.org.au X-Mailman-Version: 2.0.3 Precedence: bulk Reply-To: tuxcpprogramming@lists.linux.org.au List-Help: List-Post: List-Subscribe: , List-Id: The Linux C++ Programming List List-Unsubscribe: , List-Archive: Date: Fri Aug 30 03:56:05 2002 X-Original-Date: Thu, 29 Aug 2002 13:53:23 -0400 (EDT) I have borrowed the debuging macro's from the pam system on Linux. It gives good messages that help in tracing and debuging code. With a little bit of modification, you can generate debug messages for various levels of debuging. I kept mine simple. The code from one of my header files follow below the sig but the usage is easy. Ex: D(("Check variable = %d",check_var)); produces [main.c:main(15)] Check variable = 55 I often add D(("called")) to the top and bottom of functions of interest to see if they are being called and are returning Hope this and the other suggestions help. -- Keith Schincke My dawg is always with me. Jacksonville, Fl 00 Spool - Wild at Heart http://www.unf.edu/~kschin Email: kschin@unf.edu #ifdef DEBUG #include static void _pam_output_debug_info(const char *file, const char *fn , const int line) { fprintf(stderr,"[%s:%s(%d)] ",file, fn, line); } static void _pam_output_debug(const char *format, ...) { va_list args; FILE *logfile; int must_close = 1; va_start(args, format); vfprintf(stderr, format, args); fprintf(stderr, "\n"); va_end(args); } #define D(x) do { \ _pam_output_debug_info(__FILE__, __FUNCTION__, __LINE__); \ _pam_output_debug x ; \ } while (0) #else #define D(x) do { } while (0) #endif From carlo@alinoe.com Fri Aug 30 12:10:12 2002 Received: from mail by ftoomsh.progsoc.uts.edu.au with spam-scanned (Exim 3.35 #1 (Debian)) id 17kbEb-00072G-00 for ; Fri, 30 Aug 2002 12:10:11 +1000 Received: from node1500a.a2000.nl ([24.132.80.10] helo=mail.alinoe.com ident=qmailr) by ftoomsh.progsoc.uts.edu.au with smtp (Exim 3.35 #1 (Debian)) id 17kbEZ-00071r-00 for ; Fri, 30 Aug 2002 12:10:03 +1000 Received: (qmail 2922 invoked by uid 500); 30 Aug 2002 02:09:55 -0000 From: Carlo Wood To: tuxcpprogramming@lists.linux.org.au Subject: Re: [LC++]Producing a log of routine entry and exit Message-ID: <20020830040955.A29006@alinoe.com> Mail-Followup-To: Carlo Wood , tuxcpprogramming@lists.linux.org.au References: <200208291036.06567.quang@tapeware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from kschin@unf.edu on Thu, Aug 29, 2002 at 01:53:23PM -0400 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: tuxcpprogramming-admin@lists.linux.org.au Errors-To: tuxcpprogramming-admin@lists.linux.org.au X-BeenThere: tuxcpprogramming@lists.linux.org.au X-Mailman-Version: 2.0.3 Precedence: bulk Reply-To: tuxcpprogramming@lists.linux.org.au List-Help: List-Post: List-Subscribe: , List-Id: The Linux C++ Programming List List-Unsubscribe: , List-Archive: Date: Fri Aug 30 12:11:10 2002 X-Original-Date: Fri, 30 Aug 2002 04:09:55 +0200 On Thu, Aug 29, 2002 at 01:53:23PM -0400, Keith Schincke wrote: > I have borrowed the debuging macro's from the pam system on Linux. It Or you could go for the Real Deal and use libcwd. http://libcwd.sourceforge.net/ libcwd is written for (and in) C++, it supports ostreams. -- Carlo Wood From mark@austrics.com.au Fri Aug 30 14:42:43 2002 Received: from mail by ftoomsh.progsoc.uts.edu.au with spam-scanned (Exim 3.35 #1 (Debian)) id 17kdcF-0000mW-00 for ; Fri, 30 Aug 2002 14:42:43 +1000 Received: from fw.austrics.com.au ([150.101.99.165] ident=postfix) by ftoomsh.progsoc.uts.edu.au with esmtp (Exim 3.35 #1 (Debian)) id 17kdcD-0000mS-00 for ; Fri, 30 Aug 2002 14:42:37 +1000 Received: from blaze.lan.austrics.com.au (blaze.lan.austrics.com.au [192.168.1.2]) by fw.austrics.com.au (Postfix) with ESMTP id 0830C126EFB for ; Fri, 30 Aug 2002 14:12:36 +0930 (CST) Received: from localhost.localdomain (mark@research [192.168.1.36]) by blaze.lan.austrics.com.au (8.9.2/8.9.2) with ESMTP id OAA11062 for ; Fri, 30 Aug 2002 14:17:13 +0930 (CST) Subject: Re: [LC++]Producing a log of routine entry and exit From: Dr Mark H Phillips To: Tux C++ Programming In-Reply-To: <20020830040955.A29006@alinoe.com> References: <200208291036.06567.quang@tapeware.com> <20020830040955.A29006@alinoe.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Message-Id: <1030682714.1733.83.camel@research> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: tuxcpprogramming-admin@lists.linux.org.au Errors-To: tuxcpprogramming-admin@lists.linux.org.au X-BeenThere: tuxcpprogramming@lists.linux.org.au X-Mailman-Version: 2.0.3 Precedence: bulk Reply-To: tuxcpprogramming@lists.linux.org.au List-Help: List-Post: List-Subscribe: , List-Id: The Linux C++ Programming List List-Unsubscribe: , List-Archive: Date: Fri Aug 30 14:46:19 2002 X-Original-Date: 30 Aug 2002 14:15:10 +0930 On Fri, 2002-08-30 at 11:39, Carlo Wood wrote: > Or you could go for the Real Deal and use libcwd. > http://libcwd.sourceforge.net/ > > libcwd is written for (and in) C++, it supports ostreams. Hi Carlo, I am going through the tutorial for libcwd and found this quote from the FAQ: "Any project should have one header file that is included at the top of every source file. If you already have one then you can add #include to that file. Otherwise you should add such a header file: its a Good Thing(tm) to have." Am I right in thinking this is something you wrote? If so, could you please explain the reasons why it is a "Good Thing(tm)". Thanks, Mark. -- Dr Mark H Phillips Research Analyst (Mathematician) AUSTRICS - smarter scheduling solutions - www.austrics.com Level 2, 50 Pirie Street, Adelaide SA 5000, Australia Phone +61 8 8226 9850 Fax +61 8 8231 4821 Email mark@austrics.com.au From carlo@alinoe.com Fri Aug 30 21:51:54 2002 Received: from mail by ftoomsh.progsoc.uts.edu.au with spam-scanned (Exim 3.35 #1 (Debian)) id 17kkJa-00079P-00 for ; Fri, 30 Aug 2002 21:51:54 +1000 Received: from node1500a.a2000.nl ([24.132.80.10] helo=mail.alinoe.com ident=qmailr) by ftoomsh.progsoc.uts.edu.au with smtp (Exim 3.35 #1 (Debian)) id 17kkJX-00079M-00 for ; Fri, 30 Aug 2002 21:51:49 +1000 Received: (qmail 26774 invoked by uid 500); 30 Aug 2002 11:51:42 -0000 From: Carlo Wood To: tuxcpprogramming@lists.linux.org.au Subject: Re: [LC++]Producing a log of routine entry and exit Message-ID: <20020830135142.A24315@alinoe.com> Mail-Followup-To: Carlo Wood , tuxcpprogramming@lists.linux.org.au References: <200208291036.06567.quang@tapeware.com> <20020830040955.A29006@alinoe.com> <1030682714.1733.83.camel@research> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1030682714.1733.83.camel@research>; from mark@austrics.com.au on Fri, Aug 30, 2002 at 02:15:10PM +0930 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: tuxcpprogramming-admin@lists.linux.org.au Errors-To: tuxcpprogramming-admin@lists.linux.org.au X-BeenThere: tuxcpprogramming@lists.linux.org.au X-Mailman-Version: 2.0.3 Precedence: bulk Reply-To: tuxcpprogramming@lists.linux.org.au List-Help: List-Post: List-Subscribe: , List-Id: The Linux C++ Programming List List-Unsubscribe: , List-Archive: Date: Fri Aug 30 21:56:08 2002 X-Original-Date: Fri, 30 Aug 2002 13:51:42 +0200 On Fri, Aug 30, 2002 at 02:15:10PM +0930, Dr Mark H Phillips wrote: > I am going through the tutorial for libcwd and found this > quote from the FAQ: > > "Any project should have one header file that is included at the top of > every source file. If you already have one then you can add #include > to that file. Otherwise you should add such a header > file: its a Good Thing(tm) to have." > > Am I right in thinking this is something you wrote? If so, could you > please explain the reasons why it is a "Good Thing(tm)". Out of many many years of experience. It turns out that often you need something that is not directly related to your application but has external reasons. The most common reason is porting (differences between OS). It is a Good Thing to have those things at one place, in one header file - so it stays maintainable and surveyable. Code duplication is bad in general :). Furthermore it turns out having this header _standard_ at the *start* of each source file, before ANY system header file is included, gives you much more power to use it for Operating System differences. Finally, there is no good reason not to do it :p. Just like adding a license header to each file, and #ifndef MYAPP_HEADENAME_H #define MYAPP_HEADENAME_H ... #endif // MYAPP_HEADENAME_H is standard for every header file; it will pay back if you get used to starting each source (.cc, .cpp) file with: #include "sys.h" Examples of stuff that can go into such a file are given below. Please realize these ONLY *EXAMPLES* - what you will ACTUALLY add to it will be very project specific, despite that all of this is somehow not really related to the project. // autoconf dependency #ifdef HAVE_CONFIG_H #include "config.h" #endif // libcwd dependency #ifdef CWDEBUG #ifndef _GNU_SOURCE #define _GNU_SOURCE #endif #include #endif // Use __attribute__((noreturn)) but support compilers that don't have it // Functions whose use force me to use a return type but never return // now will look like: // int foo() __attribute__ ((noreturn)); // int foo() // { // this_function_never_return(); // NEED_FAKE_RETURN(0); // Avoid compiler warning // } #ifdef __GNUC__ #if (__GNUC__ < 2) || (__GNUC__ == 2 && __GNUC_MINOR__ < 7) #define NO_ATTRIBUTE #endif #else // !__GNUC__ // No attributes if we don't have gcc-2.7 or higher #define NO_ATTRIBUTE #endif // !__GNUC__ #if defined(NO_ATTRIBUTE) && !defined(__attribute__) #define __attribute__(x) #define NEED_FAKE_RETURN(x) return x; #endif #ifndef NEED_FAKE_RETURN #define NEED_FAKE_RETURN(x) #endif // Definition of macros used to add a ident string to each file: #ifndef RCSTAG_CC #define RCSTAG_CC(string) static char rcs_ident[] __attribute__ ((__unused__)) = string; #endif #ifndef RCSTAG_H #define RCSTAG_H(name, string) static char const rcs_ident_##name##_h[] __attribute__ ((__unused__)) = string; #endif #ifndef RCSTAG_INL #define RCSTAG_INL(name, string) static char rcs_ident##name##_inl[] __attribute__ ((__unused__)) = string; #endif // Use __restrict keyword, but support compilers that don't have it #if __GNUC__ == 2 && __GNUC_MINOR__ < 96 #define __restrict /*ignore*/ #endif // This is to avoid warnings like: // /usr/include/g++-3/iostream.h:253:5: "_G_CLOG_CONFLICT" is not defined #define NEED_G_CONFIG_H_MACROS #ifdef NEED_G_CONFIG_H_MACROS #include <_G_config.h> #ifndef _G_CLOG_CONFLICT #define _G_CLOG_CONFLICT 0 #endif #ifndef _G_HAS_LABS #define _G_HAS_LABS 1 #endif #endif ... Well, you get the idea. -- Carlo Wood From charlesrandle@yahoo.com Sat Aug 31 01:47:48 2002 Received: from mail by ftoomsh.progsoc.uts.edu.au with spam-scanned (Exim 3.35 #1 (Debian)) id 17knzs-0002Cm-00 for ; Sat, 31 Aug 2002 01:47:48 +1000 Received: from web13108.mail.yahoo.com ([216.136.174.153]) by ftoomsh.progsoc.uts.edu.au with smtp (Exim 3.35 #1 (Debian)) id 17knzs-0002Cj-00 for ; Sat, 31 Aug 2002 01:47:44 +1000 Message-ID: <20020830154726.47185.qmail@web13108.mail.yahoo.com> Received: from [208.163.62.10] by web13108.mail.yahoo.com via HTTP; Fri, 30 Aug 2002 08:47:26 PDT From: Charles Randle To: tuxcpprogramming@lists.linux.org.au MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Subject: [LC++]C++ Template Instantiation problems Sender: tuxcpprogramming-admin@lists.linux.org.au Errors-To: tuxcpprogramming-admin@lists.linux.org.au X-BeenThere: tuxcpprogramming@lists.linux.org.au X-Mailman-Version: 2.0.3 Precedence: bulk Reply-To: tuxcpprogramming@lists.linux.org.au List-Help: List-Post: List-Subscribe: , List-Id: The Linux C++ Programming List List-Unsubscribe: , List-Archive: Date: Sat Aug 31 01:51:05 2002 X-Original-Date: Fri, 30 Aug 2002 08:47:26 -0700 (PDT) Hi All, This is a repost due to an email address change : I have the following code : #include class gx_callbackBaseBody { public: gx_callbackBaseBody() {} virtual ~gx_callbackBaseBody() {} virtual void operator ()() const = 0; }; class gx_callback { public: gx_callback(gx_callbackBaseBody *ptr) : entity(ptr) {} gx_callback(gx_callback const & arg) : entity(arg.entity) {} ~gx_callback() { delete entity;entity = 0;return;} void operator ()() { (*entity)();} template static gx_callback make_M2(CLIENT &,CLIENTMEMBER &); private: gx_callbackBaseBody *entity; }; template class gx_memberCB : public gx_callbackBaseBody { public: gx_memberCB(CLIENT &clnt,MEMBER &clntmem) : client(clnt),clientmember(clntmem) {} virtual void operator () () { ((&client) ->*member)();} private: CLIENT &client; MEMBER &clientmember; }; template gx_callback gx_callback::make_M2(CLIENT &c,CLIENTMEMBER &cm) { return gx_callback(new gx_memberCB(c,cm)); } class A { public: A(){} ~A(){} void noretsnoargs() {::std::cerr << "NO returns & No Args !!" << ::std::endl;return;} }; int main (int argc,char const * const * const argv) { A objectA; gx_callback test1 (gx_callback::make_M2(objectA,&A::noretsnoargs)); // // Execute object test1(); } Which gives the following error on compilation: g++ cbtest.cpp -o cbtest cbtest.cpp: In function `int main(int, const char* const*)': cbtest.cpp:62: no matching function for call to `gx_callback::make_M2(A&, void (A::*)())' cbtest.cpp:42: candidates are: static gx_callback gx_callback::make_M2(CLIENT&, CLIENTMEMBER&) [with CLIENT = A, CLIENTMEMBER = void (A::*)()] make: *** [cbtest] Error 1 Can anyone explain this and possibly suggest a solution. Best Regards, Charles Randle __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com From verthan at miel.mot.com Mon Aug 5 21:11:32 2002 From: verthan at miel.mot.com (Goverthanan) Date: Mon Aug 5 21:11:32 2002 Subject: [LC++]sizeof... In-Reply-To: Message-ID: <000501c238c4$2bf22470$767d01d9@miel.mot.com> RE: [LC++]Scoping questionHi, Can anyone tell me whats the alternative for sizeof function i can use to get the size of the variable... Rgds. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux.org.au/pipermail/tuxcpprogramming/attachments/20020805/165298a1/attachment.htm From lloy0076 at rebel.net.au Mon Aug 5 22:06:25 2002 From: lloy0076 at rebel.net.au (David Lloyd) Date: Mon Aug 5 22:06:25 2002 Subject: [LC++]List Information Message-ID: <3D4E685D.457944EB@rebel.net.au> It appears that the list servers went down and that noone actually noticed it until I pointed out that these lists were not working. I don't host these lists and I am currently evaluating whether I should shift the lists (again) or wait to see whether the list servers become stable again. I apologise for the downtime. DSL -- We are not the United States' ally We are the 53rd sovereign state of the Federation From ianezz at kinsale.sodalia.it Mon Aug 5 22:56:08 2002 From: ianezz at kinsale.sodalia.it (ianezz at kinsale.sodalia.it) Date: Mon Aug 5 22:56:08 2002 Subject: [LC++]sizeof... In-Reply-To: <000501c238c4$2bf22470$767d01d9@miel.mot.com> References: <000501c238c4$2bf22470$767d01d9@miel.mot.com> Message-ID: <15694.33767.584682.557143@kinsale.sodalia.it> Goverthanan, pigiando tasti a caso sul citofono, ha scritto: > Can anyone tell me whats the alternative for sizeof function i can > use to get the size of the variable... sizeof() is an operator of the language, not a function, and unless you know in advance how many bytes a certain type requires, there's no way around it (i.e. only the compiler knows -- this is true expecially for structs and classes). May I ask you why are you trying to avoid using sizeof()? -- | \ \ | ___|_ |_ | ianezz AT sodalia.it | _ \ | \ | _| / / Visita il LinuxTrent a _|_/ _\_| _|____|___|___| http://www.linuxtrent.it From psasi at corp.untd.com Mon Aug 5 23:11:05 2002 From: psasi at corp.untd.com (Palaka, Sasidhar) Date: Mon Aug 5 23:11:05 2002 Subject: [LC++]sizeof... Message-ID: How about implementing this way, Say, you want to know the size of 'char'. Look at the following skeleton code. char* p; char* q, q = p+1; return q-p; Basically the idea is to increment the pointer and then subtract to give the size. -----Original Message----- From: ianezz at kinsale.sodalia.it [mailto:ianezz at kinsale.sodalia.it] Sent: Monday, August 05, 2002 7:26 PM To: tuxcpprogramming at lists.linux.org.au Subject: Re: [LC++]sizeof... Goverthanan, pigiando tasti a caso sul citofono, ha scritto: > Can anyone tell me whats the alternative for sizeof function i can > use to get the size of the variable... sizeof() is an operator of the language, not a function, and unless you know in advance how many bytes a certain type requires, there's no way around it (i.e. only the compiler knows -- this is true expecially for structs and classes). May I ask you why are you trying to avoid using sizeof()? -- | \ \ | ___|_ |_ | ianezz AT sodalia.it | _ \ | \ | _| / / Visita il LinuxTrent a _|_/ _\_| _|____|___|___| http://www.linuxtrent.it _______________________________________________ This is the Linux C++ Programming List : http://lists.linux.org.au/listinfo/tuxcpprogramming List From ianezz at kinsale.sodalia.it Tue Aug 6 00:21:05 2002 From: ianezz at kinsale.sodalia.it (ianezz at kinsale.sodalia.it) Date: Tue Aug 6 00:21:05 2002 Subject: [LC++]sizeof... In-Reply-To: References: Message-ID: <15694.38788.667595.289442@kinsale.sodalia.it> Palaka, Sasidhar, pigiando tasti a caso sul citofono, ha scritto: > Basically the idea is to increment the pointer and then subtract to give the > size. Try it with an `int'... the difference between pointers is in bytes/sizeof(pointed type)... so it gives back always `1'. Of course you could try casting the pointers to some unsigned type large enough before subtracting them, but then how do you know how much is ``large enough''? Use sizeof() and live in peace. -- | \ \ | ___|_ |_ | ianezz AT sodalia.it | _ \ | \ | _| / / Visita il LinuxTrent a _|_/ _\_| _|____|___|___| http://www.linuxtrent.it From psasi at corp.untd.com Tue Aug 6 01:01:05 2002 From: psasi at corp.untd.com (Palaka, Sasidhar) Date: Tue Aug 6 01:01:05 2002 Subject: [LC++]sizeof... Message-ID: Hi, Thanks for correcting me, you are right. I missed out that type casting part. But, say if I am interested in implementing 'sizeof' as an exercise question, Is there any other way out apart from what I suggested? Thanks, Sasi. -----Original Message----- From: ianezz at kinsale.sodalia.it [mailto:ianezz at kinsale.sodalia.it] Sent: Monday, August 05, 2002 8:50 PM To: tuxcpprogramming at lists.linux.org.au Subject: RE: [LC++]sizeof... Palaka, Sasidhar, pigiando tasti a caso sul citofono, ha scritto: > Basically the idea is to increment the pointer and then subtract to give the > size. Try it with an `int'... the difference between pointers is in bytes/sizeof(pointed type)... so it gives back always `1'. Of course you could try casting the pointers to some unsigned type large enough before subtracting them, but then how do you know how much is ``large enough''? Use sizeof() and live in peace. -- | \ \ | ___|_ |_ | ianezz AT sodalia.it | _ \ | \ | _| / / Visita il LinuxTrent a _|_/ _\_| _|____|___|___| http://www.linuxtrent.it _______________________________________________ This is the Linux C++ Programming List : http://lists.linux.org.au/listinfo/tuxcpprogramming List From ianezz at kinsale.sodalia.it Tue Aug 6 01:26:05 2002 From: ianezz at kinsale.sodalia.it (ianezz at kinsale.sodalia.it) Date: Tue Aug 6 01:26:05 2002 Subject: [LC++]sizeof... In-Reply-To: References: Message-ID: <15694.42703.9252.717183@kinsale.sodalia.it> Usando la tastiera di Palaka, Sasidhar, uno sconosciuto ha scritto: > But, say if I am interested in implementing 'sizeof' as an exercise > question, > Is there any other way out apart from what I suggested? Well, you could try int * p; int * q; q = p + 1; return (unsigned long)q - (unsigned long)p; assuming that strange things don't happen when casting a pointer into an unsigned long. Or even int * p; int * q; q = p + 1; return (char *)q - (char *)p; since sizeof(char) should always be 1 byte. -- | \ \ | ___|_ |_ | ianezz AT sodalia.it | _ \ | \ | _| / / Visita il LinuxTrent a _|_/ _\_| _|____|___|___| http://www.linuxtrent.it From lloyd at acm.jhu.edu Sat Aug 17 03:01:05 2002 From: lloyd at acm.jhu.edu (Jack Lloyd) Date: Sat Aug 17 03:01:05 2002 Subject: [LC++]Impressions of ACE? Message-ID: Hi, Has anyone here used ACE (http://www.cs.wustl.edu/~schmidt/ACE-overview.html)? Any impressions? I've heard many people like it. Looking at the tutorials, I'm somewhat disapoined that it doesn't use namespaces (I guess it's been around too long for that), and the ACE_XXX_RETURN stuff seems rather odd (I can't believe ACE doesn't use exceptions given it's heavy use of templates). But, OTOH, I haven't heard about any similiar C++ networking abstraction libraries (that are free (preferably BSD or LGPL), portable, and stable). So if anyone has any knowledge of any... -Jack From Torsten at Rennett.de Sat Aug 17 19:11:06 2002 From: Torsten at Rennett.de (Torsten Rennett) Date: Sat Aug 17 19:11:06 2002 Subject: [LC++]Impressions of ACE? References: Message-ID: <3D5E11D9.F668961B@Rennett.de> Hi Jack, Jack Lloyd wrote: > > Hi, > > Has anyone here used ACE > (http://www.cs.wustl.edu/~schmidt/ACE-overview.html)? Any impressions? I've I'm currently using ACE in a Client/Server-Project and I'm really satisfied. Thanks to the portability of ACE the program is running on Linux and NCR Unix (AT&T) and the Clients also on Windows NT and Windows 2000. To compile the Clients under Windows (same source code as for Unix with some #ifdefs) I used gcc-2.95.3 and MinGW. Some adjustments were necessary but now it runs fine. > heard many people like it. Looking at the tutorials, I'm somewhat > disapoined that it doesn't use namespaces (I guess it's been around too > long for that), and the ACE_XXX_RETURN stuff seems rather odd (I can't > believe ACE doesn't use exceptions given it's heavy use of templates). I think the documentation of ACE could be a bit better. But now there is a new book about ACE: Douglas C. Schmidt and Stephen D. Huston: "C++ Network Programming, Volume I: Mastering Complexity with ACE and Patterns" Addison Wesley, 2002; C++ In-Depth Series ISBN: 0-201-60464-7 http://www.awprofessional.com/catalog/product.asp?product_id={1E34F487-4285-4C05-9BF9-B55195F3C83F} Upcoming ACE publications: - "Volume II: Systematic Reuse with ACE and Frameworks" (Addison Wesley) - "The ACE programmer's Guide" (Addison Wesley) And also the following might be of interest: Douglas Schmidt, Michael Stal, Hans Rohnert, Frank Buschmann: "Pattern-oriented Software Architecture Vol 2: Patterns for Concurrent and Networked Objects" John Wiley and Sons, 15. August 2000 ISBN: 0471606952 > But, OTOH, I haven't heard about any similiar C++ networking abstraction > libraries (that are free (preferably BSD or LGPL), portable, and stable). > So if anyone has any knowledge of any... IMHO there is no alternative to ACE if you are programming in C++. If you have to develop a distributed network application using CORBA also consider using TAO - The ACE ORB. Torsten -- Ingenieurbuero RENNETT -- innovative Software-Entwicklung -- Torsten Rennett Ludwig-Thoma-Weg 14 E-Mail: mailto:Torsten at Rennett.de D-85551 Heimstetten Telefon: +49-89-90480538 From mark at austrics.com.au Thu Aug 29 17:31:06 2002 From: mark at austrics.com.au (Dr Mark H Phillips) Date: Thu Aug 29 17:31:06 2002 Subject: [LC++]Producing a log of routine entry and exit Message-ID: <1030606341.24586.2737.camel@research> Hi, For debugging purposes, I wished to provide a standard means of logging the entry into, and exit from, each of my routines. This log should give the name of the routine, and calling signature. On entry it should print the input parameters, and on exit, the output parameters. My current way of doing this is like this: int myRoutine(string& retString, int a, char b) { cout<<"entering myRoutine(string&, int, char)\n" <<" second param: "< > For debugging purposes, I wished to provide a standard means of > logging the entry into, and exit from, each of my routines. This > log should give the name of the routine, and calling signature. > On entry it should print the input parameters, and on exit, the > output parameters. class EntryExitLogger { private: string name; public: EntryExitLogger(const char *name): name(name) { fprintf(stderr,"Entering %s\n",name); } ~EntryExitLogger() { fprintf(stderr,"Exiting %s\n",name); } }; #define EELOG EntryExitLogger entry_exit_logger(__PRETTY_FUNCTION__); void foo() { EELOG // Do stuff } __PRETTY_FUNCTION__ may not be the right spelling, check the docs. If you want the parameters, then it becomes way more complicated. If you want an automated thing, your best bet is to either modify the code to GCC to insert such code (yuck) or have some code to interpret the function signature and peek on the stack what it says is there (probably rather flaky). -- Vincent Penquerc'h -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux.org.au/pipermail/tuxcpprogramming/attachments/20020829/aaf76be1/attachment.htm From charlesrandle at hotmail.com Fri Aug 30 02:36:05 2002 From: charlesrandle at hotmail.com (Charles Randle) Date: Fri Aug 30 02:36:05 2002 Subject: [LC++]C++ Callback Problems Message-ID: Hi All , I have attached the following two files : "callback.hpp" and "cbtest.cpp" The first is a source file which attempts at implementing callback in C++ and the second is a test file. Whenever I compile the test file I get the following error : make -k cbtest g++ cbtest.cpp -o cbtest cbtest.cpp: In function `int main(int, const char* const*)': cbtest.cpp:20: no matching function for call to `xgx_support::gx_callback:: make_M2(A&, void (A::*)())' callback.hpp:182: candidates are: static xgx_support::gx_callback xgx_support::gx_callback::make_M2(CLIENT&, CLIENTMEMBER&) [with CLIENT = A, CLIENTMEMBER = void (A::*)()] make: *** [cbtest] Error 1 Compilation exited abnormally with code 2 at Thu Aug 29 11:18:48 Can anyone tell me what I am doing wrong ? Using GNU gcc version 3.2 Looking forward to your responses. Best Regards, Charles Randle _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx -------------- next part -------------- A non-text attachment was scrubbed... Name: callback.hpp Type: application/octet-stream Size: 6403 bytes Desc: not available Url : http://lists.linux.org.au/pipermail/tuxcpprogramming/attachments/20020830/dbb7acd1/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: cbtest.cpp Type: application/octet-stream Size: 722 bytes Desc: not available Url : http://lists.linux.org.au/pipermail/tuxcpprogramming/attachments/20020830/dbb7acd1/attachment-0001.obj From quang at tapeware.com Fri Aug 30 03:36:07 2002 From: quang at tapeware.com (Quang Nguyen (Ngo)) Date: Fri Aug 30 03:36:07 2002 Subject: [LC++]Producing a log of routine entry and exit In-Reply-To: <1030606341.24586.2737.camel@research> References: <1030606341.24586.2737.camel@research> Message-ID: <200208291036.06567.quang@tapeware.com> I would recommend using some kind of macros to handle logging/tracing, for example: #if DEBUG #define TRACE0(x,msg) MyTraceFunc(x,msg) #define TRACE1(x,msg,p1) MyTraceFunc(x,msg,p1) #define TRACE2(x,msg,p1,p2) MyTraceFunc(x,msg,p1,p2) #define .... #else #define TRACE0(x,msg) #define TRACE1(x,msg,p1) ... #endif x = trace mask value so you can filter out certain trace messages p1 = parameter 1 p2 = parameter 2 etc... void MyTraceFunc(unsigned int traceType, const char *msgFormat, ...) { va_list ap; va_start(ap, msgFormat); switch (traceType) { case TTYPE_ERROR: vprintf(...); or vsnprintf(...), etc... blah, blah... break; case TTYTPE_CRITICAL: blah, blah... break; . default: ... break; } va_end(ap); } Just some idea... -- Quang On Thursday 29 August 2002 07:32 am, Dr Mark H Phillips wrote: > Hi, > > For debugging purposes, I wished to provide a standard means of > logging the entry into, and exit from, each of my routines. This > log should give the name of the routine, and calling signature. > On entry it should print the input parameters, and on exit, the > output parameters. > > My current way of doing this is like this: > > int myRoutine(string& retString, int a, char b) { > cout<<"entering myRoutine(string&, int, char)\n" > <<" second param: "< <<" third param: "< int ret; > > // do stuff here > // including some things like "goto preExit;" > > preExit: > cout<<"exiting myRoutine(string&, int, char)\n" > <<" first param: "< <<" return: "< return ret; > } > > The problem with this is that it requires the use of gotos > which generally should be avoided. It also means I can't > create any objects "on the fly" before preExit, or I get > an error like: > > parsing.h: In function `bool moat::getToken(int &, string &)': > parsing.h:277: jump to label `preExit' > parsing.h:248: from here > parsing.h:274: crosses initialization of `class string myString' > > Now I can think of a range of alternative solutions to this > kind of logging, but they each have their drawbacks: > > 1. Same as above, but replace every instance of "goto preExit;" > with a local copy of the code that currently follows preExit. This > would eliminate gotos, but would make routines very verbose, and > would be wasteful, both in terms of program size, and in terms of > program writing and maintenance. > > 2. Create general routines "entryLog(...)" and "exitLog(...)". Call > entryLog(...) at the start. Then do as in 1, except that "goto preExit" > is replaced by a call to exitLog(...). This is less wasteful than 1, > but still somewhat so. And the parameters of these calls need to be > very general to cater for all kinds of uses - very tricky to get right, > and involving lots of template variables and function overloading. > > 3. Create a "RoutineLogger" object, instanciated at the beginning of > its routine, and told information about the routine it is responsible > for logging. It has the same scope as the routine it is representing, > so it will be destructed just before the routine exits. In this way > it will automatically be called at the right time without the need for > gotos. This solution sounds really good, except it's very hard to > properly pass it the information needed so it can log properly. > > > Any thoughts? > > Cheers, > > Mark. ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________ From kschin at unf.edu Fri Aug 30 03:56:05 2002 From: kschin at unf.edu (Keith Schincke) Date: Fri Aug 30 03:56:05 2002 Subject: [LC++]Producing a log of routine entry and exit In-Reply-To: <200208291036.06567.quang@tapeware.com> Message-ID: I have borrowed the debuging macro's from the pam system on Linux. It gives good messages that help in tracing and debuging code. With a little bit of modification, you can generate debug messages for various levels of debuging. I kept mine simple. The code from one of my header files follow below the sig but the usage is easy. Ex: D(("Check variable = %d",check_var)); produces [main.c:main(15)] Check variable = 55 I often add D(("called")) to the top and bottom of functions of interest to see if they are being called and are returning Hope this and the other suggestions help. -- Keith Schincke My dawg is always with me. Jacksonville, Fl 00 Spool - Wild at Heart http://www.unf.edu/~kschin Email: kschin at unf.edu #ifdef DEBUG #include static void _pam_output_debug_info(const char *file, const char *fn , const int line) { fprintf(stderr,"[%s:%s(%d)] ",file, fn, line); } static void _pam_output_debug(const char *format, ...) { va_list args; FILE *logfile; int must_close = 1; va_start(args, format); vfprintf(stderr, format, args); fprintf(stderr, "\n"); va_end(args); } #define D(x) do { \ _pam_output_debug_info(__FILE__, __FUNCTION__, __LINE__); \ _pam_output_debug x ; \ } while (0) #else #define D(x) do { } while (0) #endif From carlo at alinoe.com Fri Aug 30 12:11:10 2002 From: carlo at alinoe.com (Carlo Wood) Date: Fri Aug 30 12:11:10 2002 Subject: [LC++]Producing a log of routine entry and exit In-Reply-To: ; from kschin@unf.edu on Thu, Aug 29, 2002 at 01:53:23PM -0400 References: <200208291036.06567.quang@tapeware.com> Message-ID: <20020830040955.A29006@alinoe.com> On Thu, Aug 29, 2002 at 01:53:23PM -0400, Keith Schincke wrote: > I have borrowed the debuging macro's from the pam system on Linux. It Or you could go for the Real Deal and use libcwd. http://libcwd.sourceforge.net/ libcwd is written for (and in) C++, it supports ostreams. -- Carlo Wood From mark at austrics.com.au Fri Aug 30 14:46:19 2002 From: mark at austrics.com.au (Dr Mark H Phillips) Date: Fri Aug 30 14:46:19 2002 Subject: [LC++]Producing a log of routine entry and exit In-Reply-To: <20020830040955.A29006@alinoe.com> References: <200208291036.06567.quang@tapeware.com> <20020830040955.A29006@alinoe.com> Message-ID: <1030682714.1733.83.camel@research> On Fri, 2002-08-30 at 11:39, Carlo Wood wrote: > Or you could go for the Real Deal and use libcwd. > http://libcwd.sourceforge.net/ > > libcwd is written for (and in) C++, it supports ostreams. Hi Carlo, I am going through the tutorial for libcwd and found this quote from the FAQ: "Any project should have one header file that is included at the top of every source file. If you already have one then you can add #include to that file. Otherwise you should add such a header file: its a Good Thing(tm) to have." Am I right in thinking this is something you wrote? If so, could you please explain the reasons why it is a "Good Thing(tm)". Thanks, Mark. -- Dr Mark H Phillips Research Analyst (Mathematician) AUSTRICS - smarter scheduling solutions - www.austrics.com Level 2, 50 Pirie Street, Adelaide SA 5000, Australia Phone +61 8 8226 9850 Fax +61 8 8231 4821 Email mark at austrics.com.au From carlo at alinoe.com Fri Aug 30 21:56:08 2002 From: carlo at alinoe.com (Carlo Wood) Date: Fri Aug 30 21:56:08 2002 Subject: [LC++]Producing a log of routine entry and exit In-Reply-To: <1030682714.1733.83.camel@research>; from mark@austrics.com.au on Fri, Aug 30, 2002 at 02:15:10PM +0930 References: <200208291036.06567.quang@tapeware.com> <20020830040955.A29006@alinoe.com> <1030682714.1733.83.camel@research> Message-ID: <20020830135142.A24315@alinoe.com> On Fri, Aug 30, 2002 at 02:15:10PM +0930, Dr Mark H Phillips wrote: > I am going through the tutorial for libcwd and found this > quote from the FAQ: > > "Any project should have one header file that is included at the top of > every source file. If you already have one then you can add #include > to that file. Otherwise you should add such a header > file: its a Good Thing(tm) to have." > > Am I right in thinking this is something you wrote? If so, could you > please explain the reasons why it is a "Good Thing(tm)". Out of many many years of experience. It turns out that often you need something that is not directly related to your application but has external reasons. The most common reason is porting (differences between OS). It is a Good Thing to have those things at one place, in one header file - so it stays maintainable and surveyable. Code duplication is bad in general :). Furthermore it turns out having this header _standard_ at the *start* of each source file, before ANY system header file is included, gives you much more power to use it for Operating System differences. Finally, there is no good reason not to do it :p. Just like adding a license header to each file, and #ifndef MYAPP_HEADENAME_H #define MYAPP_HEADENAME_H ... #endif // MYAPP_HEADENAME_H is standard for every header file; it will pay back if you get used to starting each source (.cc, .cpp) file with: #include "sys.h" Examples of stuff that can go into such a file are given below. Please realize these ONLY *EXAMPLES* - what you will ACTUALLY add to it will be very project specific, despite that all of this is somehow not really related to the project. // autoconf dependency #ifdef HAVE_CONFIG_H #include "config.h" #endif // libcwd dependency #ifdef CWDEBUG #ifndef _GNU_SOURCE #define _GNU_SOURCE #endif #include #endif // Use __attribute__((noreturn)) but support compilers that don't have it // Functions whose use force me to use a return type but never return // now will look like: // int foo() __attribute__ ((noreturn)); // int foo() // { // this_function_never_return(); // NEED_FAKE_RETURN(0); // Avoid compiler warning // } #ifdef __GNUC__ #if (__GNUC__ < 2) || (__GNUC__ == 2 && __GNUC_MINOR__ < 7) #define NO_ATTRIBUTE #endif #else // !__GNUC__ // No attributes if we don't have gcc-2.7 or higher #define NO_ATTRIBUTE #endif // !__GNUC__ #if defined(NO_ATTRIBUTE) && !defined(__attribute__) #define __attribute__(x) #define NEED_FAKE_RETURN(x) return x; #endif #ifndef NEED_FAKE_RETURN #define NEED_FAKE_RETURN(x) #endif // Definition of macros used to add a ident string to each file: #ifndef RCSTAG_CC #define RCSTAG_CC(string) static char rcs_ident[] __attribute__ ((__unused__)) = string; #endif #ifndef RCSTAG_H #define RCSTAG_H(name, string) static char const rcs_ident_##name##_h[] __attribute__ ((__unused__)) = string; #endif #ifndef RCSTAG_INL #define RCSTAG_INL(name, string) static char rcs_ident##name##_inl[] __attribute__ ((__unused__)) = string; #endif // Use __restrict keyword, but support compilers that don't have it #if __GNUC__ == 2 && __GNUC_MINOR__ < 96 #define __restrict /*ignore*/ #endif // This is to avoid warnings like: // /usr/include/g++-3/iostream.h:253:5: "_G_CLOG_CONFLICT" is not defined #define NEED_G_CONFIG_H_MACROS #ifdef NEED_G_CONFIG_H_MACROS #include <_G_config.h> #ifndef _G_CLOG_CONFLICT #define _G_CLOG_CONFLICT 0 #endif #ifndef _G_HAS_LABS #define _G_HAS_LABS 1 #endif #endif ... Well, you get the idea. -- Carlo Wood From charlesrandle at yahoo.com Sat Aug 31 01:51:05 2002 From: charlesrandle at yahoo.com (Charles Randle) Date: Sat Aug 31 01:51:05 2002 Subject: [LC++]C++ Template Instantiation problems Message-ID: <20020830154726.47185.qmail@web13108.mail.yahoo.com> Hi All, This is a repost due to an email address change : I have the following code : #include class gx_callbackBaseBody { public: gx_callbackBaseBody() {} virtual ~gx_callbackBaseBody() {} virtual void operator ()() const = 0; }; class gx_callback { public: gx_callback(gx_callbackBaseBody *ptr) : entity(ptr) {} gx_callback(gx_callback const & arg) : entity(arg.entity) {} ~gx_callback() { delete entity;entity = 0;return;} void operator ()() { (*entity)();} template static gx_callback make_M2(CLIENT &,CLIENTMEMBER &); private: gx_callbackBaseBody *entity; }; template class gx_memberCB : public gx_callbackBaseBody { public: gx_memberCB(CLIENT &clnt,MEMBER &clntmem) : client(clnt),clientmember(clntmem) {} virtual void operator () () { ((&client) ->*member)();} private: CLIENT &client; MEMBER &clientmember; }; template gx_callback gx_callback::make_M2(CLIENT &c,CLIENTMEMBER &cm) { return gx_callback(new gx_memberCB(c,cm)); } class A { public: A(){} ~A(){} void noretsnoargs() {::std::cerr << "NO returns & No Args !!" << ::std::endl;return;} }; int main (int argc,char const * const * const argv) { A objectA; gx_callback test1 (gx_callback::make_M2(objectA,&A::noretsnoargs)); // // Execute object test1(); } Which gives the following error on compilation: g++ cbtest.cpp -o cbtest cbtest.cpp: In function `int main(int, const char* const*)': cbtest.cpp:62: no matching function for call to `gx_callback::make_M2(A&, void (A::*)())' cbtest.cpp:42: candidates are: static gx_callback gx_callback::make_M2(CLIENT&, CLIENTMEMBER&) [with CLIENT = A, CLIENTMEMBER = void (A::*)()] make: *** [cbtest] Error 1 Can anyone explain this and possibly suggest a solution. Best Regards, Charles Randle __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com