General questions and guidance from pros

[Mandavel]

So looks like I was off on a few things here then. Can someone explain why using namespace std; is not a good thing? I assumed it would mean less code overall through the program, more readability, less information, etc. so I guess I just don’t understand why it’s looked down upon. Does that mean I should never use using or even namespace for anything?

I’m also interested in cross-platform knowledge, as much as possible. So the console clearing character input in, I thought was cross-platform and would clear the output no matter what. Is there a better system I should be using? I suppose in the end that kind of thing is what a real GUI is for, so clearing the console isn’t truly the best option.

And lastly, understandable that my clock will drift, I didn’t know [code]Sleep()/[code] was so loose. How would one keep very solid time, or is it a crapshoot on a system unless it’s time synced?

Learning a lot from the replies, thanks.

[George P]

https://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practice

[George P]

My personal choice is ALMOST never have using directives or using declarations in code I write, I fully qualify whatever I use.

https://www.learncpp.com/cpp-tutorial/using-declarations-and-using-directives/

At first the "excess" typing was mildly annoying, but now it is 2nd nature. At first glance I see exactly where something I use resides. Either in the std namespace or in a custom namespace.

I say ALMOST never have using declarations/directives, Boost buries a lot of the functionality deep in multiple layers of namespaces. Boost is the one firm "maybe" exception.

[JLBorges]

> Can someone explain why using namespace std; is not a good thing?

It is considered bad practice to write using namespace directives in a header file
or before an #include in an implementation file.

About writing using namespace std ; at global scope in an implementation file, there are different shades of opinions.

More info on this: https://www.cplusplus.com/forum/beginner/275318/#msg1188303


> How would one keep very solid time, or is it a crapshoot on a system unless it’s time synced?

To process events within very tightly defined time constraints, use an RTOS.
"A real-time operating system (RTOS) is an operating system (OS) for real-time applications that processes data and events that have 'critically defined time constraints'."
https://en.wikipedia.org/wiki/Real-time_operating_system

[helios]

And lastly, understandable that my clock will drift, I didn’t know [code]Sleep()/[code] was so loose. How would one keep very solid time, or is it a crapshoot on a system unless it’s time synced?

Modern desktop computers are not designed for very precise timing. That is to say, it's easy to measure the interval between two events precisely, but difficult to, for example, execute a piece of code at precise intervals.
Windows has multimedia timers, which let you get callbacks at up to 1 kHz, but the system may still miss by up to 2 or 3 ms.
In my experience, the most precise method to wait is to spinwait until the real time clock has reached the necessary time. Obviously this is not particularly efficient.

[jonnin]

you have a number of options.
-you can just busy wait, instead of sleep do nothing in a loop until time is reached. This is not awesome, as it busies a cpu doing nothing useful.

- better, sleep (say, 90% of the time slice you want, 900 ms for 1 second etc) and then why not get the current time, correct your clock as needed (say the computer got busy and you sleep 10 seconds! detect that, increment the clock 10 times, resume normal operations). Since you always correct to the current time, the sleeps let other programs use the CPU and your clock may occasionally lag but it corrects and if it were badly lagged, the whole computer would have been unresponsive as well, the user will realize it. Generally the clock would be within 1-2 seconds of 'correct' all the time if you are not constantly locking it up due to asking too much from the hardware.

-depending on the application, you can even just sleep a bit then spew the current system time back out without trying to track it yourself. If you just wanted a wall clock, for example.

none of that matters if you are just doing exercises. The only thing you really needed to learn here is that sleep is set up on "at least this much" not "exactly this much". If you can remember that, you learned all you needed to from my comment. There are powerful timing tools in <chrono> if you want to dig into timers and such.

[Rakib771]

@GeorgeP, yeah, figured that I can change the dll link to static link. But my point is, I don't even know what those libraries are doing. It was a small code to just write a file and then delete it. Nothing outside of STL. And it still requires three dlls! Here's the Git link https://github.com/Rakib1503052/DiskWipe . It would be pretty helpful if you could tell me why it needs those dlls.

@Mandavel, My personal rule- "Never put a using directive in a header file". For source files, using directives should be put inside functions, preferably. And absolutely, never, ever put two different namespaces in using directives in the same scope <- I follow this strictly..

To explain why- The header files are supposed to be included into other's codes. If you put a using directive there, other people using that header will be forced to use that using directive.
And putting two different namespaces in using directive can make your code go nuts. Consider an example-

namespace ns1{
void foo(some args)
{
    something
}
}

namespace ns2{
int foo(same args)
{
    something else
}
}

using namespace ns1;
using namespace ns2;

int main()
{
    int x = foo(whatever args);
    something to do
}

When you call foo(), the two definitions collide. It's not uncommon to have different functions in different libraries with the same name and often similar arguments. For me, it's okay to put the most used namespace for a source file in using directive and write full namespace for other namespaces in that file.

[newbieg]

I generally still put "using namespace std;" above main(), especially in my test programs, but avoid it most everywhere else.
I consider main() to be the client side of my libs, it's equally important to me that I have avoided collisions to begin with since I don't know who's going to use my libs, poor souls.

[Mandavel]

That all makes great sense now. better not to make those blanket statements if down the road you need to change something up or suspect a collision.

And about the clock, it's good to know how Sleep() works and about the timing stuff. Right now I'm just doing exercises and trying to understand how things work together, so at this point I'm not concerned about the drift. But really good to know.

Thanks for the insight.