Namespace
C did not have namespaces so if you are using the old c stuff you will have headers with a .h like #include <stdio.h> and you don''t need to do using namespace std, but in c++ we drop the .h and use namespaces. If you want to inlcude say #include <iostream> you also need to do: using namespace std;
Because iostream is inside a namespace you cant see it unlees you do the using namespace std, which will resolve the scope.
Code Optimizing
quote:Original post by Anonymous Poster
Namespace
C did not have namespaces so if you are using the old c stuff you will have headers with a .h like #include <stdio.h> and you don''t need to do using namespace std, but in c++ we drop the .h and use namespaces. If you want to inlcude say #include <iostream> you also need to do: using namespace std;
Because iostream is inside a namespace you cant see it unlees you do the using namespace std, which will resolve the scope.
Post to wrong thread or server error?
The canonical definition for a namespace is exactly what it says: a space for names. Classes have namespaces, which is why we prefix class member definitions with <classname>:: and nonstatic invocations/references with <objectname>. or <objectname>->.
With the standardardization of C++, namespaces were made a commodity (about time, too!) All entities in the Standard C++ Library were placed in the std namespace and the namespace and using keywords were introduced. using allows you to import either entire namespaces or select identifiers from a namespace (using namespace std: vs using std::cout;). There's also the global namespace (which is unnamed), which is where main resides.
Namespaces may be anonymous (have no identifying name) and are hierarchical.
[Edit: Formatting.]
[edited by - Oluseyi on September 16, 2002 8:31:44 PM]
With the standardardization of C++, namespaces were made a commodity (about time, too!) All entities in the Standard C++ Library were placed in the std namespace and the namespace and using keywords were introduced. using allows you to import either entire namespaces or select identifiers from a namespace (using namespace std: vs using std::cout;). There's also the global namespace (which is unnamed), which is where main resides.
Namespaces may be anonymous (have no identifying name) and are hierarchical.
namespace A{ int function( int i ) { return i + 2; } namespace // anonymous namespace { int function( int i ) { // call function in outer namespace return ::function( i ) + 4; } }}; [Edit: Formatting.]
[edited by - Oluseyi on September 16, 2002 8:31:44 PM]
quote:Original post by CWizard
I think it''s good to always optimize where you can
I may be taking you totally out of context, but I generally disagree with this statement. Too many times at work I get suggestions, "these lines should be done like this, it''s faster" but in doing so, would make it much harder to understand, and only save a few cycles a frame. Trying to understand that optimized line 2 months from now is time wasted, that could have been used optimizing parts of the program that really need it.
quote:Original post by Oluseyi
Compilers can only perform localized optimizations - usually optimizations within functions. For global optimizations, the compiler would need to understand the overall application architecture and how things fit together, something we haven''t quite figured out how to express to compilers.
Modern compilers will optimize across function boundaries and translation unit boundaries, so I can''t say I agree with you.
quote:Original post by Oluseyi
If it were so, the Big-O of a function would depend on compiler, platform, etc.
No it wouldn''t.
Like you go on to say, constants are ignored, and you only take the largest term.
In any case, the number of "operations" would depend on the compiler too.
quote:It''s definitely operations. We assume a number of simple statements - assignments and the like - to take a constant amount of time ( O(1) ) and obtain n-tuples by analyzing iterations.
Generally when computer scientists speak of Big-O, they''re referring to time complexity, but space complexity isn''t uncommon either.
quote:Original post by DrPizza
Modern compilers will optimize across function boundaries and translation unit boundaries, so I can''t say I agree with you.
Neither can I. I was a little too quick with that statement. Return value optimization is an obvious example that invalidates my use of "only".
A compiler won''t be able to optimize a slowsort into a quicksort. Look them up. They work much differently.
That''s the kind of thing that computer scientists try to improve upon.
That''s the kind of thing that computer scientists try to improve upon.
On the topic of iostream vs. iostream.h, the new C++ Standard says to use .h-less headers for the standard library (and c headers have a .h-less alternate too - e.g. cmath instead of math.h). The functions in the .h-less headers are defined in the std:: namespace instead of the global namespace too. That''s really the only difference.
About optimizations, being a student of extreme programming now, I think the most important thing is getting something to work. Once it works fine if you find something is a bottleneck then it''s fine to rewrite it to squeeze out the extra clock cycles you need (plus assuming you do TDD you can make sure you don''t f*ck the code up with your new code). Compilers can do a lot of optimization and humans are very bad guessers at what code will need optimizations.
About optimizations, being a student of extreme programming now, I think the most important thing is getting something to work. Once it works fine if you find something is a bottleneck then it''s fine to rewrite it to squeeze out the extra clock cycles you need (plus assuming you do TDD you can make sure you don''t f*ck the code up with your new code). Compilers can do a lot of optimization and humans are very bad guessers at what code will need optimizations.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
