Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > Software - Troubleshooting and Discussion > Developer Center > Quick C++ Question

Quick C++ Question
Thread Tools
itistoday
Professional Poster
Join Date: Oct 2001
Status: Offline
Reply With Quote
Jul 20, 2005, 11:41 PM
 
In the never ending struggle to expand my knowledge of various programming languages, I have finally decided to learn C++. I am really familiar with Java and the way it does things, so I have quick question about the C++ scope operator (::). Why would you ever want to create a constructor or a method outside of the actual class declaration when you can create it inside of it? It just seems to add a layer of confusion...

Thanks!
     
smeger
Mac Elite
Join Date: Sep 2000
Location: Tempe, AZ
Status: Offline
Reply With Quote
Jul 21, 2005, 12:40 AM
 
Let's say that you've got two namespaces, and both of them contain a class with the same name. Without the scope operator, you have no way of specifying with one you want to use.

Let's say that your class contains a method named "strlen". If you want to call the standard library function named "strlen" from within a method of that class, you'd have no way of doing it without the scope operator.

And so on.
Geekspiff - generating spiffdiddlee software since before you began paying attention.
     
parallax
Admin Emeritus
Join Date: Oct 2000
Location: Boston, MA
Status: Offline
Reply With Quote
Jul 21, 2005, 01:17 AM
 
In general, you want to keep the interface and implementation of a class separate. Having a class declaration with method signatures and a bunch of comments explaining how to use the class enforces the idea that the client shouldn't really care about the details of implementation.

And another, more practical, reason. You generally keep class declarations in the header file, which is included by multiple other files. Not only would #including the implementation for that class in /each other file/ increase bloat, but it would be incorrect as the class definitions would not be linked to each other and would thus introduce namespace conflicts.
"Against stupidity, the gods themselves contend in vain" (Schiller)
     
itistoday  (op)
Professional Poster
Join Date: Oct 2001
Status: Offline
Reply With Quote
Jul 21, 2005, 01:34 AM
 
Originally Posted by smeger
Let's say that you've got two namespaces, and both of them contain a class with the same name. Without the scope operator, you have no way of specifying with one you want to use.

Let's say that your class contains a method named "strlen". If you want to call the standard library function named "strlen" from within a method of that class, you'd have no way of doing it without the scope operator.

And so on.
Yes, I see that aspect of it, but I still don't understand why you can also use it to implement method functionality outside the class declaration.... In Java you always implement the class within the class... This is just weird. I see that the scope operator has its uses, but this particular one just doesn't seem to have a point.
     
itistoday  (op)
Professional Poster
Join Date: Oct 2001
Status: Offline
Reply With Quote
Jul 21, 2005, 01:36 AM
 
Originally Posted by parallax
In general, you want to keep the interface and implementation of a class separate. Having a class declaration with method signatures and a bunch of comments explaining how to use the class enforces the idea that the client shouldn't really care about the details of implementation.

And another, more practical, reason. You generally keep class declarations in the header file, which is included by multiple other files. Not only would #including the implementation for that class in /each other file/ increase bloat, but it would be incorrect as the class definitions would not be linked to each other and would thus introduce namespace conflicts.
Ahh! I see, now that makes sense. Thanks!
     
itistoday  (op)
Professional Poster
Join Date: Oct 2001
Status: Offline
Reply With Quote
Jul 21, 2005, 01:41 AM
 
Wait, one more question parallax, what do you mean when you say they "would not be linked to each other and thus introduce namespace conflicts"? (Sorry I come from a happy-go-lucky Java world)
     
parallax
Admin Emeritus
Join Date: Oct 2000
Location: Boston, MA
Status: Offline
Reply With Quote
Jul 21, 2005, 02:03 AM
 
This applies to functions as well, and it's a bit easier to imagine this using functions.

So if I have one file that contains two functions,

void foo() {
cout << "bar" << endl;
}

void foo() {
cout << "bar" << endl;
}

The compiler is going to complain because we obviously can't have two functions named "foo," even if they do the same thing.

So say we have two source files that we want to compile together. Imagine that a common header file contains the function,

void foo() {
cout << "bar" << endl;
}

and this is included by both source files. "#include" is actually just a directive that means "dump the contents of the file at this point", and so both source files will now contain definitions for foo. And of course, this is bad! We avoid this by only including the prototype of the function (void foo() in the header file and then leave the actual definition for a source file.

The same applies to classes and their methods.
"Against stupidity, the gods themselves contend in vain" (Schiller)
     
itistoday  (op)
Professional Poster
Join Date: Oct 2001
Status: Offline
Reply With Quote
Jul 21, 2005, 02:09 AM
 
Ah, ok I think I get it now, thanks a bunch!
     
   
 
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Top
Privacy Policy
All times are GMT -4. The time now is 03:43 AM.
All contents of these forums © 1995-2017 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2017, Jelsoft Enterprises Ltd.,