C ++ is DEAD
Andrej Hristoliubov
cease to exist in a month on Jan 23, 2006. There won't be any
standardization. There will be funeral. Newsgroup should be closed.
Thank you for you cooperation.
Andjey
----
Дамы и господа с неохотой, хочу вас
катастрофически огорчить: 23 Января 2006
года, С++ покинет этот мир, как
доминирующий язык программирования.
Это было истинное и духовное открытие
олицетворяющее в моей душе. Эта моя
миссия вас подготовить к это ужасной
трагедии и оповестить о ее
невозвратимой реализации. Будьте
бдительны, и пожалуйста - без
хулиганства.
Спасибо друзья,
Я всегда буду в ваших душах!
Андрюша
----------------------
Damy i gospoda s neohotoj, hochu vas katastroficheski ogorchit': 23
Janvarja 2006 goda, S++ pokinet jetot mir, kak dominirujushhij jazyk
programmirovanija. Jeto bylo istinnoe i duhovnoe otkrytie
olicetvorjajushhee v moej dushe. Jeta moja missija vas podgotovit' k
jeto uzhasnoj tragedii i opovestit' o ee nevozvratimoj realizacii.
Bud'te bditel'ny, i pozhalujsta - bez huliganstva.
Spasibo druz'ja,
Ja vsegda budu v vashih dushah!
Andrjusha
Jacek Dziedzic
> I had a revelations yesterday (a holy spirit came to me). C++ will
> cease to exist in a month on Jan 23, 2006. There won't be any
> standardization. There will be funeral. Newsgroup should be closed.
We expect better trolling around here.
- J.
Mateusz Łoskot
> I had a revelations yesterday (a holy spirit came to me). C++ will
> cease to exist in a month on Jan 23, 2006. There won't be any
> standardization. There will be funeral. Newsgroup should be closed.
>
> Thank you for you cooperation.
>
What's that?
Cheers
--
Mateusz Łoskot
http://mateusz.loskot.net
Victor Bazarov
> Andrej Hristoliubov wrote:
>
>> I had a revelations yesterday (a holy spirit came to me). C++ will
>> cease to exist in a month on Jan 23, 2006. There won't be any
>> standardization. There will be funeral. Newsgroup should be closed.
>>
>> Thank you for you cooperation.
>>
>
> What's that?
It's called "a Usenet troll", look it up.
Mateusz Łoskot
Yes, I'm pretty familiar with trolls but I hoped author of this post
could be so kind and explain pros and cons he had in mind more deeply.
robert...@gmail.com
Mateusz Loskot wrote:
> Victor Bazarov wrote:
> > Mateusz Loskot wrote:
> >
> >> Andrej Hristoliubov wrote:
> >>
> >>> I had a revelations yesterday (a holy spirit came to me). C++ will
> >>> cease to exist in a month on Jan 23, 2006. There won't be any
> >>> standardization. There will be funeral. Newsgroup should be closed.
> >>>
> >>> Thank you for you cooperation.
> >>>
> >>
> >> What's that?
> >
> >
> > It's called "a Usenet troll", look it up.
>
> Yes, I'm pretty familiar with trolls but I hoped author of this post
> could be so kind and explain pros and cons he had in mind more deeply.
Well then you are not, as you say, familiar with trolls.
Mateusz Łoskot
Ech, I'm just teasing with this guy.
Victor Bazarov
That's called "feeding the troll", and is actually a waste of bandwidth.
So, please don't. Thank you.
Mateusz Łoskot
> Mateusz Łoskot wrote:
>>
>
>
> That's called "feeding the troll", and is actually a waste of bandwidth.
> So, please don't. Thank you.
Understood.
Boris
news:1135313610.2...@o13g2000cwo.googlegroups.com...
>I had a revelations yesterday (a holy spirit came to me). C++ will
> cease to exist in a month on Jan 23, 2006. There won't be any
> standardization. There will be funeral. Newsgroup should be closed.
>
> Thank you for you cooperation.
>
> Andjey
> ----
However C++ usage shinks. Server-side development is mostly Java and .NET.
Client-side (Windows) is C++ so far, but will be replaced by other
technologies (in Windows Vista): .NET, XML graphics description language.
Btw, even though .NET supports C++, C# and VB.NET are much more popular
languages.
Kernel-level development is traditionally done in C.
What's left: cross-platform applications (Mozilla, etc.).
Btw, is Apache app-server written in C or C++?
-Boris
Sebastian Wiesner
nice things
> "Andrej Hristoliubov" <cpluspl...@gmail.com> wrote in message
> news:1135313610.2...@o13g2000cwo.googlegroups.com...
>>I had a revelations yesterday (a holy spirit came to me). C++ will
>> cease to exist in a month on Jan 23, 2006. There won't be any
>> standardization. There will be funeral. Newsgroup should be closed.
>>
>> Thank you for you cooperation.
>>
>> Andjey
>> ----
> This is an obvious troll.
> However C++ usage shinks. Server-side development is mostly Java and
> .NET. Client-side (Windows) is C++ so far, but will be replaced by other
> technologies (in Windows Vista): .NET, XML graphics description
> language. Btw, even though .NET supports C++, C# and VB.NET are much
> more popular languages.
ack.
> Kernel-level development is traditionally done in C.
> What's left: cross-platform applications (Mozilla, etc.).
Are you sure, that Mozilla is written in C++?
AFAIR they are using C, because it was more portable than C++, when the
project was started years ago.
And you forgot, that on Unix-like C++ is still widely used.
> Btw, is Apache app-server written in C or C++?
AFAIK its C
Bay
Basti
puzzlecracker
> However C++ usage shinks. Server-side development is mostly Java and .NET.
> Client-side (Windows) is C++ so far, but will be replaced by other
> technologies (in Windows Vista): .NET, XML graphics description language.
> Btw, even though .NET supports C++, C# and VB.NET are much more popular
> languages.
> Kernel-level development is traditionally done in C.
> What's left: cross-platform applications (Mozilla, etc.).
> Btw, is Apache app-server written in C or C++?
>
> -Boris
Well that proves the troll's assertion that C++ is in face dying.... Is
it really so?
Most trading and financial systems are still developed with C++ as well
as other major, distributive, real-time applications. However, C++
execution powers will soon oblivate, for computer power is increasing
lavishly .... .
Where do you people think C++ will be useful in, let's say, 5 -10 years
from now?
And please, no answers such as: legacy code, academic institutions, the
most obfuscates code contest, etc.
Thanks
Victor Bazarov
>> However C++ usage shinks. [..]
>>
>> -Boris
>
> [..]
> Where do you people think C++ will be useful in, let's say, 5 -10
> years from now?
What is the use of this discussion? Are you trying to find a reason
to bail out? You needn't waste your time and effort. Please bail
out now while there is still time to salvage your career. If you are
trying to find out whether you are still going to be employed some
time later, don't concern yourself with a single language's longevity.
Learn to program. Don't learn to program in <insert a language here>.
Here is an analogy: If your car is running fine (gets you where you're
going, has good mileage, cheap to maintain, relatively safe), there is
no logical reason to trade it in for another one. None. Whatsoever.
Drive it to the ground before you even consider what make or model to
get next. But if you are already looking around thinking what car to
get, just go get it, stop asking everybody you know whether you should
do it. If you need to ask, you need to change it. It's as simple as
that.
V
puzzlecracker
Very true, I agree with the argument as well as useful analogy.
However, people in general, hate change:
One works for the company developing real-time system in C++ for the10
years. During the time, the programmer has mastered all relevant
models, patterns, methodologies, etc. You got used to and you feel
comfortable.
After 10 years, the same company decided to start developing similar
systems in Java. Therefore, you need to change the current programming
paradigm , for the same standard models are implemented differently,
designed, likewise, differently, thus breaking your entrenched level of
feeling comfortable with the tools you have used for the past 10 years.
A priori, when a programmer enters a field with having objective
dispositions towards existing technology, he is likely to choose one
that has more future promise to avoid above inconveniences....In 2005;
does C++ hold the same promise as in 1985?
Programming is important, but tools should also be considered and
chosen wisely.....
Best,
Mateusz Łoskot
>
> Programming is important, but tools should also be considered and
> chosen wisely.....
>
Just learn programming, learn programming languages and still develop
your skills. Obviously, experience will help much when you (have to/want
to) learn yet another language.
Physicians also have to*** learn about new diseases along with new
strategies of fighting with them and new medicines, the tools.
*** - why? it should be obvious!
Victor Bazarov
> Victor Bazarov wrote:
>> puzzlecracker wrote:
>>>> However C++ usage shinks. [..]
>>>>
>>>> -Boris
>>>
>>> [..]
>>> Where do you people think C++ will be useful in, let's say, 5 -10
>>> years from now?
>>> [..]
>>
>>
>> V
>
>
> Very true, I agree [..]
> However, people in general, hate change:
>
You give an example of what problems developer groups face from time
to time. You haven't given any proof that guessing usefulness of C++
in 5-10 years is of any value. I still think it's pointless. Even
if C++ is destined to be an extinct language in a decade, there is no
sense in worrying about it now.
puzzlecracker
I haven't made any asserting statements concerning 'guessing' the
usefulness or futility of C++ in 5-10 years from now, but only stated
implications derived from the proceeding trolled and follow-up posts
(which can only be an exercise in futility).
The response my posted intended to elicit was the kind of applications
in which C++ currently dominates or/and will be the powerhouse in
anticipating future given that it doesn't and won't have a fair
competitors to supplement its usefulness in those areas. That is all.
ps.
I've just noticed that many of my posts are poorly written; I should
proofread my stuff once in a while.
Boris
> AFAIR they are using C, because it was more portable than C++, when the
> project was started years ago.
gives: ~1600 .c and ~4500 .cpp files.
It's just so much easier to write code in C++ (than in C).
I think the main reason C++ isn't used for kernel-level stuff: its run-time
subsystem and standard library (STL) would need to be ported for use in
kernel-level code. One could write device-drivers (for example) in C++, if
he didn't use exceptions and STL classes.
Boris
Boris
> from now?
>
> And please, no answers such as: legacy code, academic institutions, the
> most obfuscates code contest, etc.
It's not very easy to find memory and resources leaks (and reproduce
crashes!) in unmanaged code...so, apps that need to be up and running 24*7
should probably be written in managed code (if performance degradation isn't
an issue).
Major apps that were written in C traditionally will be moved to C++,
probably. Now that we have C++ Standard it's just a matter of time until
most C++ compilers adhere to it. Of course, some of those apps will be
ported to managed code too.
Web-based client apps: browser plug-ins, toolbars, etc. - will be mostly
written in scripting languages, probably. Even now, most FireFox toolbars
are written in jscript...same will happen with IE plug-ins over time.
Boris
puzzlecracker
Boris,
You still haven't specified where C++ will exist and still
predominataly exists - i.e. applcation domain.
we need the C++ Father in here - it is his concern too!!!
:)
Sebastian Wiesner
nice things
>> Are you sure, that Mozilla is written in C++?
>> AFAIR they are using C, because it was more portable than C++, when the
>> project was started years ago.
> Searching Mozilla sources(I had them downloaded to my system) by
> filetype gives: ~1600 .c and ~4500 .cpp files.
Interesting, I didn't know that.
> It's just so much easier to write code in C++ (than in C).
Definitely.
> I think the main reason C++ isn't used for kernel-level stuff: its
> run-time subsystem and standard library (STL) would need to be ported
> for use in kernel-level code.
That would be a rather difficult task. Especially the STL is not intended
for use in kernel-level code. And things like inheritance and virtual
functions are much too complex for being ported kernel-level code and
even if someone had ported them, they would have a negative impact on the
performance of the code.
> One could write device-drivers (for example) in C++, if he didn't use
> exceptions and STL classes.
I don't know, because I've written done device drivers or kernel-level
code. But I don't think, that C++ would be the right language for such
stuff, as it is too complex.
Basti
Jim Langston
Tiaan van Aardt
"Boris" <spa...@hello.com> wrote in message
news:43ae9dc8$0$96021$742e...@news.sonic.net...
> This is an obvious troll.
Indeed, but how nice to bite :-)
> However C++ usage shinks. Server-side development is mostly Java and
> .NET.
Begging to differ here. Server applications have many Java and .NET
followers, but think for a while about all the servers deployed
accross the Internet such as sendmail, named/DNS, apache, php,
open{ssh,ntp,etc), linux itself, the *BSDs, Solaris, Windows. All in
C/C++. I'd say that the use of C/C++ is expanding as F/OSS is becoming
more accepted.
> Client-side (Windows) is C++ so far, but will be replaced by other
> technologies (in Windows Vista): .NET, XML graphics description
> language.
Actually, most client-side applications for Windows are written in VB
(mostly due to MS' marketing hype during the 90's). They're starting
to migrate that to C# under .NET (which I like to call C-hash because
it's a re-hash of C++) but plenty still remains VB.
I agree with Victor. Worrying about it now is pointless. As another
poster implied, use the language if it's useful, use something else if
it's not. Migrating to another language because it's becoming popular
(read: fashionable) is just silly. Choose the best tool for the job,
not whatever's currently being broadcast by MS or Sun or me.
Java relies heavily on Sun and .NET is especially dependent on MS.
Both languages/platforms are at the mercy of these corporations. If
I'd have to choose between the two, I'd side with Java because I
believe that Sun will someday open Java to the masses - something MS
will never ever do. And the C# standard remains proprietary (don't
even start with me on MONO). C++ is a universal standard maintained by
a universal standards body (ISO) and can be (and has been) implemented
by many different people and companies.
Also keep in mind that C++ is continually evolving. Projects such as
Boost.org and C++0x are proceeding well.
If you're worried about your carreer opportunities, it should go
without saying that you shouldn't learn only one language. It's been
said (over and over in this forum) that one should learn to program
and then apply that knowledge to a programming language that suits the
task at hand.
Regards,
-Tiaan.
--
_____________________________________________________
TruTeq Wireless (Pty) Ltd. Tel +27 12 667 1530
http://www.truteq.com Fax +27 12 667 1531
Wireless communications for remote machine management
W Marsh
> will never ever do. And the C# standard remains proprietary (don't
> even start with me on MONO). C++ is a universal standard maintained by
> a universal standards body (ISO) and can be (and has been) implemented
> by many different people and companies.
You don't have a clue what you're talking about. C# is a universal
standard maintained by ECMA (Sun were going to do the same, but later
withdrew their application). C# has two open source implementations.
"And the C# standard remains proprietary (don't even start with me on MONO)"
There is no such thing as the colour yellow. Don't even start with me on
bananas.
Besides, MONO is an implementation of the .NET platform, which has as
much to do with C++ as it does C#.
I feel that you are a big fan of open source software - please, do the
movement a favour by not being a bad advocate.
Tiaan van Aardt
> You don't have a clue what you're talking about. C# is a universal
> standard maintained by ECMA (Sun were going to do the same, but
> later withdrew their application). C# has two open source
> implementations
And so we learn and I stand corrected.
Here's a description of the process followed by MS to get C#
standardised:
http://msdn.microsoft.com/netframework/ecma
> There is no such thing as the colour yellow. Don't even start with
> me on bananas.
Bananas are good for you ;-)
> I feel that you are a big fan of open source software - please, do
> the movement a favour by not being a bad advocate.
You feel incorrectly. I'm more a big fan of what works well, but
that's so far OT now I'll just show myself out.
Tiaan.
Ivan Vecerina
news:1135552393.2...@g49g2000cwa.googlegroups.com...
: Well that proves the troll's assertion that C++ is in face dying....
: Is it really so?
All the technolgies of today are dying and will be replaced
at some point. There is no question about this.
: Where do you people think C++ will be useful in, let's say,
: 5 -10 years from now?
For application development, maybe the time is coming soon to move
away from C and C++ ... it has been coming for years.
But I woudn't necessarily bet on .NET or Java either. Their life
span and space might be short and limited between today's world
of C++ apps and the script-based future of web applications.
But unless you envision a world ruled by .NET or Java-oriented
microprocessors (which would be quite naive), you are bound to
see C (and by extension C++) code all over the place.
Some may argue that C is good enough for 'core' development,
and that C++ might go away in spite of C remaining as the
"portable assembly language". I do not think that this is
realistic, as C++ as a better C does provide real benefits.
C and C++ are two languages governed by distinct standards,
but in the big picture they pretty much share the same spot.
In my world of embedded development, intensive real-time
data processing, and vision/rendering systems, I do not
see C or C++ going away anytime soon. Same for telecom
systems, operating systems, compilers/interpreters, etc...
Of course most coders will stop individually coding low-level
algorithms in C++, just like writing a Bresenham line drawing
algorithm or a memory allocator would really be an exception today.
But C and C++ will remain the tool underlying the development
of most higher-level platforms and languages. This might
be a small portion of the future world of software development,
but a critical one.
Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Bob Hairgrove
<tazm...@rocketmail.com> wrote:
>Thank you.
Who are the trolls here?
--
Bob Hairgrove
NoSpam...@Home.com
W Marsh
I'm sorry, I'm a bit grouchy. Kudos to you for taking my awful barking
with grace.
Martin Vejnar
I can understand why people prefer C# to C++ for .NET development. I've
tried to write a win-form application in C++ and it indeed stank.
But I've also read about C++/CLI recently and I believe that this
language has all the benefits of C# and even more. You can still rely on
existing paradigmas - mainly stack-based objects with automatic
construction/destruction, templates and a strong type system - while
exploiting the garbage collector. (Really, what does .NET have except gc?)
Martin.
robert...@gmail.com
It is my understanding that Win32 is being "depricated" by MS and will
be replaced by something called WinFX. WinFX is a .NET framework. It
is rather annoying to think that I may be forced to do .NET development
soon as my current employer writes windows apps. It does make me
wonder what the future holds for REAL C++ (Managed C++ is NOT C++ -
it's an abomination).
Martin Vejnar
> (Managed C++ is NOT C++ - it's an abomination).
Yes, but C++/CLI is not Managed C++.
robert...@gmail.com
Yes, it is. It is a complete redesign but it is still Managed C++.
Martin Vejnar
Ok, so you consider C++/CLI an abomination too? Why? AFAIK a C++ program
is valid C++/CLI. The latter only adds support for managed code which is
something we need if we (or our employers) want (us) to develop for .NET.
Kaz Kylheku
> Andrej Hristoliubov wrote:
> > I had a revelations yesterday (a holy spirit came to me). C++ will
> > cease to exist in a month on Jan 23, 2006. There won't be any
> > standardization. There will be funeral. Newsgroup should be closed.
>
That's not a troll, just a bit of humor.
You'd have to be pretty insecure about your pet language to find
trolling traction in Andrej's goofy posting.
:)
Jim Langston
"Bob Hairgrove" <inv...@bigfoot.com> wrote in message
news:esovq1h791phovlk4...@4ax.com...
> On Mon, 26 Dec 2005 01:45:54 -0800, "Jim Langston"
> <tazm...@rocketmail.com> wrote:
>
>>Thank you.
>
> Who are the trolls here?
Andrej Hristoliubov
Çaglar
language.
puzzlecracker
Çaglar wrote:
> As I know C++ is still the fastest and the most stable object oriented
> language.
>stable object oriented language.
Oh really? be kind to provide some justification for this claim. Java
and C# are much more stable in OO regard, but, by all means, I am
not implying that they are better languages as a whole.
Andrej Hristoliubov
> Java and C# are much more stable in OO regard
PLus other comments made, make c++ unrecoverable and on a brink of its
short-lived existence. People please help me gather the support for it.
I want to collect enough people to start the marsh and strike in
Washington. President should hear our pleas and reimburse financially
and physiologically the hurt ones; the c++ lost is a major tragedy.
Some say it is even worse than Sep.11. We also need to help
Stroustrup's family (for the father and god of the language will need
it to sponsor his recovery in mental institute, recovering from
post-died-language-and-programming-future syndrome: for those that do
not know - it is most extreme case of mental illness).
Thanks folks, send me an email if you plan to attend,
Additionally, you can also send me funds and donation and I will make
sure its to ones most in need.
With love and devotion, C++ true believer,
Andrej Hristoliubov
------
let me know if russian translation is need it.
---
Victor Bazarov, thanks for promulgating funeral flyers in our area and
sending to our professors at MIT this mortal news. Other take this as
example and contact victor for the copy of the flyer.
Bye
Mirek Fidler
> probably. Now that we have C++ Standard it's just a matter of time until
> most C++ compilers adhere to it. Of course, some of those apps will be
> ported to managed code too.
You make me laugh. What time-span do you except? It is almost 8 years
after the standadard and compilers are still non-conforming!
Maybe next 50 years to get some reasonable C++ compilers? :)
Mirek
bjarne
http://public.research.att.com/~bs/applications.html -- the part that
can be answered without pure speculation.
-- Bjarne Stroustrup; http://www.research.att.com/~bs
James Juno
Very impressive. Guess the trolling OP will need to start over with some
other premise.
-JJ
Mirek Fidler
Actually, I see two problems here (both with the list and C++):
- most of those applications are not using "modern" C++ (STL etc...)
Perhaps that indicates something.
- what makes me worry is the fact that the majority of current C++
development tools is actually not written in C++ (but in Java, C#, C or
even Pascal). Was not C++ designed as a language suitable for such tools?
Mirek
P.S.: Personally, I consider C++ to be the very effective tool, perhaps
the most effective language ever, so it in fact makes me sad to see its
_relative_ stagnation... (IMHO, STL is to blame there).
James Juno
> bjarne wrote:
>> Here's an answer to part of your question:
>> http://public.research.att.com/~bs/applications.html -- the part that
>> can be answered without pure speculation.
>>
>> -- Bjarne Stroustrup; http://www.research.att.com/~bs
>>
>
> Actually, I see two problems here (both with the list and C++):
>
> - most of those applications are not using "modern" C++ (STL etc...)
> Perhaps that indicates something.
>
> - what makes me worry is the fact that the majority of current C++
> development tools is actually not written in C++ (but in Java, C#, C or
> even Pascal). Was not C++ designed as a language suitable for such tools?
I think you are confusing apples with oranges. While IDEs and
mouse-driven RAD tools and such might be written in interpreted
script-ish languages like c#, compilers are not. How do you propose to
write the first c# "compiler" in something like c#? This seems to be a
common disconnect in understanding of a lot of newer generation programmers.
-JJ
puzzlecracker
Given that most features in C++ are already imlemented in different
languages, what trademarks other than efficiency still makes a
powerhouse.?
Luke Meyers
> Given that most features in C++ are already imlemented in different
> languages, what trademarks other than efficiency still makes a
> powerhouse.?
As we all well know, a programming language is much more than a set of
features, and it's not a game of "he who implements the most features
wins." A well-selected feature set which provides a powerful tool
without excessive obfuscation is preferable to endless glue-ons. C++
is an impressively rich and robust language, and we are still
discovering important new paradigms that it enables. Boost is young.
Template metaprogramming is young ("the book" is copyright 2005). Yes,
these paradigms can also be adopted in other languages. Yes, C++ has
its weaknesses and other languages have their strengths. But neither
"newer" nor "bigger" is equivalent to "better."
My local C++ zealot, though long on enthusiasm and a bit short on
shut-the-hell-up-already, happens to be right more often than he is
wrong. One of the points he is fond of making is that while it's
easier to rapidly develop an application that meets the "pretty good"
or "80-90% of the way there" standard in a language such as Java, in
the long haul it's easier to get the last mile to a truly robust, solid
solution with C++. That is, with properly used, modern C++, not with
industry-average C++.
For many purposes, you don't need "five nines" reliability, bulletproof
libraries, or more than rudimentary efficiency. For those tasks, in
many cases, C++ is bound to be eclipsed by a more domain-appropriate
tool. However, as the number and quality of higher-level languages
which trade away C++-ness for ease of use and rapid prototyping
increases, it seems likely that the developers making heavy use of such
tools will diverge (to an extent) as a community from those involved in
systems that are real-time, mission-critical, safety-critical,
efficiency-critical, and so on.
Getting back to the matter of features for a moment, I note that you've
on at least one occasion made rather sloppy comparisons of features
between languages -- case in point, you referred to Java generics as
templates, and stated or implied that they were equivalent to C++
templates, which is beyond a distortion of fact. I don't say this for
ad hominem purposes (I hope that's clear from my tone -- I just don't
want to risk anyone thinking so), but rather to emphasize the point
that a feature is more than a bullet point. It exists in the context
of an entire language, and the degree to which it successfully and
elegantly interoperates with and enhances the rest of the language is
the crux, not to mention whether it's actually comparable to features
in other languages which it happens to resemble.
Luke
Luke Meyers
made on all sides, has so readily drowned out the irritating squealing
of lesser Usenet organisms. Kudos to all (well, most).
Luke
bjarne
> > Here's an answer to part of your question:
> > http://public.research.att.com/~bs/applications.html -- the part that
> > can be answered without pure speculation.
>
> > -- Bjarne Stroustrup; http://www.research.att.com/~bs
>
>
> Actually, I see two problems here (both with the list and C++):
>
> - most of those applications are not using "modern" C++ (STL etc...)
That's a bold statement. Nobody knows all of those applications and the
applications on that list are just some I happen to have heard about
and am able to refer to in public. I know that there is much poor C++
code out there --- as there is much poor code in every language in
real-world use. However, I *know* that many of those applications use
various forms of "modern" C++ relying on object-oriented and generic
techniques to produce code that in the eyes of its creators and
maintainers far surpasses older styles. Much of this code is produced
by professionals --- livelyhoods (and lives) depend on the correctness,
performance, and maintainability of the code. I wouldn't disparage
that.
> Perhaps that indicates something.
> - what makes me worry is the fact that the majority of current C++
> development tools is actually not written in C++ (but in Java, C#, C or
> even Pascal). Was not C++ designed as a language suitable for such tools?
C++ was and is suitable for such tools. It is also used for widely used
for development tools (e.g. compilers and SDEs). However the history
of many such tools go way back (e.g. note the history of C tools in the
Unix world). Other tools are written in proprietary languages to limit
competition. You might also consider that there happen to be several
software development tools on that list (eventhough I was trying to
focus on applications rather that libraries and tools).
> Mirek
>
> P.S.: Personally, I consider C++ to be the very effective tool, perhaps
> the most effective language ever, so it in fact makes me sad to see its
> _relative_ stagnation...
What evidence do you have for "relative stagnation"?
Once you have 3 million programmers (as C++ does), growing the user
population by double digit percentages gets hard. I don't consider the
current steady 5% to 10% growth (my best estimate based on multiple
sources incl. IDC) stagnation, even "relative stagnation".
> (IMHO, STL is to blame there).
Interesting claim. On what could you base it?
Mirek Fidler
>>development tools is actually not written in C++ (but in Java, C#, C or
>>even Pascal). Was not C++ designed as a language suitable for such tools?
>
>
> C++ was and is suitable for such tools. It is also used for widely used
> for development tools (e.g. compilers and SDEs). However the history
> of many such tools go way back (e.g. note the history of C tools in the
> Unix world). Other tools are written in proprietary languages to limit
> competition.
That is certainly not the case of Eclipse and many other tools :)
> You might also consider that there happen to be several
> software development tools on that list (eventhough I was trying to
> focus on applications rather that libraries and tools).
Some of them are moving from C++ implementation now (MS Visual Studio) :(
>>P.S.: Personally, I consider C++ to be the very effective tool, perhaps
>>the most effective language ever, so it in fact makes me sad to see its
>>_relative_ stagnation...
>
>
> What evidence do you have for "relative stagnation"?
Well, maybe my view is stupid, but for me "relative stagnation" is
expressed but C++ not being recommended for new projects anymore, with
less C++ programmers coming from schools etc... C++ has now the stigma
of "ineffective monster", much like PL/1 had decades ago.
(Please once again, that is not my opinion, personally I think that C++
is the most effective language in history, even more effective than you
ever thought :)
In other words, it could be stupid view, but go to any non-C++
news-group of forum and ask for a language to develop something. You
could tell that new-group opinion does not represent decision maker
opinion, but I think that in long term there is convergency.
>>(IMHO, STL is to blame there).
>
>
> Interesting claim. On what could you base it?
Well, in order to have your development efforts effective, you need a
tool to express and maintain data model of your application in as simple
form as possible.
Now STL has that "assignable/copyable" requirement. That makes STL
containers good for effective storage of fundamental data types, but
hardly anything else. You cannot e.g. directly put GUI widgets
representing a number to STL container and sort them. Yes, you can put
them there using (smart) pointer, but that makes your code COMPLICATED.
For any nontrivial application, these complications multiply. Add to
this schema the iterator concept (with its nice features like vector
iterators getting invalidated) and you are getting that kind of monster
language...
It is perhaps accidental, but I believe that the timeframe of STL
introduction matches the rise of Java. Of course, it is just
speculation, but it is not that impossible that many programmers, given
the choice between complicated and not-exactly-problem-solving STL and
simple GC-based model gave up on C++ and gone for better option of the
time. Purely based on the fact that datamodels of Java apps are easier
to express and maintain.
Now note that I am NOT advocating GC! I believe that the best option
there would be to adopt some form of owning containers without that
devastating copy-always monstrosity. But with STL momentum in C++
standard circles, it is of course too late now...
(well, what I have in mind is this:
http://upp.sourceforge.net/www$uppweb$overview$en-us.html
I know that chances of success are dim there, but at least I try :)
Mirek
P.J. Plauger
news:41ketcF...@individual.net...
>> What evidence do you have for "relative stagnation"?
>
> Well, maybe my view is stupid, but for me "relative stagnation" is
> expressed but C++ not being recommended for new projects anymore, with
> less C++ programmers coming from schools etc... C++ has now the stigma of
> "ineffective monster", much like PL/1 had decades ago.
I remember reading an article in Datamation (I think it was) a few
years ago where one putative expert remarked offhandedly that all
major companies were doing new projects in Smalltalk(!) I'm
continually impressed with the ability of even the most intelligent
of people to see what they want to see. Of course that includes all
of us, too; but some of us have the advantage of scientific training
and can force ourselves to perform an occasional reality check.
Overall, however, we are a society drunk on opinions and starved for
facts.
> (Please once again, that is not my opinion, personally I think that C++ is
> the most effective language in history, even more effective than you ever
> thought :)
Noted.
> In other words, it could be stupid view, but go to any non-C++ news-group
> of forum and ask for a language to develop something. You could tell that
> new-group opinion does not represent decision maker opinion, but I think
> that in long term there is convergency.
No, I think there's a widespread belief that some toy has to be
better than hard-working languages like C and C++. Try to pin
down a single new language, or even coherent family of languages,
and you'll find plenty of divergence.
>>>(IMHO, STL is to blame there).
>>
>>
>> Interesting claim. On what could you base it?
>
> Well, in order to have your development efforts effective, you need a tool
> to express and maintain data model of your application in as simple form
> as possible.
>
> Now STL has that "assignable/copyable" requirement. That makes STL
> containers good for effective storage of fundamental data types, but
> hardly anything else.
Another interesting worldview. Until I began learning traditional
OO languages, I found very few occasions where I needed the
handle/clone model. Most of the time it's easy enough to define
assignment; when it's not it's easy enough to use pointers and
a simple discipline for keeping track of storage. I find that it's
refugees from such languages who work backwards from what they're
used to who discover that it's harder to make C++ look like
Smalltalk than to make Smalltalk look like Smalltalk.
You cannot e.g. directly put GUI widgets
> representing a number to STL container and sort them.
You can with a list. Most implementations never really required
list assignability and now that requirement is officially removed
for lists, maps, and sets, IIRC. It helps to know your tools before
you criticize them.
> Yes, you can put them
> there using (smart) pointer, but that makes your code COMPLICATED.
See above.
> For any nontrivial application,
For any nontrivial Smalltalk application...
> these complications multiply. Add to this
> schema the iterator concept (with its nice features like vector iterators
> getting invalidated) and you are getting that kind of monster language...
Yep. Once again, a simple discipline (ideally augmented with checking
iterators to catch your early errors) makes this a minor problem.
Now, if I were to list the stupid mistakes I made when first writing
Java code, I could easily represent *that* language as monstrous.
> It is perhaps accidental, but I believe that the timeframe of STL
> introduction matches the rise of Java. Of course, it is just speculation,
> but it is not that impossible that many programmers, given the choice
> between complicated and not-exactly-problem-solving STL and simple
> GC-based model gave up on C++ and gone for better option of the time.
> Purely based on the fact that datamodels of Java apps are easier to
> express and maintain.
A wonderful post hoc argument, but weakly aligned with reality. Java
did it's booming in the mid 1990s, *before* the world got to see much
of STL. By the time STL was at all widespread, people were no longer
talking about using Java to destroy C/C++/Unix/Windows/Microsoft;
it had already begun to settle into the niche that it occupies today.
> Now note that I am NOT advocating GC! I believe that the best option there
> would be to adopt some form of owning containers without that devastating
> copy-always monstrosity. But with STL momentum in C++ standard circles, it
> is of course too late now...
We have the interesting experiment just launched by Microsoft called
C++/CLI. It has already proved to my satisfaction that it can merge
C++, STL, and GC into one coherent package. In a few years we'll know
whether enough real-world programmers find it useful.
> (well, what I have in mind is this:
>
> http://upp.sourceforge.net/www$uppweb$overview$en-us.html
>
> I know that chances of success are dim there, but at least I try :)
And I applaud all such efforts. We have to try things to see if
they're worthwhile.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Mirek Fidler
> assignment;
Well, I am far from being that optimistic for anything than most trivial
types, mostly fundumentals and some PODs.
>>representing a number to STL container and sort them.
>
>
> You can with a list. Most implementations never really required
How are you going to put that GUI widget into the list? Last time I have
checked, push_back had single "const T&" parameter...
> list assignability and now that requirement is officially removed
> for lists, maps, and sets, IIRC. It helps to know your tools before
> you criticize them.
Could be. How would you advice me to put my GUI widget (which naturally
lacks any form of copy operation) to the list?
>>It is perhaps accidental, but I believe that the timeframe of STL
>>introduction matches the rise of Java. Of course, it is just speculation,
>>but it is not that impossible that many programmers, given the choice
>>between complicated and not-exactly-problem-solving STL and simple
>>GC-based model gave up on C++ and gone for better option of the time.
>>Purely based on the fact that datamodels of Java apps are easier to
>>express and maintain.
>
>
> A wonderful post hoc argument, but weakly aligned with reality. Java
> did it's booming in the mid 1990s, *before* the world got to see much
> of STL. By the time STL was at all widespread, people were no longer
> talking about using Java to destroy C/C++/Unix/Windows/Microsoft;
> it had already begun to settle into the niche that it occupies today.
Possibly. It was just an opinion :)
But I remember first encountering STL somewhere around 1995, which is
"mid 1990s" - I even remember arguing with some Objective-C advocate
through all the night on some geek party comparing the STL with
Objective-C collections - I was a big fan of STL at the time.
I also remember talking with friends quitting C++ for Java later (around
1997-98).
Mirek
Chris Hills
writes
>> What evidence do you have for "relative stagnation"?
>
>Well, maybe my view is stupid, but for me "relative stagnation" is
>expressed but C++ not being recommended for new projects anymore,
This is clearly not true. Incidentally MISRA is has now started a MISRA
c++ because of the increased use of C++ in new projects..... This is in
a large number of fields not just automotive.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Roland Pibinger
>Well, in order to have your development efforts effective, you need a
>tool to express and maintain data model of your application in as simple
>form as possible.
>
>Now STL has that "assignable/copyable" requirement. That makes STL
>containers good for effective storage of fundamental data types, but
>hardly anything else. You cannot e.g. directly put GUI widgets
>representing a number to STL container and sort them. Yes, you can put
>them there using (smart) pointer, but that makes your code COMPLICATED.
>For any nontrivial application, these complications multiply. Add to
>this schema the iterator concept (with its nice features like vector
>iterators getting invalidated) and you are getting that kind of monster
>language...
Interestingly, apparently nobody ever really questioned or even
discussed the "dogma of value semantics". The probably best-selling
STL book (by a well known author) doesn't even mention 'value
semantics'.
In fact, generic programming and OO programing are independent of each
other. Generic algorithms and containers can be written to work with
polymorphic types the same way as they do with value types in STL
(actually many library implementers have written containers for
polymorphic objects in the past).
>It is perhaps accidental, but I believe that the timeframe of STL
>introduction matches the rise of Java. Of course, it is just
>speculation, but it is not that impossible that many programmers, given
>the choice between complicated and not-exactly-problem-solving STL and
>simple GC-based model gave up on C++ and gone for better option of the
>time. Purely based on the fact that datamodels of Java apps are easier
>to express and maintain.
In the meantime Java also turned into a dinosaur-language. These days
the interesting trends happen in scripting languages like Python,
Ruby, ... , i.e. in languages that emphasize simplicity, usability,
and elegance.
>Now note that I am NOT advocating GC! I believe that the best option
>there would be to adopt some form of owning containers without that
>devastating copy-always monstrosity.
Applause!
>But with STL momentum in C++
>standard circles, it is of course too late now...
Well, after 10 years, the generic programming hype is certainly over.
I think, nobody can be enthused any more by yet another additional
policy template parameter or yet another for_each (bind... (adapt...
(bind...(.., _1))) cascade.
>(well, what I have in mind is this:
>
>http://upp.sourceforge.net/www$uppweb$overview$en-us.html
>
>I know that chances of success are dim there, but at least I try :)
Time to look at it again, esp. since you seem to have improved the
documentation.
Best wishes,
Roland Pibinger
Mirek Fidler
>>language...
>
>
> Interestingly, apparently nobody ever really questioned or even
> discussed the "dogma of value semantics".
So we do now :)
> other. Generic algorithms and containers can be written to work with
> polymorphic types the same way as they do with value types in STL
> (actually many library implementers have written containers for
> polymorphic objects in the past).
Indeed :) At least to some degree, there are limits, but actually there
are limits in STL as well (that is why std::list has 'sort' as method :)
>>(well, what I have in mind is this:
>>
>>http://upp.sourceforge.net/www$uppweb$overview$en-us.html
>>
>>I know that chances of success are dim there, but at least I try :)
>
>
> Time to look at it again, esp. since you seem to have improved the
> documentation.
I wish we had more time and resources to do better...
Mirek
Mirek Fidler
> the interesting trends happen in scripting languages like Python,
> Ruby, ... , i.e. in languages that emphasize simplicity, usability,
> and elegance.
BTW, I still believe that "simplicity, usability and elegance" are
domains of C++...
Mirek
Roland Pibinger
>> Most of the time it's easy enough to define
>> assignment;
>
>Well, I am far from being that optimistic for anything than most trivial
>types, mostly fundumentals and some PODs.
>
>>>representing a number to STL container and sort them.
>>
>>
>> You can with a list. Most implementations never really required
>
>How are you going to put that GUI widget into the list? Last time I have
>checked, push_back had single "const T&" parameter...
>
>> list assignability and now that requirement is officially removed
>> for lists, maps, and sets, IIRC. It helps to know your tools before
>> you criticize them.
>
>Could be. How would you advice me to put my GUI widget (which naturally
>lacks any form of copy operation) to the list?
Mr. Plauger implements (implemented) the "STL.NET" for Microsoft (
http://www.dinkumware.com/stlnet_signup.html ). If I interpret the
"STL.NET Primer" (
http://msdn.microsoft.com/visualc/?pull=/library/en-us/dnvs05/html/stl-netprimer.asp?frame=true
) correctly the implementation uses reference semantics instead of
value semantics.
Best regards,
Roland Pibinger
Mirek Fidler
>>>list assignability and now that requirement is officially removed
>>>for lists, maps, and sets, IIRC. It helps to know your tools before
>>>you criticize them.
>>
>>Could be. How would you advice me to put my GUI widget (which naturally
>>lacks any form of copy operation) to the list?
>
>
> Mr. Plauger implements (implemented) the "STL.NET" for Microsoft (
> http://www.dinkumware.com/stlnet_signup.html ). If I interpret the
> "STL.NET Primer" (
> http://msdn.microsoft.com/visualc/?pull=/library/en-us/dnvs05/html/stl-netprimer.asp?frame=true
> ) correctly the implementation uses reference semantics instead of
> value semantics.
Well, but garbage collected STL with C++/NET is not exactly standard
C++/STL, is it?
Mirek
Roland Pibinger
>
>Well, but garbage collected STL with C++/NET is not exactly standard
>C++/STL, is it?
Right, it's not Standard C++. The interesting point is that a member
of the C++ Standards commitee has no problem to abandon the value
semantics dogma. If that is appropriate for C++/CLI why not for 'real'
C++?
Best wishes,
Roland Pibinger
Mirek Fidler
Actually, C++/CLI looks much more like solving .NET - C++ integration
(legacy apps to maintain...) than breaking value semantics dogma...
Mirek
P.J. Plauger
>> Most of the time it's easy enough to define
>> assignment;
>
> Well, I am far from being that optimistic for anything than most trivial
> types, mostly fundumentals and some PODs.
You have my sympathy.
>>>representing a number to STL container and sort them.
>>
>>
>> You can with a list. Most implementations never really required
>
> How are you going to put that GUI widget into the list? Last time I have
> checked, push_back had single "const T&" parameter...
Just keep adding the constraints and you'll always win in the end.
>> list assignability and now that requirement is officially removed
>> for lists, maps, and sets, IIRC. It helps to know your tools before
>> you criticize them.
>
> Could be. How would you advice me to put my GUI widget (which naturally
> lacks any form of copy operation) to the list?
I wouldn't. I'd advise you to pick the OO language of your choice and use
it. Now if I were to design a GUI for C++, it would not "naturally" lack
certain useful properties...
>>>It is perhaps accidental, but I believe that the timeframe of STL
>>>introduction matches the rise of Java. Of course, it is just speculation,
>>>but it is not that impossible that many programmers, given the choice
>>>between complicated and not-exactly-problem-solving STL and simple
>>>GC-based model gave up on C++ and gone for better option of the time.
>>>Purely based on the fact that datamodels of Java apps are easier to
>>>express and maintain.
>>
>>
>> A wonderful post hoc argument, but weakly aligned with reality. Java
>> did it's booming in the mid 1990s, *before* the world got to see much
>> of STL. By the time STL was at all widespread, people were no longer
>> talking about using Java to destroy C/C++/Unix/Windows/Microsoft;
>> it had already begun to settle into the niche that it occupies today.
>
> Possibly. It was just an opinion :)
>
> But I remember first encountering STL somewhere around 1995, which is "mid
> 1990s" - I even remember arguing with some Objective-C advocate through
> all the night on some geek party comparing the STL with Objective-C
> collections - I was a big fan of STL at the time.
>
> I also remember talking with friends quitting C++ for Java later (around
> 1997-98).
Post hoc, ergo propter hoc.
P.J. Plauger
It does solve that integration problem. It also breaks value semantics
dogma.
It also breaks OO semantics dogma, and probably a few others as well.
It's an interesting brew indeed.
James Juno
> "Mirek Fidler" <c...@volny.cz> wrote in message
> news:41kuecF...@individual.net...
>
>>> for lists, maps, and sets, IIRC. It helps to know your tools before
>>> you criticize them.
>> Could be. How would you advice me to put my GUI widget (which naturally
>> lacks any form of copy operation) to the list?
>
> I wouldn't. I'd advise you to pick the OO language of your choice and use
> it. Now if I were to design a GUI for C++, it would not "naturally" lack
> certain useful properties...
>
Exactly. If you don't want to provide the simple requisites like copy
constructors then it's time to move on. My business has been designing
C++ GUIs for years and this has never been a problem.
>> But I remember first encountering STL somewhere around 1995, which is "mid
>> 1990s" - I even remember arguing with some Objective-C advocate through
>> all the night on some geek party comparing the STL with Objective-C
>> collections - I was a big fan of STL at the time.
>>
>> I also remember talking with friends quitting C++ for Java later (around
>> 1997-98).
>
> Post hoc, ergo propter hoc.
>
Yes this is a classic case. Also, I think Joel Spolsky has done a great
job summarizing the problem a lot of us in the business are seeing these
days:
http://www.joelonsoftware.com/items/2005/12/29.html
We're finding it harder by the day to find the C++ talent we need.
-JJ
Howard Hinnant
time. But as today I'm working on a revision to N1855, the subject is
on my mind even more than usual... ;-)
In article <41kuecF...@individual.net>,
Mirek Fidler <c...@volny.cz> wrote:
> How would you advice me to put my GUI widget (which naturally
> lacks any form of copy operation) to the list?
I'm not an NTL expert by any means. But if I understand correctly, this
is how you might do it with NTL?
class widget
{
public:
...
widget(pick_ widget& w);
widget& operator=(pick_ widget& w);
...
private:
widget(const widget&);
widget& operator=(const widget&);
};
...
BiVector<widget> c;
widget w;
c.AddTailPick(w);
Is that about right?
The "STL" isn't sitting still either. Here is how it is currently
looking for C++0X.
class widget
{
public:
...
widget(widget&& w);
widget& operator=(widget&& w);
...
private:
widget(const widget&);
widget& operator=(const widget&);
};
...
std::list<widget> c;
c.push_back(widget());
That will work with vector, map, etc. too. I.e. Today's C++ programmers
won't have to learn a lot of new syntax (e.g. AddTailPick).
You'll even be able to return your movable but non-copyable widgets from
factory functions:
widget
make_widget( /* some parameters */)
{
widget result (/* ... */);
...
return result; // Ok, moves instead of copies
}
...
c.push_back(make_widget()); // Ok, all moves, no copies
The only thing you won't be able to do is implicitly move from a named
widget (like you can from auto_ptr):
std::list<widget> c;
widget w;
c.push_back(w); // compile-time error, can't copy widget
That's a feature not a bug. You don't want to accidently move from a
named object which you can later reference (and perhaps not realize it
has been moved from). If you really want to move from a named widget
(an lvalue widget), you can:
std::list<widget> c;
widget w;
c.push_back(std::move(w)); // ok
And it isn't just containers getting a face lift. Most of your familiar
STL algorithms are getting a face lift so as to work with sequences of
widgets:
some_iterator i = std::remove_if(c.begin(), c.end(), some_predicate());
NTL works today. A move enabled STL is only available on CodeWarrior 10
for the Mac.
If you're impatient for a move-enabled STL, let your standards
representative, compiler and library vendor know.
If you want to learn more about a move-enabled STL see this paper:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1771.html
There are lots of similarities between NTL and the currently proposed
C++0X STL. But the biggest difference is that the newer STL has a lot
of backwards compatibility with today's STL. It will look and feel very
much like today's. It will just do a lot more moving than copying (and
have the associated performance increases).
-Howard
Mirek Fidler
Well, I think as our "cooperation" in both mailing lists seems to
continue, I will try to learn you via posts as much as possible :)
> But if I understand correctly, this
> is how you might do it with NTL?
>
> class widget
> {
> public:
> ...
> widget(pick_ widget& w);
> widget& operator=(pick_ widget& w);
> ...
> private:
> widget(const widget&);
> widget& operator=(const widget&);
> };
>
> ...
>
> BiVector<widget> c;
> widget w;
> c.AddTailPick(w);
>
> Is that about right?
No. This would require pick (aka implicit move) constructor in widget.
Far too restricting.
Instead, the solution is to completely avoid the transfer of widget to
container. Means, create it in the place:
Array<widget> c;
widget& w = c.Add();
If you want polymorhism, you can choose either
widget& w = c.Add<button>();
or (less elegant, but equivalent and sometimes necessary)
widget& w = c.Add(new button);
Note however that Array is (as any U++ container) ALWAYS owning its
content and always represents it in direct way. Means, nothing prevents
you to define operator< and
Sort(c);
> The "STL" isn't sitting still either. Here is how it is currently
> looking for C++0X.
>
> class widget
> {
> public:
> ...
> widget(widget&& w);
> widget& operator=(widget&& w);
> ...
> private:
> widget(const widget&);
> widget& operator=(const widget&);
> };
>
> ...
>
> std::list<widget> c;
> c.push_back(widget());
>
> That will work with vector, map, etc. too. I.e. Today's C++ programmers
> won't have to learn a lot of new syntax (e.g. AddTailPick).
Unfortunately, for
struct DialogPart {
button ok, cancel;
vector<editor_widget> field;
};
you are out of luck once again, unless you will suffer painful process
of defining moving contructor for whole class.
> You'll even be able to return your movable but non-copyable widgets from
> factory functions:
My widgets are both non-copyable AND non-movable. You cannot apply move
magic to polymorphy.
I guess that your opinion is that NTL is just about moving. No, moving
is just one part of problem. And your proposal actually solves just one
special case of moving - as there are no composition options, moving
will be in practice reserved just for predefined types. It is far too
easy for lazy programmer to forget move constructor.
> There are lots of similarities between NTL and the currently proposed
> C++0X STL. But the biggest difference is that the newer STL has a lot
> of backwards compatibility with today's STL. It will look and feel very
> much like today's. It will just do a lot more moving than copying (and
> have the associated performance increases).
Actually, NTL in fact does not do too much moving - it is mostly
reserved for function return values and special cases (like swap). In
NTL it is much more often "cheap-copy" (fundamental types, COWs),
"create-in-place" or "memcpy" (to manage Vector internals).
Mirek
Mirek Fidler
>>
>>How are you going to put that GUI widget into the list? Last time I have
>>checked, push_back had single "const T&" parameter...
>
>
> Just keep adding the constraints and you'll always win in the end.
Well, sorry, I was not defining things properly on preceeding post. When
I was speaking about "copying", I was speaking about both assignable and
copy-constructible requirements. It is as hard to define GUI Widget
copy-constructor as it is to define operator=, right?
>>Could be. How would you advice me to put my GUI widget (which naturally
>>lacks any form of copy operation) to the list?
>
>
> I wouldn't. I'd advise you to pick the OO language of your choice and use
> it. Now if I were to design a GUI for C++, it would not "naturally" lack
> certain useful properties...
I perhaps do not undestand... Do you really consider copy constructor
for GUI widget as a good idea? So far I am not aware about any GUI
library in any language that would implement widgets with any form of
value-semantics.. (and I have studied a lot of them).
Mirek
Howard Hinnant
Mirek Fidler <c...@volny.cz> wrote:
> > I'm not an NTL expert by any means.
>
> Well, I think as our "cooperation" in both mailing lists seems to
> continue, I will try to learn you via posts as much as possible :)
Yes, I would enjoy that, thanks.
> > But if I understand correctly, this
> > is how you might do it with NTL?
> >
> > class widget
> > {
> > public:
> > ...
> > widget(pick_ widget& w);
> > widget& operator=(pick_ widget& w);
> > ...
> > private:
> > widget(const widget&);
> > widget& operator=(const widget&);
> > };
> >
> > ...
> >
> > BiVector<widget> c;
> > widget w;
> > c.AddTailPick(w);
> >
> > Is that about right?
>
> No. This would require pick (aka implicit move) constructor in widget.
> Far too restricting.
>
> Instead, the solution is to completely avoid the transfer of widget to
> container. Means, create it in the place:
>
> Array<widget> c;
> widget& w = c.Add();
And for non-default constructed widget?
> If you want polymorhism, you can choose either
>
> widget& w = c.Add<button>();
>
> or (less elegant, but equivalent and sometimes necessary)
>
> widget& w = c.Add(new button);
Ah, now button is a class derived from widget? For C++0X STL this might
look like:
std::vector<std::unique_ptr<widget> > c;
c.push_back(std::unique_ptr<widget>(new button));
Making it explicit that you are:
1. Storing pointers.
2. Having the container own the pointer.
3. Zero overhead (sizeof(unique_ptr) == sizeof(auto_ptr) == sizeof
(void*).
> Note however that Array is (as any U++ container) ALWAYS owning its
> content and always represents it in direct way. Means, nothing prevents
> you to define operator< and
>
> Sort(c);
<nod>
> Unfortunately, for
>
> struct DialogPart {
> button ok, cancel;
> vector<editor_widget> field;
> };
>
> you are out of luck once again, unless you will suffer painful process
> of defining moving contructor for whole class.
Painful is in the eye of the beholder. It would look exactly like:
struct DialogPart {
button ok, cancel;
vector<editor_widget> field;
DialogPart(DialogPart&& dp)
: ok(std::move(dp.ok)),
cancel(std::move(dp.cancel)),
field(std::move(dp.field))
{}
};
There has been interest in automating this along the lines of N1717
which might look something like:
struct DialogPart {
button ok, cancel;
vector<editor_widget> field;
DialogPart(DialogPart&&) {default}
};
Although there may be some controversy as to what it means to move a
scalar in this context. One school of thought is to just copy it.
Another is to copy it, followed by zeroing the source. Neither is right
all of the time.
There has actively been disinterest in generating move constructors
implicitly without some sort of user intervention (such as inspired by
N1717). Many people (and I count myself among them) think of implicitly
generated special members as a continual source of bugs, and do not want
to see the practice expanded (modulo something along the lines of
N1717). For example, classes which are self referential can not have
implicitly generated move constructors (it would generate incorrect
code). If such classes were to suddenly acquire such special members
without warning with C++0X, we would be in sorry shape indeed.
> > You'll even be able to return your movable but non-copyable widgets from
> > factory functions:
>
> My widgets are both non-copyable AND non-movable. You cannot apply move
> magic to polymorphy.
A polymorphic type can be moved the same as any other type, you just
have to know the runtime type of the object. If you only know the
static type, then you must work via a pointer or reference to the base
type. A library can help mask this fact by making a container of
pointers look like a container of values, and that technique may even be
valuable in some contexts.
But what is missing today is an effective way to build the base layer:
a container of pointers (which the container owns). The best we have
today is container<shared_ptr<T>>, or perhaps container<clone_ptr<T>>.
Move semantics will bring container<unique_ptr<T>> (which is roughly
equivalent to the often desired container<auto_ptr<T>>). On top of
container<unique_ptr<T>> it will be easy to build adaptors to make that
look like a container of values if that is what you desire.
> I guess that your opinion is that NTL is just about moving. No, moving
> is just one part of problem. And your proposal actually solves just one
> special case of moving - as there are no composition options, moving
> will be in practice reserved just for predefined types. It is far too
> easy for lazy programmer to forget move constructor.
Especially for self-referential types. Not implicitly generating a move
constructor is absolutely a key feature for C++0X not turning working
code into buggy code.
> > There are lots of similarities between NTL and the currently proposed
> > C++0X STL. But the biggest difference is that the newer STL has a lot
> > of backwards compatibility with today's STL. It will look and feel very
> > much like today's. It will just do a lot more moving than copying (and
> > have the associated performance increases).
>
> Actually, NTL in fact does not do too much moving - it is mostly
> reserved for function return values and special cases (like swap). In
> NTL it is much more often "cheap-copy" (fundamental types, COWs),
> "create-in-place" or "memcpy" (to manage Vector internals).
Ok. I'm not sure if Vector stores values or pointers. If it stores
pointers, it seems like Vector<pair<pod,pod>> might be more expensive
than it needs to be. If it stores values, I'd worry about the use of
memcpy to manage its internals. Or perhaps Vector has a way to choose
its internal structure?
> Do you really consider copy constructor
> for GUI widget as a good idea? So far I am not aware about any GUI
> library in any language that would implement widgets with any form of
> value-semantics.
I think a move constructor for a GUI widget would be a very good idea.
It will allow (for example) a GUI widget to be returned by value from a
factory function. And it will allow clients the choice of how to store
containers of that GUI widget.
struct base
{
virtual ~base() {}
};
struct derived1
: public base
{
private:
int* data_;
derived1(const derived1&);
derived1& operator=(const derived1&);
public:
derived1() : data_(new int(0)) {}
~derived1() {delete data_;}
derived1(derived1&& d) : data_(d.data_) {d.data_ = 0;}
derived1& operator=(derived1&& d) {swap(d); return *this;}
void swap(derived1& d) {std::swap(data_, d.data_);}
};
struct derived2
: public base
{
private:
double* data_;
derived2(const derived2&);
derived2& operator=(const derived2&);
public:
derived2() : data_(new double(0)) {}
~derived2() {delete data_;}
derived2(derived2&& d) : data_(d.data_) {d.data_ = 0;}
derived2& operator=(derived2&& d) {swap(d); return *this;}
void swap(derived2& d) {std::swap(data_, d.data_);}
};
derived1
make_derived1()
{
return derived1();
}
derived2
make_derived2()
{
return derived2();
}
Now clients can either have homogenous containers store a derived type
by value:
std::vector<derived1> vd1;
{
derived1 d1 = make_derived1();
vd1.push_back(std::move(d1));
}
vd1.push_back(make_derived1());
// vd1.push_back(make_derived2()); // compile-time error
and have the homogeneity checked by the compiler.
Or the client can have heterogeneous containers storing a base type
pointer:
std::vector<std::unique_ptr<base> > vb;
vb.push_back(std::unique_ptr<base>(new derived1(make_derived1())));
vb.push_back(std::unique_ptr<base>(new derived2(make_derived2())));
with only the overhead of container<base*>.
No doubt that further abstractions can be built upon
std::vector<std::unique_ptr<base> >.
-Howard
robert...@gmail.com
Mirek Fidler wrote:
> > I wouldn't. I'd advise you to pick the OO language of your choice and use
> > it. Now if I were to design a GUI for C++, it would not "naturally" lack
> > certain useful properties...
>
> I perhaps do not undestand... Do you really consider copy constructor
> for GUI widget as a good idea? So far I am not aware about any GUI
> library in any language that would implement widgets with any form of
> value-semantics.. (and I have studied a lot of them).
Since the GUI frameworks I have worked with all used pointers or
references (usuallly the former) I fail to see why you are placing so
much importance on needing to place them directly into containers. The
only reason why you would want to have any kind of container full of
widgets is if you were a) creating a parent widget or b) needing access
to a large array of widgets later. The later problem is most easily
done by placing pointers inside of a container. The former is probably
also best solved in the same manner although in this case you may be
responsible for their destruction so a smart pointer might be in order;
with the former case you don't even WANT to delete them as the parent
widget usually does this.
So I have to wonder what it is you want to solve by placing widgets
directly into containers. I certainly don't think that requiring
container contents to be assignable and copyable are weaknesses of the
container considering what these containers contain (lvalues). Like
you said, widgets don't have "value semantics" and since std c++
containers *contain values* I think it rather obvious that they
wouldn't be the best thing to contain a widget directly (though a
pointer to one is a non-issue) or any other non-value object.
Finally, any weakness in the std library containers is EASILY dealt
with by the creation of containers that are not part of the std library
so any weakness in the std library containers can, in no way, be seen
as a weakness in the language. What you desire is a container that
requires a certain set of policies about object ownership that are
simply not addressed by the containers in std c++...you are quite free
to create such containers and the easiest way might very well be using
the std c++ containers and some method of pointer, smart or otherwise.
IMHO you are really being quite silly with you chosen direction of
argument. The ways to solve the problem you are up in arms about are
numerous.
puzzlecracker
> http://www.joelonsoftware.com/items/2005/12/29.html
This is classic!!!! it dissipates most of concerns!!! I simply love
it!!!! But hey, no one nowadays is writing applications using
pointers (those are only maintained now and are waiting to be
re-written or simply forgotten).
Is it really worthwhile nowadays to sacrifice memory leak possibilities
and complicated programming, usually making it difficult to read, for
efficiency?
I am glad that C was my first programming language thought in college!
James Juno
Spolsky's intent here is not to espouse pointers and recursion, but
rather to point out the decay of what constitutes CS competency simply
for the sake of pumping out more grads. I see it quantitatively
everyday by the applications I receive from prospective employees and
from the interviews. But this has evolved so far OT (and a troll's
topic at that) that I'll just shut up now.
Thanks,
JJ
Mirek Fidler
>>container. Means, create it in the place:
>>
>>Array<widget> c;
>>widget& w = c.Add();
>
>
> And for non-default constructed widget?
Well, on my top-ten coding guidelines list is "always provide a cheap
default constructor". It makes your composition ortogonal.
Anyway, you can always use the variant with "new"
widget& w = c.Add(new button("OK"));
> Ah, now button is a class derived from widget? For C++0X STL this might
> look like:
>
> std::vector<std::unique_ptr<widget> > c;
> c.push_back(std::unique_ptr<widget>(new button));
>
> Making it explicit that you are:
>
> 1. Storing pointers.
> 2. Having the container own the pointer.
> 3. Zero overhead (sizeof(unique_ptr) == sizeof(auto_ptr) == sizeof
> (void*).
So you have replaced one smart pointer with another....
> Painful is in the eye of the beholder. It would look exactly like:
>
> struct DialogPart {
> button ok, cancel;
> vector<editor_widget> field;
>
> DialogPart(DialogPart&& dp)
> : ok(std::move(dp.ok)),
> cancel(std::move(dp.cancel)),
> field(std::move(dp.field))
> {}
> };
Yes, this is extremly painful _and_ error-prone. DialogPart has
relatively low number of members, but imagine a little bit more of them.
Them imagine refactoring of class a year later and adding single bool
attribute... Chances that you will forget to fix your moving constructor
are high and chances that this bug will be unnoticed (for bool
attribute) are not as low either.
Actually, I am speaking from my experience here... While default pick
contructor is implicitly created by compiler with NTL, some classes have
"deep copy option" - alternative copy operation provided by
"operator<<=" and "T(const T&, int)" constructor. Their definitions are
very similar to above moving constructor definition and I was several
times caught by bugs there...
> There has actively been disinterest in generating move constructors
> implicitly without some sort of user intervention (such as inspired by
> N1717). Many people (and I count myself among them) think of implicitly
> generated special members as a continual source of bugs, and do not want
> to see the practice expanded (modulo something along the lines of
> N1717). For example, classes which are self referential can not have
> implicitly generated move constructors (it would generate incorrect
> code).
They cannot have implicitly generated default copy constructor either.
Just avoid automatic generation of move constructor when explicit copy
constructor is defined and problem is solved.
> type. A library can help mask this fact by making a container of
> pointers look like a container of values, and that technique may even be
> valuable in some contexts.
Definitely :)
> But what is missing today is an effective way to build the base layer:
Vector<void *> works just fine for me...
> a container of pointers (which the container owns). The best we have
> today is container<shared_ptr<T>>, or perhaps container<clone_ptr<T>>.
> Move semantics will bring container<unique_ptr<T>> (which is roughly
> equivalent to the often desired container<auto_ptr<T>>). On top of
> container<unique_ptr<T>> it will be easy to build adaptors to make that
> look like a container of values if that is what you desire.
IMHO, unique_ptr has no real advantage in implementing such container.
It is almost as easy to manage memory manually inside the Array (in the
end, your are implementing it just once; source code for Array is 150
lines).
> Ok. I'm not sure if Vector stores values or pointers. If it stores
> pointers, it seems like Vector<pair<pod,pod>> might be more expensive
> than it needs to be. If it stores values, I'd worry about the use of
> memcpy to manage its internals. Or perhaps Vector has a way to choose
> its internal structure?
No :) The key difference that you might have missed is that there are
TWO container "flavors" - Vector flavor and Array flavor.
Vector flavor is quite restrictive for types it can store and is
implemented using continual storage (it has slightly different
requirements for T than STL, T has to have some form of value tranfer -
pick or copy - and must follow a set of rules that allows NTL
implementation to use memcpy to manage continual storage instead of
copy/move constructing if possible).
Array is implemented using Vector<void *>.. Array has NO requirements
for T and you can store abolutely anything in it, including derived types.
The important fact to note is that Vector semantics and interface is 99%
subset of Array. Means you can always change your code to use Array
instead of Vector just replacing the name. Moreover, once item "gets
into" the container, both behave the same from interface point of view.
Now all NTL containers come in those two flavors (with some minor
exceptions). That might double the number of container types (from 4 to
8), but totally eliminates the need for smart pointers, iterator
adaptors and other "smart" stuff that makes C++ dinosaurus language.
Sorry, this does not make sense. You are solving here the problem that
you itself have created by providing move constructor the class that is
the part of hierarchy (IMO, NEVER DO THAT!). Reasonable GUI library
simply will not provide any means for value transfer and problem will
not exist. Instead, with NTL you can manage things like this:
void ButtonFactory1(Array<widget>& x)
{
x.Add<button>();
}
or
widget *ButtonFactory2()
{
return new button;
}
Array<widget> vd;
ButtonFactory1(vd);
vd.Add(ButtonFactory2());
> Or the client can have heterogeneous containers storing a base type
> pointer:
>
> std::vector<std::unique_ptr<base> > vb;
> vb.push_back(std::unique_ptr<base>(new derived1(make_derived1())));
> vb.push_back(std::unique_ptr<base>(new derived2(make_derived2())));
>
> with only the overhead of container<base*>.
>
> No doubt that further abstractions can be built upon
> std::vector<std::unique_ptr<base> >.
I see only a little difference between this and using shared_ptr. It is
faster, yes, but from programmers perspective, one smart pointer or
another, both are as painful.
Mirek
Mirek Fidler
>>for GUI widget as a good idea? So far I am not aware about any GUI
>>library in any language that would implement widgets with any form of
>>value-semantics.. (and I have studied a lot of them).
>
>
> Since the GUI frameworks I have worked with all used pointers or
> references (usuallly the former) I fail to see why you are placing so
> much importance on needing to place them directly into containers.
Because it fits my rapid application development pattern
(http://upp.sourceforge.net/www$uppweb$overview$en-us.html). If things
are arranged well, it can save a lot of effort quite often.
Moreover, GUI widgets stay as example here. Replace it with streams if
you wish :)
> So I have to wonder what it is you want to solve by placing widgets
> directly into containers.
Most of time, I need that if I am about to create content of dialog
based on some external data, like database tables or XML.
> container considering what these containers contain (lvalues). Like
> you said, widgets don't have "value semantics" and since std c++
> containers *contain values* I think it rather obvious that they
> wouldn't be the best thing to contain a widget directly (though a
> pointer to one is a non-issue) or any other non-value object.
Well, this a circle definition. "You cannot store widget directly into
STL, therefore you cannot store the widget directly".
I CAN however store it directly into NTL container without a problem and
find very useful.
> Finally, any weakness in the std library containers is EASILY dealt
> with by the creation of containers that are not part of the std library
> so any weakness in the std library containers can, in no way, be seen
> as a weakness in the language.
I never said that C++ has weaknesses here. I love C++, love its
flexibility and prefer it over anything else, that is why I am here.
Anyway, C++ is represented by STL right now. And STL makes it the
monster language. That is all.
> What you desire is a container that
> requires a certain set of policies about object ownership that are
> simply not addressed by the containers in std c++
I do not desire. I am using NTL for more than 7 years now.
> ...you are quite free
> to create such containers and the easiest way might very well be using
> the std c++ containers and some method of pointer, smart or otherwise.
>
> IMHO you are really being quite silly with you chosen direction of
> argument. The ways to solve the problem you are up in arms about are
> numerous.
Problem is solved. That is not the problem :)
Mirek
Howard Hinnant
Mirek Fidler <c...@volny.cz> wrote:
> > std::vector<std::unique_ptr<widget> > c;
> > c.push_back(std::unique_ptr<widget>(new button));
> >
> > Making it explicit that you are:
> >
> > 1. Storing pointers.
> > 2. Having the container own the pointer.
> > 3. Zero overhead (sizeof(unique_ptr) == sizeof(auto_ptr) == sizeof
> > (void*).
>
> So you have replaced one smart pointer with another....
No, not replaced. Added to the set of useful tools. There is no such
thing as the One True SmartPointer.
> Array is implemented using Vector<void *>
Thanks, that helps. There is a similar library (implemented after NTL
was) here:
http://www.boost.org/libs/ptr_container/doc/ptr_container.html
The latter appears to be more concerned with exception safety than the
former, however that is just an implementation detail.
Array<Number> num;
num.Add(new Integer(3)); // if Add throws, new is leaked
boost::ptr_vector<animal> vec;
vec.push_back( new animal ); // if push_back throws, new is deleted
> one smart pointer or
> another, both are as painful.
I'm having trouble making such a large distinction between an object
that owns one pointer and an object that owns many. Why is one so
painful while the other so useful?
One of the fundamental issues that owning objects keep wrestling with is
what to do on "copy":
NTL containers:
-----------
Move with copy syntax.
Copies with other syntax.
boost::Pointer Containers:
------------------
Copy syntax disabled.
Copies with other syntax.
And if you'll allow me to think of smart pointers as pointer-owning
containers...
auto_ptr
------
Move with copy syntax.
shared_ptr
--------
Shares ownership with copy syntax.
clone_ptr
-------
Copies with copy syntax.
unique_ptr
--------
Moves with copy syntax from rvalues.
Copy syntax disabled from lvalues.
Moves with other syntax from lvalues.
With the obvious exception of auto_ptr, containers of these smart
pointers have move/copy behavior the same as an individual smart pointer.
There is no One Right Way. However I believe some techniques are more
error prone than others. For example, moving with copy syntax from
lvalues can be dangerous for generic code. For example a generic
algorithm might have a statement that looks like:
...
value_type pivot_element = *mid_point;
...
The algorithm might implicitly assume that after this statement,
pivot_element and *mid_point are equivalent. But if value_type moves
with copy syntax from lvalues, that assumption is invalidated, and could
lead to run time errors (indeed this was the reason auto_ptr was changed
to be inhospitable to containers just prior to the '98 standard).
So when I read:
> Vector<int> v1 = v;
> now source Vector v is destroyed - picked - and you can no longer access its
> content. Awful it might seem, it allows using containers as return values.
I'm hesitant to believe, however useful NTL has been for you, that NTL
should replace STL in general. However, the very motivation you state
for moving with copy syntax:
> allows using containers as return values
is imho, a dramatically strong motivation! :-) I can well understand
why you designed NTL the way you did because of this! You had to work
with C++98.
C++0X is to give us the best of both worlds (assuming adoption of the
rvalue reference proposals). Expensive-to-copy types will copy from
lvalues with copy syntax, and yet they will still be cheaply returnable
by value:
std::vector<int> f()
{
std::vector<int> result;
....
return result;
}
In the return statement, if the "copy" of result isn't elided (by
present day rules), then it will be considered an rvalue for the purpose
of selecting the copy operation. And because vector will have a move
constructor (pick constructor or whatever we call it), the "result" will
move instead of copy out of the function.
The client of f() will also see moving, instead of copying, even if rvo
is disabled:
std::vector<int> v;
v = f();
Since "f()" is an rvalue expression, the above statement will invoke
vector's "move assignment" instead of its copy assignment. This is
essentially why it is important to:
> Moves with copy syntax from rvalues.
Doing so does not invoke dangers as related to the "pivot_element"
example described above, and does enable the O(1) performance of
return-by-value with clean syntax.
Note that there are very few cases where the compiler will perform an
implicit cast to rvalue from an lvalue. The above "result" example is
the most important case. In general, the implicit move-from-lvalue will
only happen where copy elision is already legal today. This will allow
programmers to return big objects by-value guilt-free. They won't have
to worry if RVO is actually going to happen or not. RVO will either
happen, or the return will be by-move (the return is either free or
cheap but definitely not O(N)).
-Howard
Mirek Fidler
>
>
> No, not replaced. Added to the set of useful tools. There is no such
> thing as the One True SmartPointer.
Well, I would change that to "the only true smart pointer is no smart
pointer" :)
>>Array is implemented using Vector<void *>
>
>
> Thanks, that helps. There is a similar library (implemented after NTL
> was) here:
>
> http://www.boost.org/libs/ptr_container/doc/ptr_container.html
>
> The latter appears to be more concerned with exception safety than the
> former, however that is just an implementation detail.
>
> Array<Number> num;
> num.Add(new Integer(3)); // if Add throws, new is leaked
>
> boost::ptr_vector<animal> vec;
> vec.push_back( new animal ); // if push_back throws, new is deleted
Yes, that is correct. For the time being, Add is assumed to never throw.
In out-of-memory condition, U++ app simply stops.
In future, this can be resolved and fixed, but the actual presure is low
now.
> I'm having trouble making such a large distinction between an object
> that owns one pointer and an object that owns many. Why is one so
> painful while the other so useful?
In my mindset, the fundamental problem with shared_ptr is that it makes
ownership fuzzy. Of course, that does not apply to unique_ptr.
Another problem is that in container<smart_ptr<T>> composition this adds
one unnecessary component into your code. I belive that less components
your code uses, easier is the maintainance.
> There is no One Right Way. However I believe some techniques are more
> error prone than others. For example, moving with copy syntax from
> lvalues can be dangerous for generic code. For example a generic
> algorithm might have a statement that looks like:
>
> ...
> value_type pivot_element = *mid_point;
> ...
>
> The algorithm might implicitly assume that after this statement,
> pivot_element and *mid_point are equivalent.
In that case the algorithm is not well written for its set of
preconditions. That is why NTL had to reimplement algorithm library.
It is clear that you have to be quite careful before using STL
algorithms on NTL containers.
OTOH, the only thing you have to check is whether your T satisfies STL's
requirements (precondition). That is quite natural, is not it?
> But if value_type moves
> with copy syntax from lvalues, that assumption is invalidated, and could
> lead to run time errors (indeed this was the reason auto_ptr was changed
> to be inhospitable to containers just prior to the '98 standard).
>
> So when I read:
>
>
>> Vector<int> v1 = v;
>>now source Vector v is destroyed - picked - and you can no longer access its
>>content. Awful it might seem, it allows using containers as return values.
>
>
> I'm hesitant to believe, however useful NTL has been for you, that NTL
> should replace STL in general.
I think you can stay calm, such a thing is impossible to happen:)
> However, the very motivation you state
> for moving with copy syntax:
>
>
>>allows using containers as return values
>
>
> is imho, a dramatically strong motivation! :-)
;) I guess that article needs some refactoring :)
> C++0X is to give us the best of both worlds (assuming adoption of the
> rvalue reference proposals). Expensive-to-copy types will copy from
> lvalues with copy syntax, and yet they will still be cheaply returnable
> by value:
>
> std::vector<int> f()
> {
> std::vector<int> result;
> ....
> return result;
> }
>
> In the return statement, if the "copy" of result isn't elided (by
> present day rules), then it will be considered an rvalue for the purpose
> of selecting the copy operation. And because vector will have a move
> constructor (pick constructor or whatever we call it), the "result" will
> move instead of copy out of the function.
Howard, I always liked your proposal. The only thing I miss is automatic
composition, based purely on the fact that I have a lot of code using
moving syntax and I can imagine practical consequences of this decision.
However, another issue where implicit moving of containers is object
identity issue:
Array<Ctrl> FactoryCtrls()
{
Array<Ctrl> x;
x.Add(new Button);
return x; // now what?
}
Here Array "encloses" contained objects. With implicit pick semantics,
things are straightforward, Buttons keep the identity. If I understand
your proposal well, move contructor will be issued as well here, but it
is a little bit scary to me that '=' sometimes issues a move and
sometimes a copy. I believe that it can lead to some hard to catch errors:
Array<Ctrl> x = FactoryCtrls();
....
Array<Ctrl> y = FactoryCtrls();
Array<Ctrl> z = y;
with NTL everything works as expected. With STL0x this can lead to
interesting silent bug.
What I want to say is that for some types, moving is natural. (I guess
you agree on this). If it is natural, it can be implicit. And I think
that set of naturally moving types includes containers.
Mirek
Mirek Fidler
>
>
> is imho, a dramatically strong motivation! :-)
I have checked the place where it is explained this way... Well, the
real meaining should have been that this is why pick behaviour is
implicit. If there would be another way how to make pick work for
function returns (with current language), we could use explicit pick
operation.
However, I am not a very good stylist in english to explain this simply....
Mirek
Howard Hinnant
Mirek Fidler <c...@volny.cz> wrote:
> However, another issue where implicit moving of containers is object
> identity issue:
>
> Array<Ctrl> FactoryCtrls()
> {
> Array<Ctrl> x;
> x.Add(new Button);
> return x; // now what?
> }
>
> Here Array "encloses" contained objects. With implicit pick semantics,
> things are straightforward, Buttons keep the identity. If I understand
> your proposal well, move contructor will be issued as well here,
Your code will continue to function as it does now. Your "pick"
constructor will either be called or elided:
Array(pick_ Array& v);
If you wanted (and you don't have to), you could add another constructor:
Array(Array&& v);
For you, this would make little sense as this new constructor would do
the exact same thing as your pick constructor. But if you did add it,
it would be selected (and perhaps elided) instead of your pick
constructor.
> but it
> is a little bit scary to me that '=' sometimes issues a move and
> sometimes a copy.
I can understand your trepidation. The general design is:
If you have some way to observe the move (besides measuring
performance), then it won't happen implicitly (with copy syntax).
Rather, copy syntax will copy.
> I believe that it can lead to some hard to catch errors:
>
> Array<Ctrl> x = FactoryCtrls();
>
> ....
> Array<Ctrl> y = FactoryCtrls();
> Array<Ctrl> z = y;
>
> with NTL everything works as expected. With STL0x this can lead to
> interesting silent bug.
NTL will continue to operate in C++0X as it does today. The new "STL"
associated with C++0X will continue to operate as it does today, only
faster for some operations. For example, substituting vector<Ctrl> for
Array<Ctrl> in the code above:
vector<Ctrl> x = FactoryCtrls(); // will move, just like NTL
....
vector<Ctrl> y = FactoryCtrls(); // will move, just like NTL
vector<Ctrl> z = y; // will copy, just like today's STL
The reasoning is to *prevent* silent bugs. Clients can observe the
state of y after the construction of z, and most clients (except you ;-)
) will assume that y is unmodified by the construction of z. However,
moving from rvalues is safe because the client has no reference to the
moved-from rvalue to inspect after the fact.
> What I want to say is that for some types, moving is natural. (I guess
> you agree on this). If it is natural, it can be implicit. And I think
> that set of naturally moving types includes containers.
For some types both moving and copying are natural (I generally put
containers in this category, admittedly with some exceptions). For
others only moving is natural (auto_ptr springs to mind, as does a
container which has unique ownership of a non-copyable type). I think
our fundamental difference is the syntax we prefer for copy vs move, at
least from lvalue sources (warning best viewed in mono-spaced font):
you prefer: I prefer:
For copy: x <<= y; x = y;
(from lvalues)
For move x = y; x = std::move(y);
(from lvalues)
For move x = FactoryCtrls(); x = FactoryCtrls();
(from rvalues)
Note I don't have a "copy from rvalue" row. I suspect we both agree
that you always want to move from rvalues (and if move and copy are the
same operation for some type, no harm done). Indeed, except for syntax,
I think we agree with each other very much. :-)
-Howard
Mirek Fidler
> In article <41ppj9F...@individual.net>,
> Mirek Fidler <c...@volny.cz> wrote:
>
>
>>However, another issue where implicit moving of containers is object
>>identity issue:
>>
>>Array<Ctrl> FactoryCtrls()
>>{
>> Array<Ctrl> x;
>> x.Add(new Button);
>> return x; // now what?
>>}
>>
>>Here Array "encloses" contained objects. With implicit pick semantics,
>>things are straightforward, Buttons keep the identity. If I understand
>>your proposal well, move contructor will be issued as well here,
>
>
> Your code will continue to function as it does now.
Sure it will. Without automatic composition, I am not going to replace
pick_ with &&....
> For some types both moving and copying are natural (I generally put
> containers in this category, admittedly with some exceptions). For
> others only moving is natural (auto_ptr springs to mind, as does a
> container which has unique ownership of a non-copyable type). I think
> our fundamental difference is the syntax we prefer for copy vs move, at
Actually, I see two differences:
a) You seem to have the possibility to change the core language :)
b) You have designed it mostly as performance enhancements. Primary for
you is backward compatibility with existing code (very legitimate
concern!). Only later you have found some semantics possibilities like
unique_ptr etc. I had no reasons to maintain backward compatibility (in
the end, STL code works in U++ as expected and NTL has different syntax)
and meanwhile found pick semantics very helpful for code organization in
specific situations. Later become increasly important over years and now
I am sure that "picking" is really the right behaviour for any
ownership issues.
> least from lvalue sources (warning best viewed in mono-spaced font):
>
> you prefer: I prefer:
>
> For copy: x <<= y; x = y;
> (from lvalues)
>
> For move x = y; x = std::move(y);
> (from lvalues)
>
>
> For move x = FactoryCtrls(); x = FactoryCtrls();
> (from rvalues)
>
> Note I don't have a "copy from rvalue" row. I suspect we both agree
> that you always want to move from rvalues (and if move and copy are the
> same operation for some type, no harm done). Indeed, except for syntax,
> I think we agree with each other very much. :-)
We always did as far as moving is concerned (except composition issue).
Anyway, as I said before, moving is only one of problems I see in STL....
Mirek
robert...@gmail.com
Howard Hinnant wrote:
> NTL will continue to operate in C++0X as it does today.
Ok, what is NTL. The only thing I can find is this:
http://www.shoup.net/ntl/doc/tour-modules.html
I don't think this is what you guys are talking about.
Howard Hinnant
robert...@gmail.com wrote:
Sorry, here's a link:
-Howard
Howard Hinnant
Mirek Fidler <c...@volny.cz> wrote:
> Actually, I see two differences:
>
> a) You seem to have the possibility to change the core language :)
>
> b) You have designed it mostly as performance enhancements. Primary for
> you is backward compatibility with existing code (very legitimate
> concern!). Only later you have found some semantics possibilities like
> unique_ptr etc. I had no reasons to maintain backward compatibility (in
> the end, STL code works in U++ as expected and NTL has different syntax)
> and meanwhile found pick semantics very helpful for code organization in
> specific situations.
<nod> Well put. Although "perfect forwarding" has also been a primary
goal from nearly the beginning:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm#s7
(and which Peter Dimov deserves all the credit).
And we're still waiting to see if "a" is actually true. It is a slow and
laborious process. :-\ But that is as it should be. I'm now half way
through my fifth year on this quest, and am actually now optimistic
about "a".
-Howard
Bushido Hacks
Yakov Smirnoff called. He just wanted to remind you that in
post-Communist Russia you do not close newsgroup, NEWSGROUP CLOSES YOU!
Long live comp.lang.c++! Down with the Troll-eltariot!
Andrej Hristoliubov wrote:
> I had a revelations yesterday (a holy spirit came to me). C++ will
> cease to exist in a month on Jan 23, 2006. There won't be any
> standardization. There will be funeral. Newsgroup should be closed.
>
> Thank you for you cooperation.
>
> Andjey
> ----
>
> Дамы и господа с неохотой, хочу вас
> катастрофически огорчить: 23 Января 2006
> года, С++ покинет этот мир, как
> доминирующий язык программирования.
> Это было истинное и духовное открытие
> олицетворяющее в моей душе. Эта моя
> миссия вас подготовить к это ужасной
> трагедии и оповестить о ее
> невозвратимой реализации. Будьте
> бдительны, и пожалуйста - без
> хулиганства.
>
> Спасибо друзья,
>
> Я всегда буду в ваших душах!
>
> Андрюша
> ----------------------
>
>
> Damy i gospoda s neohotoj, hochu vas katastroficheski ogorchit': 23
> Janvarja 2006 goda, S++ pokinet jetot mir, kak dominirujushhij jazyk
> programmirovanija. Jeto bylo istinnoe i duhovnoe otkrytie
> olicetvorjajushhee v moej dushe. Jeta moja missija vas podgotovit' k
> jeto uzhasnoj tragedii i opovestit' o ee nevozvratimoj realizacii.
> Bud'te bditel'ny, i pozhalujsta - bez huliganstva.
>
> Spasibo druz'ja,
>
> Ja vsegda budu v vashih dushah!
>
> Andrjusha
Mirek Fidler
NTL is the name of container/algorithm library of U++ development platform:
http://upp.sf.net
http://upp.sourceforge.net/www$uppweb$overview$en-us.html
http://upp.sourceforge.net/srcdoc$Core$NTL$en-us.html
http://upp.sourceforge.net/srcdoc$Core$Tutorial$en-us.html
Mirek
Mirek Fidler
Earl Purple
Jim Langston wrote:
> Thank you.
Well a topic that has got over 80 responses from many different
contributors (can't be bothered counting but it's enough) is obviously
interesting enough to be on the minds of people who post here.
It is of great interest to me. We are here to discuss the language of
C++ and if you follow the discussion it has become a topic on that
subject, and its use in the world.
>From a personal point of view I love C++, I would like to see it
further developed and used in greenfield projects. I do not want to
spend the rest of my career maintaining legacy code while all the new
exciting stuff is done in other languages like C# or Java.
Earl Purple
Howard Hinnant wrote:
> I've been trying to turn my head and ignore this thread for the longest
> time. But as today I'm working on a revision to N1855, the subject is
> on my mind even more than usual... ;-)
>
> widget w;
> c.push_back(w); // compile-time error, can't copy widget
>
> That's a feature not a bug. You don't want to accidently move from a
> named object which you can later reference (and perhaps not realize it
> has been moved from). If you really want to move from a named widget
> (an lvalue widget), you can:
>
> std::list<widget> c;
> widget w;
> c.push_back(std::move(w)); // ok
Is this a language change or a library implementation? What I have seen
looks strange to me and not sure if it part of the current C++
language.
> If you want to learn more about a move-enabled STL see this paper:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1771.html
which I have read. I think that to improve orthogonality and remove
ambiguity, it would be better to use explicit move whenever you want a
move rather than a copy. Then you could do this;
std::vector< T > myFunc
{
std::vector<T> v; // etc
return std::move( v );
}
The previous version would still work for copyable classes and
compilers could use RVO but it would be consistent with the language.
Here you could use the same for non-copyable types.
puzzlecracker
Well CUJ is almost dead.... where is C++ going if magazine cannot its
act together......?
robert...@gmail.com
puzzlecracker wrote:
> Well CUJ is almost dead.... where is C++ going if magazine cannot its
> act together......?
Astrodome writer happens then meteorite. With you well all this
something death. Nevermind you system solid. Where they lived that
bird wing nakid.
Thank you all that, is.
Mike Wahler
"puzzlecracker" <irons...@gmail.com> wrote in message
news:1136496156.5...@z14g2000cwz.googlegroups.com...
>
>> > Andrjusha
>
>
>
> Well CUJ is almost dead.... where is C++ going if magazine cannot its
> act together......?
The future of C++ is in no way affected by the demise of a periodical.
-Mike
Roland Pibinger
<mkwa...@mkwahler.net> wrote:
>"puzzlecracker" <irons...@gmail.com> wrote in message
>news:1136496156.5...@z14g2000cwz.googlegroups.com...
>>
>> act together......?
>
>The future of C++ is in no way affected by the demise of a periodical.
So it's of no relevance that the only C++ magazine on the newsstand
goes out of print and at the same time you can buy there 5 PHP
magazines?
Ben Pope
> So it's of no relevance that the only C++ magazine on the newsstand
> goes out of print and at the same time you can buy there 5 PHP
> magazines?
I doubt it.
Ben Pope
--
I'm not just a number. To many, I'm known as a string...
Victor Bazarov
You can derive other knowledge from it, of course. For example, it is
easier to sell advertising space in a PHP magazine than in a C++ one.
Why it is so, I could speculate, of course. But is it topical here, in
comp.lang.c++? Perhaps this discussion belongs to a magazine publishing
newsgroup...
Other potentially relevant topics include the impossibility to find any
Fortran magazines on the newsstand. Why is that? Is Fortran dead? No.
How long ago did Fortran magazines disappear from the newsstands? Were
they _ever_ there?.. Anyway, moving on...
JustBoo
wrote:
>So it's of no relevance that the only C++ magazine on the newsstand
>goes out of print and at the same time you can buy there 5 PHP
>magazines?
It's called a fad. PHP is the flavor of the month. C++ is far, far
beyond that. People can make money from the herd writing
about this fad. C++ is "mature."
True genius resides in the capacity for evaluation of uncertain,
hazardous, and conflicting information. - Winston Churchill
JustBoo
<benpope...@gmail.com> wrote:
I just hung this off your post Mr. Pope, sorry. My ISP... yada.
>Roland Pibinger wrote:
>> So it's of no relevance that the only C++ magazine on the newsstand
>> goes out of print and at the same time you can buy there 5 PHP
>> magazines?
Something just hit me in the eye like a big pizza pie. These are a
bunch of script-kiddies confusing the State of the Web with the State
of Programming in general. [1] In their myopic web-view if it's not
used on the web then it isn't valid.
As the good Doctor pointed out earlier there is more in the world of
programming than you/I can imagine.
For example, I write C++ code for multi-million dollar test stations
(machine control) and data acquisition systems. Then write 3D
visualization programs to analyze this data and play with it. You
"ain't doin' that" with a script-kiddie deal like PHP, pal. I think
they are just trying to justify their bad and sad decisions. (Maybe
they can't learn C++ either so they want to "burn it down, baby.")
Ooo, in fact, "Father" needs to add OpenSceneGraph to his list.
http://www.openscenegraph.org/
ALL C++ with a lot of design patterns. Very cool.
1. If this as already been stated then I apologize... maybe. :-)
"The trouble with going with the flow is, you might
wind up getting sucked down the drain."
Roland Pibinger
<v.Aba...@comAcast.net> wrote:
>Other potentially relevant topics include the impossibility to find any
>Fortran magazines on the newsstand. Why is that? Is Fortran dead? No.
>How long ago did Fortran magazines disappear from the newsstands? Were
>they _ever_ there?.. Anyway, moving on...
There are also no Cobol and PL/I magazines on the newsstand. I'd
prefer not to see C++ in that row.
Regards,
Roland Pibinger
robert...@gmail.com
C++ is a tool. If it "dies" because nobody wants to use it anymore
then so be it. Things advance, even programming languages and
paradigms. I am a computer programmer, I use what I need to get the
job done. Right now that is C++.
I don't see a lot of magazines about hammer use either.
I never bought the CUJ. I buy books. I read websites. I don't buy
Linux magazines either but that is my personal preference to OS. Point
is that there is no corrilation between magazine sales and use...even
assuming sales, or lack of, was the primary reason for the magazine to
shut down - when there can be any number of alternative explainations.
There is also ample evidence to show that it is not "dead" or dying.
The least of which is not the fact that it is currently important
enough to have a standards committee dedicated to its evolution...but
trolls aren't interested in facts like that...
puzzlecracker
> The future of C++ is in no way affected by the demise of a periodical.
helpful and important information source will be cut down.... I kinda
feel obligated to read it once a month, and now? :(
JustBoo
wrote:
Has there been an official announcement of * why* the mag has shut
down? Perhaps it was not a circulation issue at all, but something
else. Especially given the sudden nature of the whole thing. Stranger
things have happened.
Where I work there are always copies of CUJ and DDJ laying around. I'm
not sure why, but I always tend to pick up DDJ first anyway. :-) In
fact I haven't seen the Feb. issue.
"Solitary trees, if they grow at all, grow strong."
- Winston Churchill
Victor Bazarov
And now you will read comp.lang.c++.moderated a bit more frequently. I am
sure that some who expected to publish their C++ discoveries/innovations
in CUJ now will be compelled to share their views in c.l.c++.m or in other
publications. DDJ is not all that bad, and perhaps with CUJ gone it's
going to be a bit better. I leaf through DDJ once in a while. Now I will
probably do it more often... But this horse is just as dead as CUJ or as
C++ the 'killa trolls about. Perhaps we should stop beating it, eh?
Mike Wahler
"Roland Pibinger" <rpb...@yahoo.com> wrote in message
news:43beaf40...@news.utanet.at...
That's right.
-Mike
Mike Wahler
>
>> The future of C++ is in no way affected by the demise of a periodical.
> C++ programmers who read the magazine will be affected.
But not in any disastrous way.
> This undeniably
> helpful and important information source will be cut down.... I kinda
> feel obligated to read it once a month, and now? :(
You seem to be one of the folks who feel that if
something isn't the way they like, that someone
else should rectify it. If you feel there's a need
for a particular product, create it.
-Mike
Ben Pope
> On Fri, 06 Jan 2006 18:13:33 +0000, Ben Pope
> <benpope...@gmail.com> wrote:
>
> I just hung this off your post Mr. Pope, sorry. My ISP... yada.
>
>> Roland Pibinger wrote:
>>> So it's of no relevance that the only C++ magazine on the newsstand
>>> goes out of print and at the same time you can buy there 5 PHP
>>> magazines?
>
> Something just hit me in the eye like a big pizza pie. These are a
> bunch of script-kiddies confusing the State of the Web with the State
> of Programming in general. [1] In their myopic web-view if it's not
> used on the web then it isn't valid.
PHP is quick and easy for throwing together web sites. Java is fine for
web server type stuff.
C++ is great for anything that needs to be portable and high performance.
Choose the right tool for the job. There are many more tools available
now, and depending on what your requirements are, C++ might not be, and
in fact, in many cases is not, the right tool for the job.
In many cases it IS the right tool for the job. We should just
concentrate on what it is good for, and how to apply it, there's no
requirement to bash other techniques and tools, they have their place.
Anybody who knows C++ knows when to apply it.
Randy Yates
> [...]
> C++ is a tool. If it "dies" because nobody wants to use it anymore
> then so be it. Things advance, even programming languages and
> paradigms.
If it were dying (and I'm not saying it is) because better tools
were available, then it's an advance. But from what I can see
of the new tools, this isn't the case.
What I'm trying to say is that C++ may die simply because of the
herd mentality to use the latest tools out there, even if they're
much less capable, and that would be very unfortunate.
--
% Randy Yates % "Midnight, on the water...
%% Fuquay-Varina, NC % I saw... the ocean's daughter."
%%% 919-577-9882 % 'Can't Get It Out Of My Head'
%%%% <ya...@ieee.org> % *El Dorado*, Electric Light Orchestra
http://home.earthlink.net/~yatescr