|
Daniel Pfeffer wrote: What kind of computer needs a chastity belt?
To keep bad things from happening! It's TPM 3.0...kinda! 
The less you need, the more you have.
Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?
JaxCoder.com
|
|
|
|
|
It was another utter Flutter failure.
(Say that fast 3 times)
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
I felt laravel was more perfect code to use for developing a pro mobile app than flutter. I say it from my experience of developing a doctor booking app.
|
|
|
|
|
(This post is being submitted under the protection afforded by Lounge posting rule #2.)
I read somewhere on this site that someone had written that it's bad practice to use "using namespace std;" in your C++ code.
Can anyone explain the theory behind this?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
A rather long discussion on SO[^]
|
|
|
|
|
It's definitely frowned on in a header file, where it's best to spell out names in full.
I also avoid it in a .cpp, but using declarations for frequently used items are OK in a .cpp. A using directive is for everything in a namespace (using namespace std), but a using declaration is for a specific item (using std::string or using std::ostream).
|
|
|
|
|
You're probably referring to this thread[^]. I only remember it because I made a flippant comment.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Richard Andrew x64 wrote: Can anyone explain the theory behind this?
Hi,
I can give you an example of why using-declarations should be avoided.
Sometime ago I was on a two-man team (Hello Andy !) working on the Delivery Optimization system service[^] which would debut with Windows 10 Threshold. The original code base was developed with VS2010 and 'using namespace boost' was sprinkled throughout much of our source code.
The first problem we encountered was that boost::chrono, boost::atomic, and boost:mutex conflicted with std::chrono, std::atmomic and std:mutex. There were a few other issues with std::thread but I can't remember them all. We spent several days (probably a week) refactoring our code.
When C++17 came around I had a similar problem with boost::filesystem conflicting with std::filesystem in other projects.
We eventually moved away from boost to the std namespace when the internal OS build system added support for C++11. Now days I just type the entire scope and avoid using-declarations.
|
|
|
|
|
Very interesting. I think I haven't worked on anything in C++ that's sufficiently complex to have had such a problem. But I thank you for taking the time to explain it.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Yeah,
Shortly after I responded to your post I remembered some other details. I can remember that std::mutex and boost::mutex were nearly identical so I could seamlessly switch the code below from boost to the std namespace simply by changing the using-namespace declaration. It's a bit frightening when you discover three days later that you forgot to change a mutex in a few places.
mutex m;
m.lock();
m.unlock();
Can't make that mistake if you use the entire scope:
std::mutex m;
m.lock();
m.unlock();
|
|
|
|
|
Randor wrote: Can't make that mistake if you use the entire scope:
care to elaborate?
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
|
Yeah, I had understood so far.
But I didn't get the sentence I quoted.
I suppose that you meant using the "std::" or "boost::" as prefix, you have less probability of getting errors than unsing both "using", i.e. because some methods might have similar parameters but different behaviour.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Personally, I think it's fine in your main.cpp
Anywhere else, such as in a header, it clutters your global naming container.
In general, don't use "using namespace" in headers at all.
Some people here might suggest that using namespace std, even in main.cpp is bad form because of all the stuff it drags in.
I suggest those people relax.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: Some people here might suggest that using namespace std, even in main.cpp is bad form because of all the stuff it drags in.
As if linkers are that stupid...
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Not that. Just that people don't like intellisense coming up with a billion and a half entries every time it opens.
Real programmers use butterflies
|
|
|
|
|
I use VisualAssistX, it usually gives good entries anyway.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
I just use VS Code with minimal frills when I do C++. It mostly stays out of my way and that's what I like about it. It has a few quirks, but so does everything.
Real programmers use butterflies
|
|
|
|
|
I tried VSCode and while I find it all in all good I despise its side-panels management. When I can I cram everything in VS and use the external toolchain to compile. I'm using it for an embedded Linux sw, I used it for microcontrollers... 
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
They never bothered me that much. Once I got the hang of ctrl+click to open in the side it was all gravy for me.
Mostly I like VS Code because it's got a nice mix of minimal UI wrapped around maximum functionality. I have yet to find a file type it can't open. Makes it super nice for me working on my TTF library because I can just open a test font file and look at all the glyphs in VS Code.
I really hope they backport some of that functionality into Visual Studio or something but I doubt it because they are such different products.
Real programmers use butterflies
|
|
|
|
|
A.k.a. namespace pollution.
If you import a large amount of classes/functions, that you do not know the name of, you end up with a higher risk of running into namespace collisions.
|
|
|
|
|
Message Closed
modified 6-Aug-21 21:01pm.
|
|
|
|
|
|
|
Anyone who has played "shooter" games knows about "hit points".
I was fascinated to find rules for an 1824 Prussian war game that was attributed to later Prussian military successes. Back then they were assigning hit points to units.
As infantry in 3 ranks: .2 HP per man
In 2 ranks: .33 HP
Skirmishers: .66 HP
etc.
A half-Battalion (450 men) can "fire" anywhere from 2 - 60 HP, depending on range and probabilities.
I want to be a skirmisher.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
