|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
On May 26 2018 20:26 Excludos wrote:Show nested quote +On May 26 2018 08:53 nunez wrote:
@excludos
qt should be quarantined to the code that deals with the gui, and even there it should be used as sparingly as possible. for that it's an ok option, but for anything else there are better alternatives. if someone suggested that we use qt for signals / slots at work, he / she would also be quarantined to code that deals with gui.
some never get comfortable with the complexity of c++, and seek refuge in the abstract comfort of Qt or C# or python or whatever. parading this retreat as ersatz critique seems common. What do you base your answer on here? Qt has loads of plugins and tools for back end purposes and is made to work equally well for that as front end. I wouldn't suggest you use it just because of signals and slots, but because it literally has an answer for all of your problems (Hyperbole of course. There's loads of things it doesn't do as well. Like heavy calculations or image operations). A lot of those problems can be solved with a external library each..or you can just remove all of them and use Qt instead. I'm also not saying it's the only tool for the job or something you must use in all situations, just that it's very good for a lot of them, and not something you should just dismiss based on..whatever you think you're basing it on. I don't know what kind of misconceptions you have about it, but I'd love to know
experience.
|
On May 26 2018 20:47 nunez wrote:Show nested quote +On May 26 2018 20:26 Excludos wrote:On May 26 2018 08:53 nunez wrote:
@excludos
qt should be quarantined to the code that deals with the gui, and even there it should be used as sparingly as possible. for that it's an ok option, but for anything else there are better alternatives. if someone suggested that we use qt for signals / slots at work, he / she would also be quarantined to code that deals with gui.
some never get comfortable with the complexity of c++, and seek refuge in the abstract comfort of Qt or C# or python or whatever. parading this retreat as ersatz critique seems common. What do you base your answer on here? Qt has loads of plugins and tools for back end purposes and is made to work equally well for that as front end. I wouldn't suggest you use it just because of signals and slots, but because it literally has an answer for all of your problems (Hyperbole of course. There's loads of things it doesn't do as well. Like heavy calculations or image operations). A lot of those problems can be solved with a external library each..or you can just remove all of them and use Qt instead. I'm also not saying it's the only tool for the job or something you must use in all situations, just that it's very good for a lot of them, and not something you should just dismiss based on..whatever you think you're basing it on. I don't know what kind of misconceptions you have about it, but I'd love to know experience.
Again why bother with non-answers such as these? It's so damn pointless. Next time you're writing a one word answer, stop, think to yourself: "Does this provide anything?", realise the answer is "no", and then press backspace
|
On May 26 2018 20:10 bo1b wrote:
With gratuitous template usage you can make c++ faster then c, at least when the problem crosses a certain threshold of complexity. There are many reasons c++ is used pretty much universally where time matters the most, more then anything. And then there are reasons why it's not used in operating system development, many to do with run time size and how it compiles, believe it or not c++ and c do not compile to the same machine code.
Again, c++ is only as safe as you allow yourself to be, as soon as you start using templates you'll start enjoying that "safety"
yes. i think inlining, copy-elision, etc, etc, is also worth mentioning when discussing performance. the prevalence of high-quality header-only libraries makes the thought of letting everything run through python unbearable just in terms of the potential compiler magic you miss out on.
|
On May 26 2018 20:13 sc-darkness wrote:What operating systems have been developed since C++ became popular though? 
Tizen, Android, Symbian to name major ones but just to be clear i dont know detalis of their implementation.
Edit: Apparently Tizen is written both in C and C++
|
On May 26 2018 20:50 Excludos wrote:Show nested quote +On May 26 2018 20:47 nunez wrote:On May 26 2018 20:26 Excludos wrote:On May 26 2018 08:53 nunez wrote:
@excludos
qt should be quarantined to the code that deals with the gui, and even there it should be used as sparingly as possible. for that it's an ok option, but for anything else there are better alternatives. if someone suggested that we use qt for signals / slots at work, he / she would also be quarantined to code that deals with gui.
some never get comfortable with the complexity of c++, and seek refuge in the abstract comfort of Qt or C# or python or whatever. parading this retreat as ersatz critique seems common. What do you base your answer on here? Qt has loads of plugins and tools for back end purposes and is made to work equally well for that as front end. I wouldn't suggest you use it just because of signals and slots, but because it literally has an answer for all of your problems (Hyperbole of course. There's loads of things it doesn't do as well. Like heavy calculations or image operations). A lot of those problems can be solved with a external library each..or you can just remove all of them and use Qt instead. I'm also not saying it's the only tool for the job or something you must use in all situations, just that it's very good for a lot of them, and not something you should just dismiss based on..whatever you think you're basing it on. I don't know what kind of misconceptions you have about it, but I'd love to know experience. Again why bother with non-answers such as these? It's so damn pointless. Next time you're writing a one word answer, stop, think to yourself: "Does this provide anything?", realise the answer is "no", and then press backspace
it's my honest answer.
|
On May 26 2018 19:54 bo1b wrote:
std::vector<int> sortThis = {3, 6, 1, 9, 8, 2, 0, 5, 7, 4};
std::sort(sortThis.begin(),sortThis.end());
modern (ok, ranges is not quite here yet, but very soon):
std::vector v{3,6,1,9,8,2,0,5,7,4};
std::sort(v);
|
edit: fuck it. I have better things to do than feeding a troll
|
On May 26 2018 21:05 nunez wrote:Show nested quote +On May 26 2018 19:54 bo1b wrote:
std::vector<int> sortThis = {3, 6, 1, 9, 8, 2, 0, 5, 7, 4};
std::sort(sortThis.begin(),sortThis.end()); modern (ok, ranges is not quite here yet, but very soon): std::vector v{3,6,1,9,8,2,0,5,7,4};
std::sort(v);
Initializer list reminds me of something I've read from Google's C++ Code Style. To feed C++ haters:
std::vector<int> v(100, 1); // A vector containing 100 items: All 1s.
std::vector<int> v{100, 1}; // A vector containing 2 items: 100 and 1.
|
Most kernels use multiple languages. For Android/Linux/MacOS, most of it is in C. C++ for some small parts and C#/Java/Objective-C for libraries. Some assembly when needed. These days, the arguments pro/con C++ are quite outdated and often show an unwillingness to try new things. True, GC was pathetic in the early days but now manual memory management isn't necessarily better because ARC has issues than GC doesn't. ARC adds memory overhead, trashes the cache, can cause unpredictable pauses, requires special handling to break cycles, is unfriendly to multi-threaded programs, etc.
My advice would be: don't overthink that stuff and have fun. The language is just a tool and no tool is the best for every scenario. If you spend your energy defending your favorite language, you will miss out on many of the other cool stuff out there.
|
I don't know how C++ shared_ptr is implemented, but unique_ptr is neither ARC nor GC. It's simply deallocated when it's out of scope without magic from compiler. It's so simple: constructor allocates, scope ends, then destructor is called and memory is released.
void SomeFunction()
{
// constructor is called here
std::unique_ptr<Class> obj = std::make_unique<Class>(parameters);
obj.method();
} // memory is deallocated when scope ends here which means Class' destructor is called
I'd pick modern C++ memory management over GC any day. I just don't stand checking memory usage of my program, then wondering if it's leaking memory or if GC hasn't kicked in. Also, when will memory be released? It's so annoying.
|
On May 26 2018 21:21 sc-darkness wrote:Show nested quote +On May 26 2018 21:05 nunez wrote:On May 26 2018 19:54 bo1b wrote:
std::vector<int> sortThis = {3, 6, 1, 9, 8, 2, 0, 5, 7, 4};
std::sort(sortThis.begin(),sortThis.end()); modern (ok, ranges is not quite here yet, but very soon): std::vector v{3,6,1,9,8,2,0,5,7,4};
std::sort(v); Initializer list reminds me of something I've read from Google's C++ Code Style. To feed C++ haters: Show nested quote +
std::vector<int> v(100, 1); // A vector containing 100 items: All 1s.
std::vector<int> v{100, 1}; // A vector containing 2 items: 100 and 1.
yes... i was aiming for class template argument deduction though. maybe you picked up on that, i couldn't tell.
|
Sweden33719 Posts
Jinro unfortunately not everything is written in c/c++ with a python library attached, and for those many cases getting dirty with a lower level language is sometimes unavoidable. I also disagree to a certain degree about not needing to know the underlying library, if only because an awful lot of it is years or decades old and may not interface well with the newest version or w/e language you're running.
I've already experienced that second one on my own (actually almost the very first project I ever attempted a few years back, I ran into it) so I see what you mean!
|
On May 26 2018 21:38 nunez wrote:Show nested quote +On May 26 2018 21:21 sc-darkness wrote:On May 26 2018 21:05 nunez wrote:On May 26 2018 19:54 bo1b wrote:
std::vector<int> sortThis = {3, 6, 1, 9, 8, 2, 0, 5, 7, 4};
std::sort(sortThis.begin(),sortThis.end()); modern (ok, ranges is not quite here yet, but very soon): std::vector v{3,6,1,9,8,2,0,5,7,4};
std::sort(v); Initializer list reminds me of something I've read from Google's C++ Code Style. To feed C++ haters:
std::vector<int> v(100, 1); // A vector containing 100 items: All 1s.
std::vector<int> v{100, 1}; // A vector containing 2 items: 100 and 1.
yes... i was aiming for class template argument deduction though. maybe you picked up on that, i couldn't tell.
Well, since this is C++14, I definitely didn't mean something from C++17. I doubt C++17 will change it for backwards compatibility reasons. It's just that braces change semantics in that example which is one of the ugly sides of C++, but it's totally avoidable.
|
|
|
Did you see example?
std::vector<int> v(100, 1); // A vector containing 100 items: All 1s.
std::vector<int> v{100, 1}; // A vector containing 2 items: 100 and 1.
The second line is C++14 (uniform initialization & initializer list). It's ugly to have 2 different outcomes based on what brackets you use. Luckily, this could be avoided with good coding conventions.
|
On May 26 2018 21:32 sc-darkness wrote:I don't know how C++ shared_ptr is implemented, but unique_ptr is neither ARC nor GC. It's simply deallocated when it's out of scope without magic from compiler. It's so simple: constructor allocates, scope ends, then destructor is called and memory is released.
void SomeFunction()
{
// constructor is called here
std::unique_ptr<Class> obj = std::make_unique<Class>(parameters);
obj.method();
} // memory is deallocated when scope ends here which means Class' destructor is called
I'd pick modern C++ memory management over GC any day. I just don't stand checking memory usage of my program, then wondering if it's leaking memory or if GC hasn't kicked in. Also, when will memory be released? It's so annoying.
Yes, but unique_ptr fills this particular role only. shared_ptr is ARC.
|
initializer-lists are c++14 now? hm... i don't know kev.
vector (see overload 8)
initializer_list (see initializer_list)
|
Ok, I don't remember correctly then. Uniform initialization is what makes the second example ugly then.
All of them are 10.
int number(10);
int number{10}; // uniform initialization
int number = 10;
It's not the same story here.
std::vector<int> v(100, 1); // A vector containing 100 items: All 1s.
std::vector<int> v{100, 1}; // A vector containing 2 items: 100 and 1.
^ uniform initialization
|
list_initialization
in particular:
Otherwise, the constructors of T are considered, in two phases:
All constructors that take std::initializer_list as the only argument, or as the first argument if the remaining arguments have default values, are examined, and matched by overload resolution against a single argument of type std::initializer_list.
don't see why this is c++14.
note, you're using direct-list-initialization, see (1).
|
Yes, same problem regardless if it's C++11 or C++14. Just different standard. It doesn't really matter which of the two it is. It's still going to compile with recent compilers.
So you're saying it's only fine because it's a better match to compiler. I understand that. I'm just against confusing syntax in that case. They should be significantly more different than a single character. The question is, do you agree or not?
|
|
|
|
|
|
EPT
