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.
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.
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.
From my collected data, C++ is around the top4 choice. If a programmerchose C++, there are actually many variations to choose. The main issue
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.
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.
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 programmerchose C++, there are actually many variations to choose. The main issue
here is that C++ conforming codes can do so little and so complex!
C++ has relatively good development tool support, large amount of
libraries (like that Qt)
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,
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: [...]
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.
On Fri, 26 Feb 2016 09:31:19 CSTone
Öö 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
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 haveMicrosoft
pretty good project & debugging support, once you squelch the
self-serviing warnings about using standard library functions.
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 --would
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
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.
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.
On Wednesday, 2 March 2016 13:40:18 UTC+1, wij wrote:compatible
This remind me of the vanishing IC (hard-ware) dream.
The stance of C++ is understandable (though any other language
doubledwith C can be equally powerful).
Something wondered me that C++ added rref type, which effectively
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.
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.
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 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 ornot.
As general variable, wondering how many cases is rref useful? how manyaround)
can causing negative effects? (I don't use rref, no big deal to work
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)...
Öö Tiib <ootiib@hot.ee> spake the secret code <778f8707-56b5-4ad2-9569-7a658ad2e78a@googlegroups.com> thusly:doubled
On Wednesday, 2 March 2016 14:40:18 UTC+2, wij wrote:
Something wondered me that C++ added rref type, which effectively
languagethe type complexity with few useful instances. don't know the
preciselydevelopers are aware of it or not.
You are correct that C++ has made it burden of programmer to
indirectionindicate the storage and life-time of values and nuances of
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.
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:
objectsone can have standard containers which contain resource handling
(so can't be sensibly copied, but can be moved).
makeThis is a major reason rref tried to solve.
It not only "tried" but solved that. Copying lot of things does not
sense but moving some of those (like a thread or a file descriptor)movable
makes sense. So now if we make classes that contain such things
then we can use those in 'std::vector' or 'std::deque'.
convincedIt does add complexity to the type system (although I'm not
mentionby x2),
Let's say. If adding a lllong int, many should be considered, type
casting ,promotion, literals, i/o... that just one type (just
class,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
right wayabout half of the members have the burden how to treat rref the
memberswhether 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
dynamically and "manually" are rare.or
Template class has more cases to think about, no matter you like it
not.similar
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
to other classes.many
As general variable, wondering how many cases is rref useful? how
addedcan causing negative effects? (I don't use rref, no big deal to workaround)
If you don't use move then all works like in C++03. No complexity
whatsoever. Then is hard to understand what you complain about.considered
There are many cases where rref are not so good and had to be
particularly,and that triggered a language 'taboo': A language feature,
thethe core part, should consider not only the desirable part, but all
entercases generated. A good language feature should in principle not
missingthis '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
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 301 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 214:51:20 |
| Calls: | 6,744 |
| Calls today: | 4 |
| Files: | 12,272 |
| Messages: | 5,369,009 |