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

[w...@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.


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

[Martin Bonner]

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.

[Wouter van Ooijen]

Op 25-Feb-16 om 3:26 PM schreef w...@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

[Francis Glassborow]

On 25/02/2016 14:26, 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!

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

[w...@totalbb.net.tw]

{ 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!

[Cholo Lennon]

On 02/25/2016 11:26 AM, 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 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

[Öö Tiib]

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.

[James K. Lowden]

On Fri, 26 Feb 2016 09:31:19 CST
嘱 Tiib <oot...@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

[Richard]

[Please do not mail me a copy of your followup]

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

>On Fri, 26 Feb 2016 09:31:19 CST
>嘱 Tiib <oot...@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>

[Öö Tiib]

On Friday, 26 February 2016 23:50:16 UTC+2, James K. Lowden wrote:
> On Fri, 26 Feb 2016 09:31:19 CST
> 嘱 Tiib <oot...@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.

[wij]

{ quoted server banner redacted. -mod }

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.

[Martin Bonner]

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.

[Öö Tiib]

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.

[w...@totalbb.net.tw]

{ 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.

[Öö Tiib]

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.

[Richard]

[Please do not mail me a copy of your followup]

=?ISO-8859-1?Q?=D6=F6_Tiib?= <oot...@hot.ee> spake the secret code
<778f8707-56b5-4ad2...@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>

[w...@totalbb.net.tw]

{ quoted server banner redacted. -mod }

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...?

[Öö Tiib]

On Friday, 4 March 2016 19:10:19 UTC+2, Richard wrote:
> 嘱 Tiib <oot...@hot.ee> spake the secret code

> <778f8707-56b5-4ad2...@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.


--