Announcement

Collapse
No announcement yet.

C++17 Is Near, A Look At The New Features

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • doom_Oo7
    replied
    Originally posted by discordian View Post
    Not extensible enough (hardware debugging?)
    ... Did you look at the manual ? It handles hardware debugging without problems : http://doc.qt.io/qtcreator/creator-d...baremetal.html

    Leave a comment:


  • coder
    replied
    Seems like there are a lot of true believers, in this thread.

    Originally posted by cj.wijtmans View Post
    You should seriously be banned for your bs.
    C'mon, guys. Experience has taught me that one might be less right, and the other person less wrong than you might think. And insults really undermine your case. People with strong arguments generally have no use for them, so they make you look weak.

    There's not always a singular, correct approach to solve every problem. Languages are just tools for solving problems. They each have strengths and weaknesses. By learning a new language, you might discover a different way of approaching certain problems, and that will probably make you a better programmer. So, try and keep an open mind.

    Given that we're all on this board, and in this thread, we certainly share many common interests and views. Internecine violence is some of the most tragic, if not the worst. Try to be respectful, at least.

    Leave a comment:


  • DanLamb
    replied
    Originally posted by discordian View Post
    I don`t know about clion, but MSVC is good... aslong as you let it handle everything. As soon as you want to handle some Makefile or CMake based builds, it will cause significant trouble.
    Yeah, I am not too happy about the state of IDEs either, if you need some good crossplatform (other OS, or no OS) and hardware debugging support you will likely end up with eclipse, or something based on it.

    Someone should pay me to write one, using the LLVM / Clang Libs, I`d be interested in doing that =)
    CLion has full CMake support. It infers project structure details from CMake files and won't modify your CMake unless you want it to. CLion has a normal source debugger, I don't know what "hardware debugging support" is.

    Eclipse has slowly fallen out of favor over the past decade. JetBrains generally makes the best IDEs. Most Python teams prefer PyCharm, in the Java/Scala worlds IntelliJ is the most popular, in Ruby RubyMine is the most popular, for JavaScript including Node and HTML WebStorm, and for a database GUI, DataGrip is the best.

    I haven't done heavy C++ development in recent years, so I haven't used CLion, but that looks great from the outside.

    Leave a comment:


  • cj.wijtmans
    replied
    Originally posted by mmstick View Post
    It's very much a part of C++, and it's imported in C++ projects through the std namespace: `std::string` and `std::vector`.
    This i believe is changing in new C++ standards. But NOTHING is imported in C++. STL is just c++ code that is included. STL is as the name describes just a standard library that platforms/toolchains can have its own implementation of to do whatever optimization they like. Including using realloc if they wish.
    Originally posted by mmstick View Post
    If you want vectors in C++, the STL is where you go. Likewise, the same applies to strings.
    Not really. STL can be very inefficient and sometimes it would be better to turn to a different library. Which is one of the reasons for accelarated standard releases in the first place as the limitations caused STL implementations to be slow and make to many copies.
    Originally posted by mmstick View Post
    What you're referring to is not a `C++ String`. That is a byte/character array, basically a `C String`.
    They are the same. C++ is designed to be C compatible. STL string is something else.
    Originally posted by mmstick View Post
    An actual string is a structure that handles UTF-8/16 text and supports reallocation / shrinking / growing. Basically, an actual string type is in the form of `std::string`.
    Says who?
    Originally posted by mmstick View Post
    Reducing yourself to byte arrays for all your string handling is simply bad design. No one should allow you to code in their codebases.
    Nevertheless it is what a string/literal is in C++ and C and it will remain as such as long as there are string literals in the binary. Same for Rust or any language for that matter.

    Originally posted by mmstick View Post
    So you're admitting that you're twelve?
    Projection.

    Leave a comment:


  • pipe13
    replied
    Well... not to be argumentative or anything, but for vectors STL is not the only place I go. Depends what they're vectors of, and what I want them for. Likewise std::strings are nice, but QStrings are frequently nicer. And not that I'd stoop so low myself (unless I'm forced to by MPI), but coder could possibly lend an example (or two) where byte arrays were in fact very good design...

    Leave a comment:


  • mmstick
    replied
    Originally posted by cj.wijtmans View Post
    Ever heard of custom allocators? And you dont HAVE TO use STL. And STL is not really an internal part C++.
    It's very much a part of C++, and it's imported in C++ projects through the std namespace: `std::string` and `std::vector`.

    If you want vectors in C++, the STL is where you go. Likewise, the same applies to strings.

    STL strings are not the same as a C++ string(which are basically literals or pointers to a null terminated block in memory)
    What you're referring to is not a `C++ String`. That is a byte/character array, basically a `C String`.

    An actual string is a structure that handles UTF-8/16 text and supports reallocation / shrinking / growing. Basically, an actual string type is in the form of `std::string`.

    Reducing yourself to byte arrays for all your string handling is simply bad design. No one should allow you to code in their codebases.

    You should seriously be banned for your bs.
    So you're admitting that you're twelve?

    Leave a comment:


  • pipe13
    replied
    Originally posted by cj.wijtmans View Post
    Ever heard of custom allocators? And you dont HAVE TO use STL. And STL is not really an internal part C++. Just as you did not understand that STL strings are not the same as a C++ string(which are basically literals or pointers to a null terminated block in memory).

    You should seriously be banned for your bs.
    FIFY. Us programmers are serious stuff. Or seriously stuffed. But not that seriously stuffed

    Leave a comment:


  • cj.wijtmans
    replied
    Originally posted by mmstick View Post
    vectors in C++ cannot use realloc,
    Ever heard of custom allocators? And you dont HAVE TO use STL. And STL is not really an internal part C++. Just as you did not understand that STL strings are not the same as a C++ string(which are basically literals or pointers to a null terminated block in memory).

    You should seriously be banned for your bs.

    Leave a comment:


  • liam
    replied
    Originally posted by igouy View Post

    I guess, until you share with everyone something you would describe as "a reliable language comparison tool".

    Meanwhile, the performance section of the Rust FAQ points to

    https://www.rust-lang.org/en-US/faq.html#performance

    It also points to https://github.com/kostya/benchmarks

    Leave a comment:


  • tinko
    replied
    Originally posted by coder View Post
    Lol! wut?

    Wow, that's entirely not what I was talking about. I mean that an update to a language standard probably shouldn't change it so drastically that expert practitioners in the old standard can be virtually reduced to the level of newbies.
    That is not, what's happening. The C++-experts I know, are still experts, even though some features of C++14 are new to them. I've looked at the list of expected C++17-feature and I fail to see anything that looks like it would change the code it is used in, to something that would be harder to understand for me, based on my experience with C++. Also, being an expert requires to learn new stuff in ones area of expertise. Please point to some examples of features, that make code incomprehensible for experts of the previous C++ standard.

    IMO, the goal of updating a language standard shouldn't be to make a language into something it wasn't, but rather to fine-tune it to be a better version of the tool it already is. So, the mere suggestion of features like garbage collection really get my hackles up. If I want a garbage-collected language, I'll use something else, thank you. C++ does not need to be all things to all people.
    That's a straw man argument because the people developing future C++ standards are not making C++ into all things to all people and nobody is seriously suggesting to have a non-optional garbage collector. I still control what memory I use, even though shared_ptr (which I haven't needed yet, thankfully) and more importantly unique_ptr allow me to express certain aspects of that in a safer and more expressive way that allows me to make better use of tool support and catch more bugs with the compiler, without adding any overhead (I would only use shared_ptr in cases, where I would do reference counting anyway).

    I still know exactly which types all my values are, even though "auto" makes the code easier to read than some long class name, easier to change types and so on, while losing no benefit of static typing, producing no runtime-overhead and losing no tool- and compiler-support. "auto" makes stuff easier to use, more readable and more flexible, without pulling any unpredictable, black magic runtime type trickery, that some interpreted languages have, into C++.

    With ranged-based for-loops I can write down 95% of the for-loops in a more readable way with equivalent functionality, that is closer to the way I think about the algorithm and the code tells everything important about the iteration in the first line. What better way is there, to tell the reader, what might and what might not happen to the elements than for(const auto& item : list), for(auto item : list), for(auto& item : list)? Certainly not the almost zero-information for(long_iterator_class_name item_it=list.begin();item_it!=list.end();++item_it ) type_i_know_from_the_list_anyway item = *item_it; which says almost always the same thing, except when one got used to gloss over it and misses it, when it would actually say something meaningful, or mistypes it at the end of a day in a rarely visited code path and have it blow up at runtime much later.

    These are just some examples. They provide convenience and more safety at zero cost. They do not change there scope of the language. They do not change what happens in memory (that would affect the performance). If you think, C++ is trying to become all things for all people, please point out some new features that are the reason you believe that.

    Leave a comment:

Working...
X