Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
"Experimenting with a Proposed Standard Drawing Library for the C++ language"
152 views
Skip to first unread message
Lynn McGuire
Jan 30, 2015, 2:01:18 PM1/30/15
to
"Experimenting with a Proposed Standard Drawing Library for the C++ language"
https://msopentech.com/blog/2015/01/28/experimenting-with-a-proposed-standard-gui-for-the-c-language/
C++ has needed a standard drawing library for a LONG time! This may take hold with Sutter behind it.
http://isocpp.org/blog/2014/01/n3888
Now C++ needs a standard user interface library.
Lynn
https://msopentech.com/blog/2015/01/28/experimenting-with-a-proposed-standard-gui-for-the-c-language/
C++ has needed a standard drawing library for a LONG time! This may take hold with Sutter behind it.
http://isocpp.org/blog/2014/01/n3888
Now C++ needs a standard user interface library.
Lynn
Mr Flibble
Jan 30, 2015, 6:39:44 PM1/30/15
to
have tried and failed to achieve that.
/Flibble
Christopher Pisz
Jan 30, 2015, 6:45:01 PM1/30/15
to
Message has been deleted
Öö Tiib
Jan 31, 2015, 10:14:15 AM1/31/15
to
crap like that Flash (proprietary ECMAScript) or that Unity (also
ECMAScript and Mono) to be successful. Everybody knows how C++ is
more efficient and everybody knows how pad or phone becomes hot in
your hands when such Flash or Unity is running there.
Juha Nieminen
Feb 2, 2015, 5:36:01 AM2/2/15
to
The problem with a *standard* GUI library is that the standard evolves
very, very slowly. The standard is updated every 5 years or so. That's
an awfully long time in a rapidly evolving technological environemnt.
The vast majority of GUI libraries out there are constantly evolving.
With most of them not even a month goes by without a new version of
the library coming out.
Even when the GUI is an integral part of the language and/or the
environment where it's used (for example Apple's variant of
Objective-C and its UIKit library), it's usually continually
upgraded.
This is the main reason why the idea of a standard GUI library is
pretty unworkable for C++. It's actually better to leave it to
third-party libraries that are unbound by the strict admission
process of standardization. They can be upgraded at any time,
and mistakes can be corrected rapidly.
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
very, very slowly. The standard is updated every 5 years or so. That's
an awfully long time in a rapidly evolving technological environemnt.
The vast majority of GUI libraries out there are constantly evolving.
With most of them not even a month goes by without a new version of
the library coming out.
Even when the GUI is an integral part of the language and/or the
environment where it's used (for example Apple's variant of
Objective-C and its UIKit library), it's usually continually
upgraded.
This is the main reason why the idea of a standard GUI library is
pretty unworkable for C++. It's actually better to leave it to
third-party libraries that are unbound by the strict admission
process of standardization. They can be upgraded at any time,
and mistakes can be corrected rapidly.
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
jacob navia
Feb 2, 2015, 12:41:08 PM2/2/15
to
Le 02/02/2015 11:35, Juha Nieminen a écrit :
> Lynn McGuire <l...@winsim.com> wrote:
>> Now C++ needs a standard user interface library.
>
> The problem with a *standard* GUI library is that the standard evolves
> very, very slowly. The standard is updated every 5 years or so. That's
> an awfully long time in a rapidly evolving technological environemnt.
>
This is exactly the problem. Computer graphics is such a rapidly
> Lynn McGuire <l...@winsim.com> wrote:
>> Now C++ needs a standard user interface library.
>
> The problem with a *standard* GUI library is that the standard evolves
> very, very slowly. The standard is updated every 5 years or so. That's
> an awfully long time in a rapidly evolving technological environemnt.
>
evolving field that setting a fixed API for the whole language is
completely NONSENSE!
> The vast majority of GUI libraries out there are constantly evolving.
> With most of them not even a month goes by without a new version of
> the library coming out.
>
conceptual base for doing graphics changing. Even apparently simple
stuff like LineTo(x,y); can be quite difficult to do:
o Do you want dithering and pixel dithering using color? Or you want
no dithering, just black/white line?
o Do you want setting a MINIMUM width so that your line will be visible
in a retina display with 5400 x 4800? Or even when considering the
retina displays that will be available in 4 years with
10000 x 8000 ???
etc!
> Even when the GUI is an integral part of the language and/or the
> environment where it's used (for example Apple's variant of
> Objective-C and its UIKit library), it's usually continually
> upgraded.
>
there (see above) there are problems!
> This is the main reason why the idea of a standard GUI library is
> pretty unworkable for C++. It's actually better to leave it to
> third-party libraries that are unbound by the strict admission
> process of standardization. They can be upgraded at any time,
> and mistakes can be corrected rapidly.
>
jacob
Christopher Pisz
Feb 2, 2015, 1:03:20 PM2/2/15
to
On 1/30/2015 10:38 PM, Stefan Ram wrote:
> Christopher Pisz <nos...@notanaddress.com> writes:
>> .NET failed with WPF?
>
> Java failed with AWT, so they replaced it by Swing.
> Now, Swing also has failed. It had to be replaced by JavaFX.
>
> IIRC, WPF replaces WinForms, so WinForms also had failed.
>
> It is possible, that WPF and JavaFX will be replaced by
> something else in 5 - 10 years from now, as the history
> given above shows that GUI libraries tend to fail in
> Java-like languages and have to be replaced.
>
> GUI libraries for Java-like languages - a history of failure.
>
> However, a GUI library is different from a »Drawing Library«.
>
> C++ does not even have means to access directories of the
> file system or sockets via its standard library, which might
> be deemed more important than a drawing library by some.
> Also, a standard GUI interface would be helpful, which would
> include means to draw.
>
> »Drawing« is just outputting, while a GUI library also would
> read input from a user.
>
> We can draw with ASCII-Art for now, or output something like
> SVG or png.
>
Well, I guess I see it differently. I don't see anything used for years
and then dropped for a new technology as a failure. That's just the
nature of everything we program up. Technology evolves and we get
something new and better.
Graphics evolves faster and just like all the technologies mentioned, it
should be part of the "language" itself, it should be a standardized
library that you may or may not link with.
OpenGL was just that imo. Unfortunately, MS took measures to make it
difficult on Windows.
> Christopher Pisz <nos...@notanaddress.com> writes:
>> .NET failed with WPF?
>
> Java failed with AWT, so they replaced it by Swing.
> Now, Swing also has failed. It had to be replaced by JavaFX.
>
> IIRC, WPF replaces WinForms, so WinForms also had failed.
>
> It is possible, that WPF and JavaFX will be replaced by
> something else in 5 - 10 years from now, as the history
> given above shows that GUI libraries tend to fail in
> Java-like languages and have to be replaced.
>
> GUI libraries for Java-like languages - a history of failure.
>
> However, a GUI library is different from a »Drawing Library«.
>
> C++ does not even have means to access directories of the
> file system or sockets via its standard library, which might
> be deemed more important than a drawing library by some.
> Also, a standard GUI interface would be helpful, which would
> include means to draw.
>
> »Drawing« is just outputting, while a GUI library also would
> read input from a user.
>
> We can draw with ASCII-Art for now, or output something like
> SVG or png.
>
Well, I guess I see it differently. I don't see anything used for years
and then dropped for a new technology as a failure. That's just the
nature of everything we program up. Technology evolves and we get
something new and better.
Graphics evolves faster and just like all the technologies mentioned, it
should be part of the "language" itself, it should be a standardized
library that you may or may not link with.
OpenGL was just that imo. Unfortunately, MS took measures to make it
difficult on Windows.
Message has been deleted
Christopher Pisz
Feb 2, 2015, 1:12:14 PM2/2/15
to
"language" itself.
Typo. Sorry.
Message has been deleted
Christopher Pisz
Feb 2, 2015, 1:38:03 PM2/2/15
to
On 2/2/2015 12:14 PM, Stefan Ram wrote:
> Christopher Pisz <nos...@notanaddress.com> writes:
>> Well, I guess I see it differently. I don't see anything used for years
>> and then dropped for a new technology as a failure. That's just the
>> nature of everything we program up. Technology evolves and we get
>> something new and better.
>
> However, some interfaces manage to be kept. For example, we have
> Christopher Pisz <nos...@notanaddress.com> writes:
>> Well, I guess I see it differently. I don't see anything used for years
>> and then dropped for a new technology as a failure. That's just the
>> nature of everything we program up. Technology evolves and we get
>> something new and better.
>
> - according to TIOBE -:
>
> Programming Language 1990 1995 2000 2005 2010 2015
> C 1 2 1 1 2 1
> C++ 2 1 2 3 3 4
>
> That is, the interface »C« has managed to keep up with new
> developments and is still on top in 2015, while »C++«, the
> fad language of the 90s, slowly decays into oblivion.
>
Yea, TIOBE has been discussed countless times. I trust what it says as
much as a toothless hooker.
For a language that is "a fad language falling into oblivion" it sure is
ironic that I have never had to spend more than 4 hours searching for a
job to get employed using it, locally at that, with less than a 10
minute drive from home, and almost always with a salary increase of 15%
or more from the last employer, for the last 2 decades.
Message has been deleted
Bo Persson
Feb 2, 2015, 1:52:38 PM2/2/15
to
On 2015-02-02 19:14, Stefan Ram wrote:
> Christopher Pisz <nos...@notanaddress.com> writes:
>> Well, I guess I see it differently. I don't see anything used for years
>> and then dropped for a new technology as a failure. That's just the
>> nature of everything we program up. Technology evolves and we get
>> something new and better.
>
> Christopher Pisz <nos...@notanaddress.com> writes:
>> Well, I guess I see it differently. I don't see anything used for years
>> and then dropped for a new technology as a failure. That's just the
>> nature of everything we program up. Technology evolves and we get
>> something new and better.
>
> However, some interfaces manage to be kept. For example, we have
> - according to TIOBE -:
>
> Programming Language 1990 1995 2000 2005 2010 2015
> C 1 2 1 1 2 1
> C++ 2 1 2 3 3 4
>
> That is, the interface »C« has managed to keep up with new
> developments and is still on top in 2015, while »C++«, the
> fad language of the 90s, slowly decays into oblivion.
>
"Slowly" being the key word here?
> - according to TIOBE -:
>
> Programming Language 1990 1995 2000 2005 2010 2015
> C 1 2 1 1 2 1
> C++ 2 1 2 3 3 4
>
> That is, the interface »C« has managed to keep up with new
> developments and is still on top in 2015, while »C++«, the
> fad language of the 90s, slowly decays into oblivion.
>
The trend seems to be 1 position down every 10 years or so. Means it
will leave the top 20 chart within 150 years?
Also see that the new rising stars are COBOL, Assembly and Visual Basic.
That's the future for sure!
Bo Persson
Öö Tiib
Feb 2, 2015, 2:04:32 PM2/2/15
to
On Monday, 2 February 2015 20:47:01 UTC+2, Stefan Ram wrote:
> Christopher Pisz <nos...@notanaddress.com> writes:
> >Yea, TIOBE has been discussed countless times. I trust what it says as
> >much as a toothless hooker.
>
> For something that is so untrustworthy, it's funny that its
> Christopher Pisz <nos...@notanaddress.com> writes:
> >Yea, TIOBE has been discussed countless times. I trust what it says as
> >much as a toothless hooker.
>
> results are very similar to other independent sources.
>
> The Transparent Language Popularity Index
> lang-index.sourceforge.net/ (most recent)
>
> 1 C 17.668% 15.868% 16.825%
> 2 Java 14.720% 15.450% 20.381%
> 3 Objective-C 8.230% 8.516% 9.221%
> 4 C++ 6.770% 7.544% 7.912%
>
> TIOBE (2015-01)
>
> 1 1 C 16.703% -1.24%
> 2 2 Java 15.528% -1.00%
> 3 3 Objective-C 6.953% -4.14%
> 4 4 C++ 6.705% -0.86% 5 5
Software that users use most often is written in (or generated)
Javascript that is running in browser. Back-end is also sometimes
Javascript for example with NODE.js.
These skewed lists however always show it on 7-9th place.
Message has been deleted
Öö Tiib
Feb 2, 2015, 4:02:00 PM2/2/15
to
On Monday, 2 February 2015 21:18:58 UTC+2, Stefan Ram wrote:
> However, »The RedMonk Programming Language Rankings: January
> 2015« shows C++ ranked even lower than on TIOBE and
> sourceforge, on place 5. So, whereever one looks, C++ is
> dying.
:D I feel C++ is sitting very well. None of the major platform
vendors or otherwise powerhouses mentions it in public but all
that want to make something serious use it and pay well. Tools
are mostly free. The changes by C++11 and C++14 make achieving
efficiency and safety far more simple and natural than it was
with C++03. The "sanitizers" shipped with clang for Linuxes are
very helpful too. Dying. :D
> However, »The RedMonk Programming Language Rankings: January
> 2015« shows C++ ranked even lower than on TIOBE and
> sourceforge, on place 5. So, whereever one looks, C++ is
> dying.
:D I feel C++ is sitting very well. None of the major platform
vendors or otherwise powerhouses mentions it in public but all
that want to make something serious use it and pay well. Tools
are mostly free. The changes by C++11 and C++14 make achieving
efficiency and safety far more simple and natural than it was
with C++03. The "sanitizers" shipped with clang for Linuxes are
very helpful too. Dying. :D
jacob navia
Feb 2, 2015, 4:05:50 PM2/2/15
to
Le 02/02/2015 19:03, Stefan Ram a écrit :
> The resolution of the output device is an implementation
> detail not visible in the source code.
That's the theory.
Praxis:
PixelOn(x,y,color);
You can't do that?
Then there are people that will get mad, others will not care, etc.
> The resolution of the output device is an implementation
> detail not visible in the source code.
That's the theory.
Praxis:
PixelOn(x,y,color);
You can't do that?
Then there are people that will get mad, others will not care, etc.
Christopher Pisz
Feb 2, 2015, 4:07:56 PM2/2/15
to
On 2/2/2015 1:18 PM, Stefan Ram wrote:
>
> The gut feeling says that more people use and learn
> JavaScript today than C++.
> 2 Java, 3 PHP, 4 Python, 5 C#, 5 C++, 5 Ruby, 8 CSS, 9 C,
> 10 Objective-C, 11 Perl. 11 Shell. 13 R. 14 Scala,
> 15 Haskell, 16 Matlab, 17 Go, 17 Visual Basic, 19 Clojure,
> 19 Groovy.«
>
> The situation is very chaotic with »Visual Basic«, since
> Microsoft uses that term to refer to VB.net, while the rest
> of the world uses »VB.net« for »VB.net« and »VB« for classic VB.
> TIOBE does not seem to be aware of this problem.
>
> Also, Perl 5 and Perl 6 are two different languages, and
> one would like to see separate entries for them.
original point was that I don't think graphics is "part of any
language", but rather part of a library or framework that ships with the
tools for that language.
IMO OpenGL used to be just that. As far as I know, both Windows and
Linux both came with the libraries installed with their OSes and a C++
developer could readily use it. I believe it had a comittee of some sort
and they decided what to roll into it and how. I never was an OpenGL
guru, much less a novice though. I opted to go the DirectX route since I
was almost always on a Windows platform, plus MS made OpenGL a little
more difficult to use and made it unreasonable to use it on Windows.
Of course OpenGL was low level, and there were libraries built on top of
that for standard windows and the like.
I am not sure what the popularity of languages has to do with anything,
even if they were listed accurately.
> Öö Tiib <oot...@hot.ee> writes:
>> Javascript for example with NODE.js.
>> These skewed lists however always show it on 7-9th place.
>
> I agree that JavaScript is ranked too low!
>> Javascript for example with NODE.js.
>> These skewed lists however always show it on 7-9th place.
>
>
> The gut feeling says that more people use and learn
> JavaScript today than C++.
>
> »The RedMonk Programming Language Rankings: January 2015«
> shows another POV than TIOBE and sourcefore: »1 JavaScript,
> »The RedMonk Programming Language Rankings: January 2015«
> 2 Java, 3 PHP, 4 Python, 5 C#, 5 C++, 5 Ruby, 8 CSS, 9 C,
> 10 Objective-C, 11 Perl. 11 Shell. 13 R. 14 Scala,
> 15 Haskell, 16 Matlab, 17 Go, 17 Visual Basic, 19 Clojure,
> 19 Groovy.«
>
> The situation is very chaotic with »Visual Basic«, since
> Microsoft uses that term to refer to VB.net, while the rest
> of the world uses »VB.net« for »VB.net« and »VB« for classic VB.
> TIOBE does not seem to be aware of this problem.
>
> Also, Perl 5 and Perl 6 are two different languages, and
> one would like to see separate entries for them.
>
> However, »The RedMonk Programming Language Rankings: January
> 2015« shows C++ ranked even lower than on TIOBE and
> sourceforge, on place 5. So, whereever one looks, C++ is
> dying.
>
Well, regardless of what programming language people use more, my
> However, »The RedMonk Programming Language Rankings: January
> 2015« shows C++ ranked even lower than on TIOBE and
> sourceforge, on place 5. So, whereever one looks, C++ is
> dying.
>
original point was that I don't think graphics is "part of any
language", but rather part of a library or framework that ships with the
tools for that language.
IMO OpenGL used to be just that. As far as I know, both Windows and
Linux both came with the libraries installed with their OSes and a C++
developer could readily use it. I believe it had a comittee of some sort
and they decided what to roll into it and how. I never was an OpenGL
guru, much less a novice though. I opted to go the DirectX route since I
was almost always on a Windows platform, plus MS made OpenGL a little
more difficult to use and made it unreasonable to use it on Windows.
Of course OpenGL was low level, and there were libraries built on top of
that for standard windows and the like.
I am not sure what the popularity of languages has to do with anything,
even if they were listed accurately.
Ian Collins
Feb 2, 2015, 4:10:45 PM2/2/15
to
Stefan Ram wrote:
>
> However, »The RedMonk Programming Language Rankings: January
> 2015« shows C++ ranked even lower than on TIOBE and
> sourceforge, on place 5. So, whereever one looks, C++ is
> dying.
As they say on some well known beer adds in my part of the world "yeah
>
> However, »The RedMonk Programming Language Rankings: January
> 2015« shows C++ ranked even lower than on TIOBE and
> sourceforge, on place 5. So, whereever one looks, C++ is
> dying.
right!"
--
Ian Collins
Scott Lurndal
Feb 2, 2015, 4:19:34 PM2/2/15
to
Christopher Pisz <nos...@notanaddress.com> writes:
>
>IMO OpenGL used to be just that. As far as I know, both Windows and
>Linux both came with the libraries installed with their OSes and a C++
OpenGL started life as the proprietary Iris GL which was used
>
>IMO OpenGL used to be just that. As far as I know, both Windows and
>Linux both came with the libraries installed with their OSes and a C++
by SGI IRIX systems as a 3D graphics toolkit. As PC graphics
cards became more than toys, around 1998/1999; SGI read the
writing on the wall and realized that their expensive, proprietary
MIPS-based workstations (and how I loved my dual-head two processor R10K Octane!)
were soon to be eclipsed by PC's with PII/PIII and reasonably
good third-party graphics cards. SGI even built a Windows
PC in alignment with this strategy. Didn't keep them in the
workstation bidness, however. It was a fun place to work in
the 90's, that's for sure.
https://www.opengl.org/wiki/History_of_OpenGL
Message has been deleted
Scott Lurndal
Feb 2, 2015, 4:56:05 PM2/2/15
to
r...@zedat.fu-berlin.de (Stefan Ram) writes:
> proper, but of the C++ standard library.
>
> But the standard library of a language matters. It is the
> portable core, and I also use the library status to decide
> what I teach in my C++ courses: When the course is labeled
> »C++«, I teach the standard library, but I do not teach
> extension libraries.
>
> I deem the standard library to be part of the language, but
> not other extension libraries.
>
> In Java, JavaFX is part of the standard library of Java SE.
> So, I teach GUI programming in Java. Also sockets.
>
> In C++, there is no GUI library that is part of the
> standard library, so I do not teach GUI programming with
> C++, nor socket programming.
>
> In 2003, the Journal COTS reported that the military
> migrates away from Ada towards Java. The portable libraries
> of Java were recognized as an edge over C++.
>
> »Another advantage Java offers is a broad selection of
> standard, portable and scalable libraries. That's where
> it has an edge over C++. While C++ has some good
> libraries, they're not portable---one set of libraries
> is needed with Windows, a different set is needed for
> Solaris, and yet another for Linux.« -- Jeff Child
>
>http://www.cotsjournalonline.com/pdfs/2003/07/COTS07_softside.pdf
That URL is 404.
The idea of Java replacing ADA does lead to considerable
amusement, given the real-time nature of much ADA code.
Man findet sie zu schwer zu glauben.
>Christopher Pisz <nos...@notanaddress.com> writes:
>>Well, regardless of what programming language people use more, my
>>original point was that I don't think graphics is "part of any
>>language", but rather part of a library or framework that ships with the
>>tools for that language.
>
> »fopen«/»::std::ofstream« is not part of the C++ language
>>Well, regardless of what programming language people use more, my
>>original point was that I don't think graphics is "part of any
>>language", but rather part of a library or framework that ships with the
>>tools for that language.
>
> proper, but of the C++ standard library.
>
> But the standard library of a language matters. It is the
> portable core, and I also use the library status to decide
> what I teach in my C++ courses: When the course is labeled
> »C++«, I teach the standard library, but I do not teach
> extension libraries.
>
> I deem the standard library to be part of the language, but
> not other extension libraries.
>
> In Java, JavaFX is part of the standard library of Java SE.
> So, I teach GUI programming in Java. Also sockets.
>
> In C++, there is no GUI library that is part of the
> standard library, so I do not teach GUI programming with
> C++, nor socket programming.
>
> In 2003, the Journal COTS reported that the military
> migrates away from Ada towards Java. The portable libraries
> of Java were recognized as an edge over C++.
>
> »Another advantage Java offers is a broad selection of
> standard, portable and scalable libraries. That's where
> it has an edge over C++. While C++ has some good
> libraries, they're not portable---one set of libraries
> is needed with Windows, a different set is needed for
> Solaris, and yet another for Linux.« -- Jeff Child
>
>http://www.cotsjournalonline.com/pdfs/2003/07/COTS07_softside.pdf
That URL is 404.
The idea of Java replacing ADA does lead to considerable
amusement, given the real-time nature of much ADA code.
Man findet sie zu schwer zu glauben.
Chris Vine
Feb 2, 2015, 5:04:57 PM2/2/15
to
On 2 Feb 2015 19:18:44 GMT
Objective-C on your latest statistics, which happened to be above it in
the TIOBE index which you so enjoy. Anyone can produce particular
statistics of choice from a particular measure to prove anything they
want. You have a particular axe to grind, which you do repeatedly. I
doubt anyone gives much weight to what you think, whatever their views
on C++, C or Javascript.
The fact is that C++ has a particular target area in which it is
dominant and which is not going to go away for a long time, as also for
that matter do C and even FORTRAN. All the languages you mention have
areas where they are in the mainstream and areas where they are not.
Big deal.
Chris
> >Javascript for example with NODE.js.
> >These skewed lists however always show it on 7-9th place.
>
> >These skewed lists however always show it on 7-9th place.
>
> I agree that JavaScript is ranked too low!
>
> The gut feeling says that more people use and learn
> JavaScript today than C++.
>
>
> The gut feeling says that more people use and learn
> JavaScript today than C++.
>
> »The RedMonk Programming Language Rankings: January 2015«
> shows another POV than TIOBE and sourcefore: »1 JavaScript,
> 2 Java, 3 PHP, 4 Python, 5 C#, 5 C++, 5 Ruby, 8 CSS, 9 C,
> 10 Objective-C, 11 Perl. 11 Shell. 13 R. 14 Scala,
> 15 Haskell, 16 Matlab, 17 Go, 17 Visual Basic, 19 Clojure,
> 19 Groovy.«
>
> The situation is very chaotic with »Visual Basic«, since
> Microsoft uses that term to refer to VB.net, while the rest
> of the world uses »VB.net« for »VB.net« and »VB« for classic VB.
> TIOBE does not seem to be aware of this problem.
>
> Also, Perl 5 and Perl 6 are two different languages, and
> one would like to see separate entries for them.
>
> 2 Java, 3 PHP, 4 Python, 5 C#, 5 C++, 5 Ruby, 8 CSS, 9 C,
> 10 Objective-C, 11 Perl. 11 Shell. 13 R. 14 Scala,
> 15 Haskell, 16 Matlab, 17 Go, 17 Visual Basic, 19 Clojure,
> 19 Groovy.«
>
> The situation is very chaotic with »Visual Basic«, since
> Microsoft uses that term to refer to VB.net, while the rest
> of the world uses »VB.net« for »VB.net« and »VB« for classic VB.
> TIOBE does not seem to be aware of this problem.
>
> Also, Perl 5 and Perl 6 are two different languages, and
> one would like to see separate entries for them.
>
> However, »The RedMonk Programming Language Rankings: January
> 2015« shows C++ ranked even lower than on TIOBE and
> sourceforge, on place 5. So, whereever one looks, C++ is
> dying.
Yes, it's "dying" so badly that it is higher in rank than C and
> 2015« shows C++ ranked even lower than on TIOBE and
> sourceforge, on place 5. So, whereever one looks, C++ is
> dying.
Objective-C on your latest statistics, which happened to be above it in
the TIOBE index which you so enjoy. Anyone can produce particular
statistics of choice from a particular measure to prove anything they
want. You have a particular axe to grind, which you do repeatedly. I
doubt anyone gives much weight to what you think, whatever their views
on C++, C or Javascript.
The fact is that C++ has a particular target area in which it is
dominant and which is not going to go away for a long time, as also for
that matter do C and even FORTRAN. All the languages you mention have
areas where they are in the mainstream and areas where they are not.
Big deal.
Chris
Melzzzzz
Feb 2, 2015, 5:45:56 PM2/2/15
to
C++.
I only see Nim(rod) (it compiles to C,C++ and Obj-C and JS with
limitations, optional GC) as serous replacement for C++, so far, but it
is not 1.0, yet. Whoever likes python, perl that is ;)
There is also Rust (C syntax, no GC), but it is not stable yet (not
1.0).
So really there is no real alternative to C++, yet.
Melzzzzz
Feb 2, 2015, 5:55:37 PM2/2/15
to
On Mon, 02 Feb 2015 21:55:54 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
> >Christopher Pisz <nos...@notanaddress.com> writes:
> >>Well, regardless of what programming language people use more, my
> >>original point was that I don't think graphics is "part of any
> >>language", but rather part of a library or framework that ships
> >>with the tools for that language.
> >
> > _fopen_/_::std::ofstream_ is not part of the C++ language
sc...@slp53.sl.home (Scott Lurndal) wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
> >Christopher Pisz <nos...@notanaddress.com> writes:
> >>Well, regardless of what programming language people use more, my
> >>original point was that I don't think graphics is "part of any
> >>language", but rather part of a library or framework that ships
> >>with the tools for that language.
> >
> > proper, but of the C++ standard library.
> >
> > But the standard library of a language matters. It is the
> > portable core, and I also use the library status to decide
> > what I teach in my C++ courses: When the course is labeled
> > _C++_, I teach the standard library, but I do not teach
> >
> > But the standard library of a language matters. It is the
> > portable core, and I also use the library status to decide
> > what I teach in my C++ courses: When the course is labeled
> > extension libraries.
> >
> > I deem the standard library to be part of the language, but
> > not other extension libraries.
> >
> > In Java, JavaFX is part of the standard library of Java SE.
> > So, I teach GUI programming in Java. Also sockets.
> >
> > In C++, there is no GUI library that is part of the
> > standard library, so I do not teach GUI programming with
> > C++, nor socket programming.
> >
> > In 2003, the Journal COTS reported that the military
> > migrates away from Ada towards Java. The portable libraries
> > of Java were recognized as an edge over C++.
> >
> > _Another advantage Java offers is a broad selection of
> >
> > I deem the standard library to be part of the language, but
> > not other extension libraries.
> >
> > In Java, JavaFX is part of the standard library of Java SE.
> > So, I teach GUI programming in Java. Also sockets.
> >
> > In C++, there is no GUI library that is part of the
> > standard library, so I do not teach GUI programming with
> > C++, nor socket programming.
> >
> > In 2003, the Journal COTS reported that the military
> > migrates away from Ada towards Java. The portable libraries
> > of Java were recognized as an edge over C++.
> >
> > standard, portable and scalable libraries. That's where
> > it has an edge over C++. While C++ has some good
> > libraries, they're not portable---one set of libraries
> > is needed with Windows, a different set is needed for
> > Solaris, and yet another for Linux._ -- Jeff Child
> > it has an edge over C++. While C++ has some good
> > libraries, they're not portable---one set of libraries
> > is needed with Windows, a different set is needed for
> >
> >http://www.cotsjournalonline.com/pdfs/2003/07/COTS07_softside.pdf
>
> That URL is 404.
>
> The idea of Java replacing ADA does lead to considerable
> amusement, given the real-time nature of much ADA code.
>
Java has extremely good JIT compiler (written in C++).
> >http://www.cotsjournalonline.com/pdfs/2003/07/COTS07_softside.pdf
>
> That URL is 404.
>
> The idea of Java replacing ADA does lead to considerable
> amusement, given the real-time nature of much ADA code.
>
Robert Wessel
Feb 2, 2015, 8:04:18 PM2/2/15
to
Java?
Melzzzzz
Feb 2, 2015, 8:20:28 PM2/2/15
to
what are they doing, I guess...
Nobody
Feb 3, 2015, 6:44:33 AM2/3/15
to
On Mon, 02 Feb 2015 22:05:36 +0100, jacob navia wrote:
> Praxis:
>
> PixelOn(x,y,color);
>
> You can't do that?
Nope. The main problem is that it can't be implemented on anything which
> Praxis:
>
> PixelOn(x,y,color);
>
> You can't do that?
isn't based upon a rectangular grid of pixels.
That includes most printers, where pixels overlap (i.e. the spacing
between adjacent pixel centres is smaller than the area which is affected
by changing the pixel's intensity).
It also has issues with rendering systems with sub-pixel granularity (e.g.
MSAA and direct control of the R/G/B sub-pixels).
Cairo's rendering model is essentially the same as all other "modern" 2D
graphics APIs (PostScript/PDF, OpenVG, SVG, HTML5 canvas, XRender, etc).
I.e. floating-point coordinates with an arbitrary affine transformation,
paths constructed from cubic Bezier curves, Porter-Duff compositing.
As opposed to the 90's-era standard (X11, BGI) which revolved around
direct manipulation of the pixel grid: integer pixel coordinates, no
transformations, lines, circles, polygons, axis-aligned rectangles, image
blit with translation and integer scaling (no rotation), compositing
limited to bitwise operations (AND, OR, XOR, etc), no alpha blending.
Lynn McGuire
Feb 3, 2015, 5:06:24 PM2/3/15
to
to support it.
Lynn
peter koch
Feb 4, 2015, 7:32:23 AM2/4/15
to
I use WxWidgets because it is the best choice for me (I will not use QT because of licensing issues and fltk was simply to lowlevel (and visually ugly) for me). But I must say that the programming interface is very far from what I would expect a good C++ library to have. This is a deliberate choice from the Wxwidgets developers and probably related to history and a need to support ancient compilers. But it is also a very good reason to dismiss it as a candidate for standardisation.
/Peter
>
> Lynn
Lynn McGuire
Feb 7, 2015, 2:23:23 PM2/7/15
to
We are on Windows only right now. We use MFC for our main window and we
wrote our own UITK for our dialogs. We have several hundred dialogs
with extensively hand built controls and mannerisms.
Thanks,
Lynn
peter koch
Feb 7, 2015, 4:54:55 PM2/7/15
to
Den lørdag den 7. februar 2015 kl. 20.23.23 UTC+1 skrev Lynn McGuire:
> On 2/4/2015 6:32 AM, peter koch wrote:
> > Den tirsdag den 3. februar 2015 kl. 23.06.24 UTC+1 skrev Lynn McGuire:
[snip]
> On 2/4/2015 6:32 AM, peter koch wrote:
> > Den tirsdag den 3. februar 2015 kl. 23.06.24 UTC+1 skrev Lynn McGuire:
> >> I totally disagree. If https://www.wxwidgets.org/ was made a standard then all of the platform developers would at least attempt
> >> to support it.
> >
> > But there is also fltk and QT. And then there are all the nonportable libraries lying around.
> > I use WxWidgets because it is the best choice for me (I will not use QT because of licensing issues and fltk was simply to lowlevel (and visually ugly) for me). But I must say that the programming interface is very far from what I would expect a good C++ library to have. This is a deliberate choice from the Wxwidgets developers and probably related to history and a need to support ancient compilers. But it is also a very good reason to dismiss it as a candidate for standardisation.
> >
> > /Peter
>
> What platforms have you used WxWidgets on?
So far only Windows. But I expect to port to Linux soon.
> >> to support it.
> >
> > But there is also fltk and QT. And then there are all the nonportable libraries lying around.
> > I use WxWidgets because it is the best choice for me (I will not use QT because of licensing issues and fltk was simply to lowlevel (and visually ugly) for me). But I must say that the programming interface is very far from what I would expect a good C++ library to have. This is a deliberate choice from the Wxwidgets developers and probably related to history and a need to support ancient compilers. But it is also a very good reason to dismiss it as a candidate for standardisation.
> >
> > /Peter
>
> What platforms have you used WxWidgets on?
>
> We are on Windows only right now. We use MFC for our main window and we
> wrote our own UITK for our dialogs. We have several hundred dialogs
> with extensively hand built controls and mannerisms.
Okay? I do not know why you gave me that information.
> We are on Windows only right now. We use MFC for our main window and we
> wrote our own UITK for our dialogs. We have several hundred dialogs
> with extensively hand built controls and mannerisms.
/Peter
0 new messages