|
How is flutter significant and helpful to create a cross-platform mobile app?
|
|
|
|
|
Because we all need the flutter of the Chaos Butterfly wings to code - or are you still using "keyboards" and "mice"?
And it's best not to create cross apps at all: pleasant, happy ones are much easier to work with.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
what's flutter.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Flutter - Wikipedia[^]
Aw, they prolly mean the "software" by Google. "Go Flutter!"
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Only if used with doohickey 1.0.2 and whatchamacallit 0.0.5
if you use the 1.1.0 version of doohickey, it'll break your code and render all mobile apps immobile.
but you can prevent that by applying patch 0.2 of the Alpha release of Thingy 2.4.1
Remember that if you also use thingummabob 1.0 RC it'll only work on Windows 12, and Android pre-2033 releases.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
But according to Microsoft pre release of Windows 12 it will only run on Quantum machine with the CB 2.0 upgrade.
CB = Chastity Belt
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
|
|
|
|
|
Mike Hankey wrote: CB = Chastity Belt
What kind of computer needs a chastity belt?
Asking for a friend.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
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
|
|
|
|