using directive and size_t in loop for

[mickey]

Hello,
I have this 3 question:
1. I wonder what happen in a class declaration if I do using std::cout; and after cout << "hello"; or if I do std::cout << "Hello"; and more in general: is there any drawback to using "using std::mynamespace" instead of "using namespace mynamespace;" ?

2. .NET compiler gives warning on for(int i=0; i<vec.size();.............) then I use for (size_t i=0............) because "size()", I guess, return a size_t; but is size_t portable? or what is better? i < static_cast<int> (vec.size()) ? Or C -style cast, (int)

3. I've forgotten the third question right now........

Thanks...

[Michiel]

1. You can use:
using namespace std or
using std::cout

In both cases you can use either 'cout' or 'std::cout'. However, if you are missing such a directive, you need to use 'std::cout'.

The drawback of the 'using std::cout' directive is that you still have to specify the namespace for all symbols you use except cout (like endl).

For anything other than really small programs, I am a fan of the 'using std::symbol' directive, because you don't pollute the local namespace with symbols you will never use.

2. I don't understand the need of libraries to define their own basic types like this. It's as if the underlying type could someday change without warning. ;-)

Anyway, in this case, size_t is likely an unsigned int, since the size of a vector can never be negative. If the compiler still complains, I would use size_t. I suppose it does give some small measure of extra portability.

3. Well, be sure to tell us when you remember, ok?

[wysota]

It's as if the underlying type could someday change without warning. ;-)

That's exactly the case. size_t can be different on different architectures, including 32b and 64b.

[Michiel]

Heh, I knew that statement was gonna come back and bite me in the a3.

I'm designing a programming language now with (among other things) a single int-type, which is sized correctly at compile-time, by trying to find the actual limits in the code (or using a dynamic int if this is impossible). That might remove the need for such things.

[mickey]

Hello,
1. I meant some drawback much more important. So I guess there aren't
2. I don't sure to understand: apart 32b or 64b, I wonder even if could be different compiling my code with different compiler (not only MS compiler).....Does Anyone have this warning? How do you solve it? (I mean, the most elegant way.....)
3.(Finally) I read that in the .h it's better don't allocate memory: eg. if I have a class where inside a "vector<double>* ivec" (Beyond if is better take the vector on the stack instead on the heap....); it's better call the "ivec = new vector<int>(10000);" not in a inlined constructor but keep it out of the .h, but in the implementation (.cpp). But is there any performance/compiling reasons (maybe something will change in the .obj file?) ?

thanks.

[Michiel]

1. No, there aren't.
2. I get a "comparing signed with unsigned integer" warning when I use int. The solution is to use unsigned int. If that doesn't work for you, it's MS specific.
3. There are no performance reasons for putting the constructor code anywhere specific, as far as I know. It's just that if you want to change the 10000 to 20000, you will have to recompile every file that includes your header. Whereas if you put it in your .cc/.cpp file, you'll only have to recompile that one.