• Isn't it better using Qt than the 'standerd' C++?

    From wij@totalbb.net.tw@21:1/5 to All on Thu Feb 25 08:26:22 2016
    C++ says it is a system language but it's not true.
    C++ can't replace C. I don't think C++ is willing to cover those
    things C solved, even not for shell script!

    Nowadays most parts has gone farther away for 'high-end' application programmer's favor (let alone what that favor might really be), but
    remains not practical if compared to Qt(before version 4).
    So what's the problem with C++?
    It seems C++ can only be used as a base language for other languages.


    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Bonner@21:1/5 to w...@totalbb.net.tw on Thu Feb 25 09:20:31 2016
    On Thursday, 25 February 2016 15:30:18 UTC+1, w...@totalbb.net.tw wrote:
    C++ says it is a system language but it's not true.

    Why not?

    C++ can't replace C.

    I can't think of technical reasons why C++ can't replace C (there are
    political reasons like "Linus can't stand C++, so won't allow it in the
    Linux kernel").

    I don't think C++ is willing to cover those
    things C solved, even not for shell script!

    Nowadays most parts has gone farther away for 'high-end' application programmer's favor (let alone what that favor might really be), but
    remains not practical if compared to Qt(before version 4).

    Sorry, I don't understand what you are trying to say here.

    So what's the problem with C++?
    It seems C++ can only be used as a base language for other languages.

    I am writing C++ for an embedded device right now.


    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Wouter van Ooijen@21:1/5 to All on Thu Feb 25 09:46:52 2016
    Op 25-Feb-16 om 3:26 PM schreef wij@totalbb.net.tw:

    C++ says it is a system language but it's not true.
    C++ can't replace C. I don't think C++ is willing to cover those
    things C solved, even not for shell script!

    Nowadays most parts has gone farther away for 'high-end' application programmer's favor (let alone what that favor might really be), but
    remains not practical if compared to Qt(before version 4).
    So what's the problem with C++?
    It seems C++ can only be used as a base language for other languages.

    That's a nice bag of assertions. Do you have anything to back it up?

    So far I have found only two good reasons to favour C over C++ for small embedded systems (and the second one actually is quite weak):

    - there is no C++ compiler available for my target (eg. PIC
    micro-controllers)

    - my people can't handle C++, they will start using features in a wrong
    way, and afterwards we won't be able to read (understand) what they have
    done.

    Note that using C++, especially on small systems, doesn't mean 'dive in
    head first and use every feature the language has to your hart's
    content'. That would result in a disaster! But if you used C that way it
    would be equally disastrous.

    For a suggestion on what C++ *not* to use on a small system, check http://www.voti.nl/blog/?p=114

    Wouter van Ooijen




    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From wij@totalbb.net.tw@21:1/5 to All on Fri Feb 26 06:47:19 2016
    { quoted server banner redacted. -mod }

    On Thursday, February 25, 2016 at 10:30:18 PM UTC+8, w...@totalbb.net.tw
    wrote:
    C++ says it is a system language but it's not true.
    C++ can't replace C. I don't think C++ is willing to cover those
    things C solved, even not for shell script!

    Nowadays most parts has gone farther away for 'high-end' application programmer's favor (let alone what that favor might really be), but
    remains not practical if compared to Qt(before version 4).
    So what's the problem with C++?
    It seems C++ can only be used as a base language for other languages.


    I'm not talking about any specific programming task for any specific IC.
    C++ can pack assembly codes as any customized BASIC language can as well,
    and declare the language can do embeded programming.
    Let's formalize the question:

    Evalu(Task)=Money/Time
    Task= a programming task from a customer.
    Money= the money for exchange for Task
    Time= time before delivering the program for Money

    The question now is how for a programmer to maximize Evalu in this
    formula. the focus is on Time.
    Time involves all the resources available(with cost), and the future Task1,Task2,Task3... shoud be considered in different circumstances.
    A typical Task is an application like: POS, web site, web pages, music,
    data base, CAD, games, editors, FTP client/server,..,etc.

    From my collected data, C++ is around the top4 choice. If a programmer
    chose C++, there are actually many variations to choose. The main issue
    here is that C++ conforming codes can do so little and so complex!


    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Francis Glassborow@21:1/5 to wij@totalbb.net.tw on Fri Feb 26 06:47:43 2016
    On 25/02/2016 14:26, wij@totalbb.net.tw wrote:

    C++ says it is a system language but it's not true.
    C++ can't replace C. I don't think C++ is willing to cover those
    things C solved, even not for shell script!

    Well you obviously do not know the efforts that have been made to ensure
    that 99% of C compiles as C++ with exactly the same results. There are a
    few essential differences such as whether what are fundamental types.
    For example C++ found it easy to add complex types via its library
    whereas C has to add new types as fundamental ones.


    Nowadays most parts has gone farther away for 'high-end' application programmer's favor (let alone what that favor might really be), but
    remains not practical if compared to Qt(before version 4).
    So what's the problem with C++?
    It seems C++ can only be used as a base language for other languages.

    I have no idea what you think you are writing because C tends to be the language that niche languages translate to.

    Even the motor industry makes enough use of C++ for programming the
    multitude of embedded processors in modern cars that it has found it
    necessary to have enforced code standards to ensure safety.

    However there remain a number of small embedded processors that require dialects (note that, not standard) of C with special extensions. These
    are niche in one way but actually represent a very large proportion of
    all processors used today. The market is limited and so it is supported
    by a small number of small specialist companies that provide the
    modified C compilers and support tools necessary.

    C++ has been leading the efforts to support concurrent programming as
    well as many other areas that modern hardware development require for
    effective and portable use.

    During the 90's and fist decade of the 21st century the active
    participation in standards work for C++ was around 50 - 70. Currently
    the attendance at standards meetings for C++ exceeds 100 with at least
    as many other non-attending active contributors. When we recognise that
    these are largely highly paid high performing employees in the industry
    whose time is being contributed free by employers I think the evidence
    goes against your speculations.

    Francis




    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Cholo Lennon@21:1/5 to wij@totalbb.net.tw on Fri Feb 26 09:30:17 2016
    On 02/25/2016 11:26 AM, wij@totalbb.net.tw wrote:

    C++ says it is a system language but it's not true.
    C++ can't replace C. I don't think C++ is willing to cover those
    things C solved, even not for shell script!



    Nowadays most parts has gone farther away for 'high-end' application programmer's favor (let alone what that favor might really be), but
    remains not practical if compared to Qt(before version 4).
    So what's the problem with C++?
    It seems C++ can only be used as a base language for other languages.


    I work for a company that develop telecommunication software. Our
    applications are multiplatform (Windows/Linux x86/x86_64 and Solaris Intel/Sparc). We mostly use standard C++/boost and some third party
    libraries. In any case we need/use QT, so IMO it all depends on the context/domain of your software. QT is a nice (and big) library but is
    not for all software.


    Regards


    --
    Cholo Lennon
    Bs.As.
    ARG


    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?ISO-8859-1?Q?=D6=F6_Tiib?=@21:1/5 to w...@totalbb.net.tw on Fri Feb 26 09:31:19 2016
    On Friday, 26 February 2016 14:50:16 UTC+2, w...@totalbb.net.tw wrote:
    Let's formalize the question:

    Evalu(Task)=Money/Time
    Task= a programming task from a customer.
    Money= the money for exchange for Task
    Time= time before delivering the program for Money

    The question now is how for a programmer to maximize Evalu in this
    formula. the focus is on Time.

    Why? "Time" does not matter if no one wants to pay that "Money" for
    the result. So the issue is how to write somewhat better program than
    your competitors, not how to do it most quickly.


    Time involves all the resources available(with cost), and the future Task1,Task2,Task3... shoud be considered in different circumstances.
    A typical Task is an application like: POS, web site, web pages, music,
    data base, CAD, games, editors, FTP client/server,..,etc.

    C++ has relatively good development tool support, large amount of
    libraries (like that Qt) and resulting products have typically good performance. Development time is about same as with other
    programming languages.


    From my collected data, C++ is around the top4 choice. If a programmer
    chose C++, there are actually many variations to choose. The main issue
    here is that C++ conforming codes can do so little and so complex!

    Writing good software is complex in every language. Writing bad software
    is wasted effort.


    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James K. Lowden@21:1/5 to ootiib@hot.ee on Fri Feb 26 15:46:08 2016
    On Fri, 26 Feb 2016 09:31:19 CST
    Öö Tiib <ootiib@hot.ee> wrote:

    C++ has relatively good development tool support, large amount of
    libraries (like that Qt)

    It's funny you say that. I've always found C++ libraries (outside
    Boost) to be quite scattered and of variable quality. Just to take one example, Stroustrup frequently cites a standard DBMS library as an
    important void. C ++ has nothing resembling the CPAN for Perl, for
    example. I'd argue Python's library support is much better.

    On the tool side, I suppose if you're programming in Windows you have
    pretty good project & debugging support, once you squelch the
    self-serviing warnings about using standard library functions. Microsoft
    helps you better with their libraries than yours, though. You can
    highlight fopen and press F1 or whatever to see the documentation, but
    afaik there's no feasible way to reproduce that support for private
    libraries. And of course you have to be prepared with Visual Studio's definiton of "project", keep up with its continual churn.

    On Linux we're still partying like it's 1995, often relying on tools
    like cscope that were (and are) developed for C. Try, for example,
    showing in gdb the elements in a map whose key matches a regular
    expression. The complexity alone of tools like Emacs Development
    Environment make it hard to recommend, except for the dearth of
    alternatives.

    In my experience with large code bases -- millions of lines --
    otherwise adequate tools just fall over. Visual Studio simply did not
    function with 1000's of files in 2013. I've never seen any tool that
    could deal with giant code bases and do simple things like jump to a
    function definition or find all the places where a given function is
    called. (cscope will, but it can't distinguish between a.f () and b.f
    ()). On the evidence, there's no market for tools for large
    codebases. Either no tools exist or, if they do, many firms that would
    benefit from them choose not to.

    Some of these issues could be solved by reflection: by standardizing
    the metadata provided to debuggers, and including them as part of the
    language. But for that we're going to have to wait for C++2x (at
    least), because the meagre efforts in that direction to date come
    nowhere near what's possible or needed.

    --jkl


    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard@21:1/5 to All on Fri Feb 26 19:29:11 2016
    [Please do not mail me a copy of your followup]

    "James K. Lowden" <jklowden@speakeasy.net> spake the secret code <20160226154539.bb50c6517d97089efaf8d17a@speakeasy.net> thusly:

    On Fri, 26 Feb 2016 09:31:19 CST
    Öö Tiib <ootiib@hot.ee> wrote:

    C++ has relatively good development tool support, large amount of
    libraries (like that Qt)

    It's funny you say that. I've always found C++ libraries (outside
    Boost) to be quite scattered and of variable quality. Just to take one >example, Stroustrup frequently cites a standard DBMS library as an
    important void. C ++ has nothing resembling the CPAN for Perl, for
    example. I'd argue Python's library support is much better.

    It seems the community agrees with you about package management.
    There are many parallel efforts on this front. The one I like is
    Hunter <http://github.com/ruslo/hunter>.

    On the tool side, I suppose if you're programming in Windows you have
    pretty good project & debugging support, once you squelch the
    self-serviing warnings about using standard library functions.

    Recent releases of Visual Studio have gotten better about the defaults
    being more oriented towards ISO C++. For instance, the new console
    project template no longer includes <tchar.h> and supplies the
    TCHAR-ized version of main. Instead you get a reasonable default
    project with an ISO C++ standard main function.

    Microsoft
    helps you better with their libraries than yours, though. You can
    highlight fopen and press F1 or whatever to see the documentation, but
    afaik there's no feasible way to reproduce that support for private >libraries.

    While this would be nice, let's be honest and F1 in Visual Studio
    these days just does a glorified web search. The content isn't even
    installed locally anymore by default, although you can install
    documentation for the local help viewer if you prefer to work
    "disconnected". When I've asked other VS C++ developers about the
    help viewer (I actually think the old one was better), most of them
    said they never used the help viewer and just used google. So if your
    API documentation is visible to google (and not all of them are), then
    what developers are already doing is going to be just fine.

    And of course you have to be prepared with Visual Studio's
    definiton of "project", keep up with its continual churn.

    I'm not sure which "churn" you're talking about here. Are you talking
    about changes to project files because of files being
    renamed/added/removed to a project or are you making some reference to
    new version of Visual Studio changing the project file format?

    If the former, I've found that CMake is a pretty good way of handling
    that -- use CMake for you build and don't commit the project files
    and things stay up-to-date as you edit the CMake project description.
    Works great for Xcode on Mac and CLion on Linux too. Of course this
    requires that you switch to using CMake as your build description.
    For new projects, this is what I would recommend. For existing
    projects, you have to weigh the day-to-day pain of maintaining your
    existing build vs. the pain of converting to CMake and it's day-to-day
    pain of maintenance.

    If the latter, you should be aware that VS has kept compatible project
    and solution file formats for the last 5 years, since VS 2010.

    On Linux we're still partying like it's 1995,

    More like 1989, LOL.

    In my experience with large code bases -- millions of lines --
    otherwise adequate tools just fall over. Visual Studio simply did not >function with 1000's of files in 2013.

    Every day I work in VS on a solution with 121 projects, ~5800 files
    and about 1M lines of code. Our solution/projects are VS 2010
    oriented, but I've recently switched to the VS 2015 IDE using the 2010
    toolset. ReSharper for C++ can get quite sluggish at times while
    chewing on this solution, but that's the only real big delay that I'm
    noticing in either VS 2010 or VS 2015. The benefits of R++ make it
    worth the wait.

    I used to routinely turn off intellisense in VS because it's results
    were inaccurate, slower than grepping the source code, and it caused a
    huge delay in processing solutions. In VS 2015, I turned it back on to evaluate Microsoft's refactoring support and it seems much improved vs
    earlier releases, but I still use R++ for navigation instead of VS intellisense.

    Of course, you should also be turning off virus scan and content
    indexing
    for your source and build trees. Both of those cause constant
    rescanning
    of the files in your project and create disk contention for VS and
    the compiler. Switching to a solid-state drive also helps :-).

    I've never seen any tool that
    could deal with giant code bases and do simple things like jump to a
    function definition or find all the places where a given function is
    called. (cscope will, but it can't distinguish between a.f () and b.f
    ()). On the evidence, there's no market for tools for large
    codebases. Either no tools exist or, if they do, many firms that would >benefit from them choose not to.

    clang's tool infrastructure is attempting to address this somewhat.
    clang-tidy supports both invoked-from-the-editor and invoked-as-batch
    type interactions to address refactoring on a larger scale. I would
    expect that the support people are using to integrate clang into vim
    and so-on would also help with navigation, although I haven't tried
    those myself as I work in CLion on Linux and VS on Windows. CLion
    does it's own parsing and again takes a while to chew on a very large
    project like LLVM+clang+clang-tools-extra. It feels like it takes
    even longer than ReSharper for C++, but I don't know if that's due to
    the differences in projects (LLVM+etc. vs. where I work) or due to
    Java vs. C#/C++ implementations or differences in parsers or whatever.

    Some of these issues could be solved by reflection: [...]

    Yeah, somewhat. However, I think modules are going to make a huge
    difference for IDEs because the vast majority of the time spent
    chugging in order to provide navigation and refactoring support is due
    to the reparsing induced by changes to headers.
    --
    "The Direct3D Graphics Pipeline" free book
    <http://tinyurl.com/d3d-pipeline>
    The Computer Graphics Museum <http://computergraphicsmuseum.org>
    The Terminals Wiki <http://terminals.classiccmp.org>
    Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>


    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From wij@21:1/5 to Francis Glassborow on Wed Mar 2 06:34:41 2016
    { quoted server banner redacted. -mod }

    On Friday, February 26, 2016 at 8:50:16 PM UTC+8, Francis Glassborow wrote:
    On 25/02/2016 14:26, wij@totalbb.net.tw wrote:

    C++ says it is a system language but it's not true.
    C++ can't replace C. I don't think C++ is willing to cover those
    things C solved, even not for shell script!

    Well you obviously do not know the efforts that have been made to ensure
    that 99% of C compiles as C++ with exactly the same results. There are a
    few essential differences such as whether what are fundamental types.
    For example C++ found it easy to add complex types via its library
    whereas C has to add new types as fundamental ones.


    Nowadays most parts has gone farther away for 'high-end' application programmer's favor (let alone what that favor might really be), but
    remains not practical if compared to Qt(before version 4).
    So what's the problem with C++?
    It seems C++ can only be used as a base language for other languages.

    I have no idea what you think you are writing because C tends to be the language that niche languages translate to.

    Even the motor industry makes enough use of C++ for programming the
    multitude of embedded processors in modern cars that it has found it necessary to have enforced code standards to ensure safety.

    However there remain a number of small embedded processors that require dialects (note that, not standard) of C with special extensions. These
    are niche in one way but actually represent a very large proportion of
    all processors used today. The market is limited and so it is supported
    by a small number of small specialist companies that provide the
    modified C compilers and support tools necessary.

    C++ has been leading the efforts to support concurrent programming as
    well as many other areas that modern hardware development require for effective and portable use.

    During the 90's and fist decade of the 21st century the active
    participation in standards work for C++ was around 50 - 70. Currently
    the attendance at standards meetings for C++ exceeds 100 with at least
    as many other non-attending active contributors. When we recognise that
    these are largely highly paid high performing employees in the industry
    whose time is being contributed free by employers I think the evidence
    goes against your speculations.

    Francis




    This remind me of the vanishing IC (hard-ware) dream.
    The stance of C++ is understandable (though any other language compatible
    with C can be equally powerful).
    Something wondered me that C++ added rref type, which effectively doubled
    the type complexity with few useful instances. don't know the language developers are aware of it or not.


    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Bonner@21:1/5 to wij on Wed Mar 2 11:07:30 2016
    On Wednesday, 2 March 2016 13:40:18 UTC+1, wij wrote:

    This remind me of the vanishing IC (hard-ware) dream.
    The stance of C++ is understandable (though any other language compatible with C can be equally powerful).
    Something wondered me that C++ added rref type, which effectively doubled
    the type complexity with few useful instances. don't know the language developers are aware of it or not.


    My experience of rvalue references is that they make some things *very*
    much easier. For example, I now write:

    const auto lock = LockMutex();

    whereas previously I had to write:

    const Lock lock(m_mutex);

    I couldn't do the locking in a member function before because the Lock
    object can't be copied. With r-value references however, it becomes
    entirely feasible to make it movable; so now I can return it. Similarly
    one can have standard containers which contain resource handling objects
    (so can't be sensibly copied, but can be moved).

    It does add complexity to the type system (although I'm not convinced
    by x2), but there is a huge benefit to it.


    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?ISO-8859-1?Q?=D6=F6_Tiib?=@21:1/5 to James K. Lowden on Sat Feb 27 07:16:06 2016
    On Friday, 26 February 2016 23:50:16 UTC+2, James K. Lowden wrote:
    On Fri, 26 Feb 2016 09:31:19 CST
    Öö Tiib <ootiib@hot.ee> wrote:

    C++ has relatively good development tool support, large amount of
    libraries (like that Qt)

    It's funny you say that. I've always found C++ libraries (outside
    Boost) to be quite scattered and of variable quality. Just to take
    one
    example, Stroustrup frequently cites a standard DBMS library as an
    important void. C ++ has nothing resembling the CPAN for Perl, for
    example. I'd argue Python's library support is much better.

    I agree about variable quality. What you want with several millions of
    C++ developers? Result is that there is mindbogglingly huge amount of
    bad C++ libraries and large amount of useful C++ libraries. What
    other programming language has such a library and tools available open
    source for anyone like for example Unreal Engine 4? Yes, Python indeed
    supports a subset of useful C++ libraries but why that makes it better?


    On the tool side, I suppose if you're programming in Windows you have
    pretty good project & debugging support, once you squelch the
    self-serviing warnings about using standard library functions.
    Microsoft
    helps you better with their libraries than yours, though.

    Same is with X-Code on Mac. It is understandable. In modern world we
    are spammed ads from each side and so should learn to filter. The IDEs
    can be silenced and extended with plugins from other parties.

    You can
    highlight fopen and press F1 or whatever to see the documentation, but
    afaik there's no feasible way to reproduce that support for private libraries. And of course you have to be prepared with Visual Studio's definiton of "project", keep up with its continual churn.

    There are some ways how to make Visual Studio bit more
    vocal: https://msdn.microsoft.com/en-us/library/ms177242.aspx
    I trust also Doxygen eats that "MS XML documenting".
    And of course it is possible to generate various project files
    (including Visual Studio) with CMake quite seamlessly.


    On Linux we're still partying like it's 1995, often relying on tools
    like cscope that were (and are) developed for C. Try, for example,
    showing in gdb the elements in a map whose key matches a regular
    expression. The complexity alone of tools like Emacs Development
    Environment make it hard to recommend, except for the dearth of
    alternatives.

    Linux is pile of "quite scattered and of variable quality" things.
    I prefer LLDB on Linux. Also all the -fsanitize of Clang work on
    Linux. Only those alone are good enough reason for to have Linux
    among platforms targeted. Python seems in far worse state when we
    talk about tools.


    In my experience with large code bases -- millions of lines --
    otherwise adequate tools just fall over. Visual Studio simply did not function with 1000's of files in 2013. I've never seen any tool that
    could deal with giant code bases and do simple things like jump to a
    function definition or find all the places where a given function is
    called. (cscope will, but it can't distinguish between a.f () and b.f
    ()). On the evidence, there's no market for tools for large
    codebases. Either no tools exist or, if they do, many firms that
    would
    benefit from them choose not to.

    C++ is among the few languages with what it is doable at all
    to make those monstrous code bases. The Visual Studio 2015 seems to
    work bit better with those. However when application grows over third
    of million of lines then I have so far suggested to split it into
    multiple processes if possible. It seems to save lot of money
    in the long run that way.


    Some of these issues could be solved by reflection: by standardizing
    the metadata provided to debuggers, and including them as part of the language. But for that we're going to have to wait for C++2x (at
    least), because the meagre efforts in that direction to date come
    nowhere near what's possible or needed.

    It is collective effort of ours. C, C++, Python and Javascript are free languages, not proprietary like C# or Java. So C++ goes where its users
    pull it.


    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?ISO-8859-1?Q?=D6=F6_Tiib?=@21:1/5 to wij on Thu Mar 3 06:27:48 2016
    On Wednesday, 2 March 2016 14:40:18 UTC+2, wij wrote:

    Something wondered me that C++ added rref type, which effectively doubled
    the type complexity with few useful instances. don't know the language developers are aware of it or not.

    You are correct that C++ has made it burden of programmer to precisely
    indicate the storage and life-time of values and nuances of indirection
    of variables/parameters. The other options like in Java that everything
    is just a garbage-collected pointer tend to be about 4 time less
    efficient in average with current technology. That may matter or not,
    depending on problem domain.


    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From wij@totalbb.net.tw@21:1/5 to Martin Bonner on Thu Mar 3 06:27:39 2016
    { quoted server banner redacted. -mod }

    On Thursday, March 3, 2016 at 1:10:16 AM UTC+8, Martin Bonner wrote:
    On Wednesday, 2 March 2016 13:40:18 UTC+1, wij wrote:

    This remind me of the vanishing IC (hard-ware) dream.
    The stance of C++ is understandable (though any other language
    compatible
    with C can be equally powerful).
    Something wondered me that C++ added rref type, which effectively
    doubled
    the type complexity with few useful instances. don't know the language developers are aware of it or not.


    My experience of rvalue references is that they make some things *very*
    much easier. For example, I now write:

    const auto lock = LockMutex();

    whereas previously I had to write:

    const Lock lock(m_mutex);

    I couldn't do the locking in a member function before because the Lock
    object can't be copied. With r-value references however, it becomes
    entirely feasible to make it movable; so now I can return it. Similarly

    If I understanding it correctly, as a syncronization object, mutex can't
    change address. The lock function(in object form) can be moved around
    in some way, though. I don't know your case, but in general, saying some feature is so good in several lines of codes is not sufficient (I came to
    C++ is because C contained many 'quirks' then. And, for higher level applications, C source programs are very unintuitive, particularly GUI).

    one can have standard containers which contain resource handling objects
    (so can't be sensibly copied, but can be moved).


    This is a major reason rref tried to solve.

    It does add complexity to the type system (although I'm not convinced
    by x2),

    Let's say. If adding a lllong int, many should be considered, type
    casting ,promotion, literals, i/o... that just one type (just mention
    something I knew, could not be the right term for C++ compiler)
    Adding rref?
    It can be applied to all types, present or future. At least, every class,
    about half of the members have the burden how to treat rref the right way whether you like it or not. Template class has more cases to think about,
    no matter you like it or not.
    As general variable, wondering how many cases is rref useful? how many
    can causing negative effects? (I don't use rref, no big deal to work around)

    but there is a huge benefit to it.

    There are many cases where rref are not so good and had to be considered
    ,and that triggered a language 'taboo': A language feature, particularly
    the core part, should consider not only the desirable part, but all the
    cases generated. A good language feature should in principle not enter
    this 'taboo' area where that feature is so undesirable and should be
    'disabled' (C++2011 provided a 'nice' delete)...

    PS. rephrase the "IC dream" mentioned in the previous post.
    STL had a soft-IC-to-hardware-IC dream. There're lots of impl. detail had
    to be exposed and thus standardized. That's my view and that lots of
    soul/energy have been burned around the dream. Probably and hopefully,
    something inivative will pop up in the end. But before that, I just wish
    many users like I'm one, just not be too much worried and bothered about
    those standardized impl. or new stuff, and spend your time/money there,
    unless you really need to use them.


    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard@21:1/5 to All on Fri Mar 4 11:01:38 2016
    [Please do not mail me a copy of your followup]

    =?ISO-8859-1?Q?=D6=F6_Tiib?= <ootiib@hot.ee> spake the secret code <778f8707-56b5-4ad2-9569-7a658ad2e78a@googlegroups.com> thusly:

    On Wednesday, 2 March 2016 14:40:18 UTC+2, wij wrote:

    Something wondered me that C++ added rref type, which effectively doubled
    the type complexity with few useful instances. don't know the language
    developers are aware of it or not.

    You are correct that C++ has made it burden of programmer to precisely >indicate the storage and life-time of values and nuances of indirection
    of variables/parameters.

    The way you describe it overstates the case. It isn't a "burden" to
    use std::vector<>, std::shared_ptr<> or other resource containers.
    They Just Work(TM).

    The "burden" comes from doing it the hard way like people do in C.
    --
    "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
    The Computer Graphics Museum <http://computergraphicsmuseum.org>
    The Terminals Wiki <http://terminals.classiccmp.org>
    Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>


    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?ISO-8859-1?Q?=D6=F6_Tiib?=@21:1/5 to w...@totalbb.net.tw on Fri Mar 4 06:44:01 2016
    On Thursday, 3 March 2016 14:30:20 UTC+2, w...@totalbb.net.tw wrote:
    On Thursday, March 3, 2016 at 1:10:16 AM UTC+8, Martin Bonner wrote:

    one can have standard containers which contain resource handling objects (so can't be sensibly copied, but can be moved).


    This is a major reason rref tried to solve.

    It not only "tried" but solved that. Copying lot of things does not make
    sense but moving some of those (like a thread or a file descriptor)
    makes sense. So now if we make classes that contain such things movable
    then we can use those in 'std::vector' or 'std::deque'.


    It does add complexity to the type system (although I'm not convinced
    by x2),

    Let's say. If adding a lllong int, many should be considered, type
    casting ,promotion, literals, i/o... that just one type (just mention something I knew, could not be the right term for C++ compiler)
    Adding rref?
    It can be applied to all types, present or future. At least, every class, about half of the members have the burden how to treat rref the right way whether you like it or not.

    Only the classes that manage resources of members "manually" (so have user-written destructor) *and* that makes sense to make movable *and*
    that developer wants to make movable need to have two additional
    members: move constructor and move assignment operator.

    That is rather rare need since classes that manage resources of members dynamically and "manually" are rare.

    Template class has more cases to think about, no matter you like it or
    not.

    As far as C++ is concerned there are no "template class" there is only
    "class template" that is "template for a class". Most difficult about
    class templates is to validate the template arguments to be fitting in
    a way that the diagnostics make sense. Otherwise those are quite similar
    to other classes.

    As general variable, wondering how many cases is rref useful? how many
    can causing negative effects? (I don't use rref, no big deal to work
    around)

    If you don't use move then all works like in C++03. No complexity added whatsoever. Then is hard to understand what you complain about.

    There are many cases where rref are not so good and had to be considered
    ,and that triggered a language 'taboo': A language feature, particularly
    the core part, should consider not only the desirable part, but all the
    cases generated. A good language feature should in principle not enter
    this 'taboo' area where that feature is so undesirable and should be 'disabled' (C++2011 provided a 'nice' delete)...

    I do not understand what 'taboo' was violated. Feature that was missing
    and was painful to implement manually (the move) was added. Dangerous
    extension of Microsoft compilers (those accepted temporaries as
    arguments for reference to non-const parameters) was made pointless
    so VS 2015 now finally warns about that.


    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?ISO-8859-1?Q?=D6=F6_Tiib?=@21:1/5 to Richard on Sat Mar 5 06:57:15 2016
    On Friday, 4 March 2016 19:10:19 UTC+2, Richard wrote:
    Öö Tiib <ootiib@hot.ee> spake the secret code <778f8707-56b5-4ad2-9569-7a658ad2e78a@googlegroups.com> thusly:

    On Wednesday, 2 March 2016 14:40:18 UTC+2, wij wrote:

    Something wondered me that C++ added rref type, which effectively
    doubled
    the type complexity with few useful instances. don't know the
    language
    developers are aware of it or not.

    You are correct that C++ has made it burden of programmer to
    precisely
    indicate the storage and life-time of values and nuances of
    indirection
    of variables/parameters.

    The way you describe it overstates the case. It isn't a "burden" to
    use std::vector<>, std::shared_ptr<> or other resource containers.
    They Just Work(TM).

    The "burden" comes from doing it the hard way like people do in C.

    I perhaps did not explain my thought clearly enough. The C programming
    language does same.

    C has more limited ways of passing values: as pointer to value or as
    copy of value. Pointer is more efficient on most cases but in C it
    is plain address and that results with most meta-information (what is
    pointed at objects lifetime?, may it be null? may it be freed? etc.)
    being
    lost for compiler and so programmer has to face all the dangers on his
    own.

    C++ added (lot more constrained) lvalue reference and rvalue reference
    to pointer and various library wrappers like smart pointers and
    iterators
    so now we have whole pile of different lot safer and more fitting
    reference types. Need for raw naked pointer in C++ is left only on rare
    corner cases. For example when one wants to have covariant return types.
    Rarely needed, average C++ programmer will likely fail to answer what covariants are.

    Result is lot safer in good hands but now the programmer has to learn to
    choose from that variety and so technically to understand and to
    indicate
    the details correctly during declaration.


    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From wij@totalbb.net.tw@21:1/5 to All on Sat Mar 5 06:58:08 2016
    { quoted server banner redacted. -mod }

    On Friday, March 4, 2016 at 8:50:17 PM UTC+8, Öö Tiib wrote:
    On Thursday, 3 March 2016 14:30:20 UTC+2, w...@totalbb.net.tw wrote:
    On Thursday, March 3, 2016 at 1:10:16 AM UTC+8, Martin Bonner wrote:


    one can have standard containers which contain resource handling
    objects
    (so can't be sensibly copied, but can be moved).


    This is a major reason rref tried to solve.

    It not only "tried" but solved that. Copying lot of things does not
    make
    sense but moving some of those (like a thread or a file descriptor)
    makes sense. So now if we make classes that contain such things
    movable
    then we can use those in 'std::vector' or 'std::deque'.


    It does add complexity to the type system (although I'm not
    convinced
    by x2),

    Let's say. If adding a lllong int, many should be considered, type
    casting ,promotion, literals, i/o... that just one type (just
    mention
    something I knew, could not be the right term for C++ compiler)
    Adding rref?
    It can be applied to all types, present or future. At least, every
    class,
    about half of the members have the burden how to treat rref the
    right way
    whether you like it or not.

    Only the classes that manage resources of members "manually" (so have user-written destructor) *and* that makes sense to make movable *and*
    that developer wants to make movable need to have two additional
    members: move constructor and move assignment operator.

    That is rather rare need since classes that manage resources of
    members
    dynamically and "manually" are rare.

    Template class has more cases to think about, no matter you like it
    or
    not.

    As far as C++ is concerned there are no "template class" there is only
    "class template" that is "template for a class". Most difficult about
    class templates is to validate the template arguments to be fitting in
    a way that the diagnostics make sense. Otherwise those are quite
    similar
    to other classes.

    As general variable, wondering how many cases is rref useful? how
    many
    can causing negative effects? (I don't use rref, no big deal to work
    around)

    If you don't use move then all works like in C++03. No complexity
    added
    whatsoever. Then is hard to understand what you complain about.

    There are many cases where rref are not so good and had to be
    considered
    ,and that triggered a language 'taboo': A language feature,
    particularly
    the core part, should consider not only the desirable part, but all
    the
    cases generated. A good language feature should in principle not
    enter
    this 'taboo' area where that feature is so undesirable and should be 'disabled' (C++2011 provided a 'nice' delete)...

    I do not understand what 'taboo' was violated. Feature that was
    missing
    and was painful to implement manually (the move) was added. Dangerous extension of Microsoft compilers (those accepted temporaries as
    arguments for reference to non-const parameters) was made pointless
    so VS 2015 now finally warns about that.


    Firstly, I'd to appologize and thank guys tolerating the English I
    composed.

    It was not really a complain.
    I use just a single enum symbol for all the purposes I need. No
    experience
    felt the need from rref (and std:: things except few) for these 13+
    years.
    So, naturally, rref(+std::move) seems, not only to me, like killing a
    fly
    with cannons (modifying core language). So as so, naturally again, many usecases seem to me really trivial. Nontheless, they are valid, well
    formed C++ codes.

    With rref (and std::...), we are in two different C++ worlds.
    (an ominous for the language developers that another 'C++ quirks' might
    have born beside the prouded 'exception'. I'm an user.)

    Let 'Temporary object' be another issue. That no words have ever been
    heard
    about the relationship between an object and the copy constructed object
    really suprised me since the begining. This is mentioned because it
    might
    be as well suprisingly useful. Again, I'm an user, thinking another way
    like why not the language be more honest, stop playing smart, just
    declare
    an user detectable temporary and say it loudly the compiler has (so weak
    if
    exaggerated) created a temporary? A type,..,or macro, all better than
    rref.
    Well, rref is already there(+std::move). That's an example of overdo.

    I don't know Java. Garbage-collector based languages should be entirely
    a
    different thing. The fundamental concept of temporary object or even
    'object' could be very different. The meaning of direct comparison...?


    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)