[LC++]subject=unsubscribe

Christian Nalletamby cnalletamby at hotmail.com
Wed Oct 26 08:53:03 UTC 2005


With my best Regards,

Christian Nalletamby
CNalletamby at hotmail.com



----Original Message Follows----
From: tuxcpprogramming-request at lists.linux.org.au
Reply-To: tuxcpprogramming at lists.linux.org.au
To: tuxcpprogramming at lists.linux.org.au
Subject: tuxCPProgramming digest, Vol 1 #43 - 18 msgs
Date: Tue, 25 Oct 2005 15:16:02 +0800
MIME-Version: 1.0
Received: from digital.linux.org.au ([202.0.185.5]) by mc11-f22.hotmail.com 
with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 00:17:05 -0700
Received: from localhost([127.0.0.1] helo=digital.linux.org.au ident=list)by 
digital.linux.org.au with esmtp (Exim 4.50)id 1EUJ3Q-0006oc-26; Tue, 25 Oct 
2005 15:17:04 +0800
X-Message-Info: 6sSXyD95QpWWiTfh1TQXHxWnQ2V+EHe0rZuTuqvDVY8=
X-Mailer: Mailman v2.0.13
Errors-To: tuxcpprogramming-admin at lists.linux.org.au
X-BeenThere: tuxcpprogramming at lists.linux.org.au
X-Mailman-Version: 2.0.13
Precedence: bulk
X-Reply-To: tuxcpprogramming at lists.linux.org.au
List-Unsubscribe: 
<http://lists.linux.org.au/listinfo/tuxcpprogramming>,<mailto:tuxcpprogramming-request at lists.linux.org.au?subject=unsubscribe>
List-Id: The Linux C++ Programming List 
<tuxcpprogramming.lists.linux.org.au>
List-Post: <mailto:tuxcpprogramming at lists.linux.org.au>
List-Help: <mailto:tuxcpprogramming-request at lists.linux.org.au?subject=help>
List-Subscribe: 
<http://lists.linux.org.au/listinfo/tuxcpprogramming>,<mailto:tuxcpprogramming-request at lists.linux.org.au?subject=subscribe>
List-Archive: <http://lists.linux.org.au/archives/tuxcpprogramming/>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: tuxcpprogramming-admin at lists.linux.org.au
X-SA-Exim-Scanned: No (on digital.linux.org.au); SAEximRunCond expanded to 
false
Return-Path: tuxcpprogramming-admin at lists.linux.org.au
X-OriginalArrivalTime: 25 Oct 2005 07:17:06.0210 (UTC) 
FILETIME=[1ADC5020:01C5D934]

Send tuxCPProgramming mailing list submissions to
	tuxcpprogramming at lists.linux.org.au

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.linux.org.au/listinfo/tuxcpprogramming
or, via email, send a message with subject or body 'help' to
	tuxcpprogramming-request at lists.linux.org.au

You can reach the person managing the list at
	tuxcpprogramming-admin at lists.linux.org.au

When replying, please edit your Subject line so it is more specific
than "Re: Contents of tuxCPProgramming digest..."


Today's Topics:

    1. Re: virtual functions (Paul Gearon)
    2. Re: virtual functions (Adriano dos Santos Fernandes)
    3. Re: interface and abstraction (Torsten Rennett)
    4. Re: virtual functions (Paul Gearon)
    5. exception handling (choube mehul)
    6. Re: exception handling (Jan Pfeifer)
    7. Merry c++-mas (Julien Claassen)
    8. linker error LNK2005 (choube mehul)
    9. Why new behaviour of g++? (Dr Mark H Phillips)
   10. Re: Why new behaviour of g++? (Jan Pfeifer)
   11. Re: Why new behaviour of g++? (Jack Lloyd)
   12. warning: initialized and declared `extern' (choube mehul)
   13. Re: Why new behaviour of g++? (Torsten Rennett)
   14. Re: Why new behaviour of g++? (Dr Mark H Phillips)
   15. problem related to traits (choube mehul)
   16. Reader Writer Problem ............ (relan vivek)
   17. Re: Reader Writer Problem ............ (David Lloyd)
   18. Compiles with g++-3.2 but later versions flakey.  Why? (Dr Mark H 
Phillips)

--__--__--

Message: 1
From: Paul Gearon <gearon at ieee.org>
Date: Fri, 29 Oct 2004 15:54:56 +1000
To: tuxcpprogramming at lists.linux.org.au
Subject: Re: [LC++]virtual functions
Reply-To: tuxcpprogramming at lists.linux.org.au

On 29/10/2004, at 1:14 PM, choube mehul wrote:

 >>> how many?
 >>
 >> For each object of class base or class derived.
 >> Here: one virtual table for object 'd'.
 >>
 >>> one for base?
 >>> and one for derived?
 >>
 >> You have just one object 'd', so you have just one
 >> virtual table within the
 >> memory space of that object.
 >
 >     now if i add a pointer variable base *ptr
 >     then will a additional virtual table be
 >     created?
 >     2 virtual tables one for ptr and another for
 >     d?

No.  As Torsten said, you will only get a new virtual table with a new
object.

When you call the print() method on an object of type "derived" then
you want the derived::print() method to be called, no matter what kind
of compatible pointer you are using.

You can think of a virtual table as a form of indirection.  When a
virtual table is present then the code will look inside the virtual
table to find where this object's version of the method is, and then it
will call the resulting pointer.  Having a virtual table lets an object
say, "here is my own implementation of these methods".

If not for the virtual table then a pointer of type base* would always
find the base::print() method, even if the object is of type "derived".
   Calling a method on an object without a virtual table just goes to
some fixed offset from the start of the object to find the method.

Regards,
Paul Gearon

Software Engineer
Tucana Technologies
http://www.tucanatech.com

Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum
immane mittam.
(Translation from latin: "I have a catapult. Give me all the money,
or I will fling an enormous rock at your head.")



--__--__--

Message: 2
Date: Fri, 29 Oct 2004 08:33:52 -0200
From: Adriano dos Santos Fernandes <adrianosf at uol.com.br>
To: tuxcpprogramming at lists.linux.org.au
Subject: Re: [LC++]virtual functions
Reply-To: tuxcpprogramming at lists.linux.org.au

Paul Gearon wrote:

 > If not for the virtual table then a pointer of type base* would always
 > find the base::print() method, even if the object is of type
 > "derived".  Calling a method on an object without a virtual table just
 > goes to some fixed offset from the start of the object to find the
 > method.

Wrong. The method is called as a normal function (resolved by the linker).
A class that don't have virtual functions is as a C struct, it don't
have "hide" variables.

 >
 > Regards,
 > Paul Gearon
 >
Adriano



--__--__--

Message: 3
From: Torsten Rennett <Torsten at Rennett.de>
Organization: Ingenieurbuero RENNETT
To: tuxcpprogramming at lists.linux.org.au
Date: Fri, 29 Oct 2004 15:09:23 +0200
Subject: Re: [LC++]interface and abstraction
Reply-To: tuxcpprogramming at lists.linux.org.au

On Freitag, 29. Oktober 2004 05:08, choube mehul wrote:
 > hi all,
 >     are interface and abstraction different concepts?

yes.

 >     i think:
 >
 >     abstraction: a way to hide implementation details.
 >
 >     interface: methods provided for user.
 >
 >     am i correct?

Yes, you are.

What might be confusing is, that you have to use in C++ the same mechanism
(derivation) to achieve either of this two (theoretically different)
concepts. I have to admit, that Java is a bit clearer at this point.


Torsten

--
Ingenieurbuero RENNETT      -- innovative Software-Entwicklung --
Torsten Rennett                    http://www.RENNETT.de
Ludwig-Thoma-Weg 14         E-Mail:            Torsten at Rennett.de
D-85551 Heimstetten         Telefon:            +49 89 904 805 38


--__--__--

Message: 4
From: Paul Gearon <gearon at ieee.org>
Date: Sun, 31 Oct 2004 18:08:12 +1000
To: tuxcpprogramming at lists.linux.org.au
Subject: Re: [LC++]virtual functions
Reply-To: tuxcpprogramming at lists.linux.org.au


On 29/10/2004, at 8:33 PM, Adriano dos Santos Fernandes wrote:

 > Paul Gearon wrote:
 >
 >> If not for the virtual table then a pointer of type base* would
 >> always find the base::print() method, even if the object is of type
 >> "derived".  Calling a method on an object without a virtual table
 >> just goes to some fixed offset from the start of the object to find
 >> the method.
 >
 > Wrong. The method is called as a normal function (resolved by the
 > linker).
 > A class that don't have virtual functions is as a C struct, it don't
 > have "hide" variables.

Sorry.  You're quite correct here.  If things were done that way then
you'd end up with the same code being repeated for every object of the
same type.

Not sure what I was thinking when I wrote that  :-}

Regards,
Paul Gearon

Software Engineer
Tucana Technologies
http://www.tucanatech.com

Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum
immane mittam.
(Translation from latin: "I have a catapult. Give me all the money,
or I will fling an enormous rock at your head.")



--__--__--

Message: 5
Date: Thu, 9 Dec 2004 11:02:04 +0000 (GMT)
From: choube mehul <choube_mehul at yahoo.com>
To: tuxcpprogramming at lists.linux.org.au
Subject: [LC++]exception handling
Reply-To: tuxcpprogramming at lists.linux.org.au

Hello all;

please look at the following code:

Code 1:
void div (int n1, int n2)
{
   if (n2 == 0) {
     throw "divide by zero";
   }

   cout << n1/n2 << endl;
}

int main (int argc, char argv)
{
   int n1 = 10, n2 = 0;


   try {
     div (n1, n2);
   } catch (string msg) {
     cout << msg << endl;
   }

   return 0;
}

Code 2:
void div (int n1, int n2)
{
   try {
     if (n2 == 0) {
       throw "divide by zero";
     }

     cout << n1/n2 << endl;
   } catch (string msg) {
     cout << msg << endl;
   }
}

int main (int argc, char argv)
{
   int n1 = 10, n2 = 0;

   div (n1, n2);

   return 0;
}

which one from the above is correct
Code 1 or Code 2?

which is one is the general practice/efficient?

what are the advantages, disadvantages?

thanks in advance.

mehul.


________________________________________________________________________
Yahoo! India Matrimony: Find your life partner online
Go to: http://yahoo.shaadi.com/india-matrimony


--__--__--

Message: 6
From: Jan Pfeifer <pfjan at yahoo.com.br>
To: tuxcpprogramming at lists.linux.org.au
Date: Thu, 09 Dec 2004 11:37:10 -0200
Subject: Re: [LC++]exception handling
Reply-To: tuxcpprogramming at lists.linux.org.au

Hi Mehul,

there is no right and wrong in this case (*). It depends where you want
to handle the error/exception. I'll try to give you a short explanation
on exceptions, sorry if it is already obvious to you.

think of exceptions as exceptional, typically error, conditions, that a
method/function/block of code don't know how to handle, or just prefers
to leave to some other piece of code to handle.

instead of creating cumbersome parameter (return value) manipulation to
indicate this error condition, you can "throw an exception". Usually
methods/functions documentations lists the possible exceptions it may
generate.

the code using the method/function can then handle the exceptions as
they see fit, or just leave to some other code to handle. If nothing
"catches" an exception, it will cause your program to exit.

so if you want for your function "div" to know how to handle the
exceptional condition, just use the second code. Note that in this case,
the calling code will never know about the exception/error.

generally if your developing a library, i would recommend the first
form, where the user of the library gets to decide what to do when some
error occurs.

note that if you're using exceptions inside a more complex
method/function, before leaving the method because of an exception, you
might have to free allocated resources (memory, close files, and so on).
A commom method to implement this is to code a catch in the end of your
method that frees the allocated resources and re-throws the exception.

there is little speed difference among the two forms.

hope this helps :)

jan


(*) I haven't tested your code, but I noticed is that you throw a "const
char *" and you're catching a "string", which are different types, so it
might not work. And if you are using simple throws, try to use the
standard exception classes already defined -- runtime_error,
logical_error, and so on :)





On Thu, 2004-12-09 at 11:02 +0000, choube mehul wrote:
 > Hello all;
 >
 > please look at the following code:
 >
 > Code 1:
 > void div (int n1, int n2)
 > {
 >   if (n2 == 0) {
 >     throw "divide by zero";
 >   }
 >
 >   cout << n1/n2 << endl;
 > }
 >
 > int main (int argc, char argv)
 > {
 >   int n1 = 10, n2 = 0;
 >
 >
 >   try {
 >     div (n1, n2);
 >   } catch (string msg) {
 >     cout << msg << endl;
 >   }
 >
 >   return 0;
 > }
 >
 > Code 2:
 > void div (int n1, int n2)
 > {
 >   try {
 >     if (n2 == 0) {
 >       throw "divide by zero";
 >     }
 >
 >     cout << n1/n2 << endl;
 >   } catch (string msg) {
 >     cout << msg << endl;
 >   }
 > }
 >
 > int main (int argc, char argv)
 > {
 >   int n1 = 10, n2 = 0;
 >
 >   div (n1, n2);
 >
 >   return 0;
 > }
 >
 > which one from the above is correct
 > Code 1 or Code 2?
 >
 > which is one is the general practice/efficient?
 >
 > what are the advantages, disadvantages?
 >
 > thanks in advance.
 >
 > mehul.
 >
 >
 > ________________________________________________________________________
 > Yahoo! India Matrimony: Find your life partner online
 > Go to: http://yahoo.shaadi.com/india-matrimony
 >
 > _______________________________________________
 > This is the Linux C++ Programming List
 > : http://lists.linux.org.au/listinfo/tuxcpprogramming List
 >
--
Jan Pfeifer <pfjan at yahoo.com.br>



--__--__--

Message: 7
Date: Sun, 26 Dec 2004 12:29:47 +0100 (CET)
From: Julien Claassen <julien at c-lab.de>
To: tuxcpprogramming <tuxcpprogramming at lists.linux.org.au>
Subject: [LC++]Merry c++-mas
Reply-To: tuxcpprogramming at lists.linux.org.au

Hi all!
int main()
{
   string name;
   cout << "Enter your name: ";
  cin >> name;
   cout << "Merry Christmas " << name << endl;
   return 24;
}

   :-)
   Kindest regards
         Julien

--------
Music was my first love and it will be my last (John Miles)

======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net - the Linux TextBased Studio guide


--__--__--

Message: 8
Date: Sat, 12 Feb 2005 09:35:35 +0000 (GMT)
From: choube mehul <choube_mehul at yahoo.com>
To: tuxcpprogramming at lists.linux.org.au
Subject: [LC++]linker error LNK2005
Reply-To: tuxcpprogramming at lists.linux.org.au

Hello,

i am getting following linker error
Linking...
libvxSigFCL2LSU.lib(guid.obj) : error LNK2005:
_iswalnum already defined in LIBCMT.lib(_wctype.obj)
libvxSigFCL2LSU.lib(guid.obj) : warning LNK4006:
_iswalnum already defined in LIBCMT.lib(_wctype.obj);
second definition ignored

i am building a application which statically links
to libvxSigFCL2LSU.lib (this lib is also wriiten by
me)

i used dumpbin to get the symbol info.

 >dumpbin libvxSigFCL2LSU.lib /SYMBOLS | grep iswalnum
097 00000000 SECT31 notype () External | _iswalnum

the output says iswalnum is defined in SECT31, but
in my code i have just made a call to iswalnum ().

i tried searching with google
it says this is related to /Mx flags
i am compiling all the source files using /Mt flag.

has anyone encountered this problem earlier?
how did u solve this?

Thanks,
Mehul.


________________________________________________________________________
Yahoo! India Matrimony: Find your life partner online
Go to: http://yahoo.shaadi.com/india-matrimony


--__--__--

Message: 9
From: Dr Mark H Phillips <mark at austrics.com.au>
To: Tux C++ Programming <tuxcpprogramming at lists.linux.org.au>
Organization: Austrics
Date: Wed, 16 Feb 2005 18:47:08 +1030
Subject: [LC++]Why new behaviour of g++?
Reply-To: tuxcpprogramming at lists.linux.org.au

Hi,

The recent versions of g++ (in contrast to 3.3.* versions) will no
longer compile:

   #include <iostream>

   template<typename T> struct SixStore {
     int store; SixStore(): store(6) {}
   };

   template<typename T> struct Six: public SixStore<T> {
     int six() {return store;}
   };

   int main() {
     Six<char> s;
     std::cout<<"six = "<<s.six()<<std::endl;
   }

It complains with:

   tst3.cc: In member function `int Six<T>::six()':
   tst3.cc:8: error: `store' undeclared (first use this function)

If I remove the template stuff however, it compiles fine.  I had
a look on the GCC website and on the page

   http://gcc.gnu.org/bugs.html#known

I found the following information:

   This also affects members of base classes, see [14.6.2]:
                 template <typename> struct A
                 {
                     int i, j;
                 };

                 template <typename T> struct B : A<T>
                 {
                     int foo1() { return i; }       // error
                     int foo2() { return this->i; } // OK
                     int foo3() { return B<T>::i; } // OK
                     int foo4() { return A<T>::i; } // OK

                     using A<T>::j;
                     int foo5() { return j; }       // OK
                 };

and foo1() seems to be pretty much what I was unsuccessfully trying to
do!  But why does g++ now outlaw this?  Presumably the answer lies in
14.6.2 of the standard, but I do not have a copy of this and I can't
find it anywhere on the web.  Can anyone enlighten me on what is happening
here and why this kind of access to base-class members has been outlawed??

Thanks,

Mark.




--__--__--

Message: 10
Date: Wed, 16 Feb 2005 07:54:39 -0300 (ART)
From: Jan Pfeifer <pfjan at yahoo.com.br>
To: Linux C++ List <tuxcpprogramming at lists.linux.org.au>
Subject: Re: [LC++]Why new behaviour of g++?
Reply-To: tuxcpprogramming at lists.linux.org.au

hi Mark,

as you, I didnt have the specifications to check for,
but in the g++ page you refered they mentioned: "We
now have two-stage name-lookup".



More information about the tuxCPProgramming mailing list