Will interest in C++ be revived after the Java fallout?

M

Michael Doubez

   [...]
C++ is not a portable programming language and any, non
trivial, program will only work on the system is was
designed to work on.
That's not been my experience.  I've moved several large (500
KLoc or more) applications from Windows or Solaris to Linux,
with no real problems.  Given the way the language has evolved,
it's often been more work to move to a more recent version of
the compiler than to move from Windows to Unix.
Even a very basic windows winmain function and messsage loop cannot be
ported, your lucky if it runs on your version of windows nvm Linux.
What's a windows winmain function?  I've never seen one.
Standard entry point function for a windows process.
It's certainly not standard, and I've never seen it used.
   [...]
I can't think of any programs that requires no user input
User input is often, if not always, from a file.
A lot of Windows "applications" are plugins (e.g. to Excel).  In
which case, there isn't really any entry point; they're DLL's,
which require some sort of registration (not just system
dependent, but application dependent) with the hosting
application.
Interestingly enough, you can port such programs to another
system, provided you can find an application which can host it.

Windows DLL's still have entry point functions namely DLLMain.

From the context, I would say they were talking about program entry
point (which is unique in most cases today). For plugin, the entry
points are just some transient callback. Unless you want to execute a
whole application in a dynamic load call; which is not practical
since, the context is then constrained, by example, you can load a
library in a DllMain (I don't know if this applies to threads started
from this point).
They may be similar across OS's, but the loading/registration process and
function signatures all create a different program structure that cannot be
ported.
Here is a *very* simple winodws DLL program (at bottom of page). Please tell
me how it is possible to make this code portable.http://msdn.microsoft.com/en-us/library/ms682583.aspx

I don't see your point here. The dynamic load process can be
abstracted away and I have done so on many occasions.

IIRC examples are the Boost.Plugin library or DynObj (I don't known
the state of those project nowadays) .
 
Ö

Öö Tiib

:)

But I wasn't really thinking of using the internet.  Just doing
all of the calculations in a C++ program, which acts like an
HTTP server (on the local machine).  But graphic applications
are probably an exception---you might want a native GUI for
those.  

GUI is needed anywhere if amount of data is serious enough and user
wants to configure his view to that data on the fly. Just imagine
browser-based IDE.
I'm not sure: I don't know what the possibilities for
displaying graphics are in a browser. But I can easily imagine
that for quality graphics, you want to be able to control each
pixel yourself.

Raster graphics are mostly fine. It was before when different browsers
did produce different images from same png file. Vector graphics are
still a mess. SVG is still not supported by IE8, MS claims that they
are working on SVG support in IE9. Thanks to cell-phone browsers it
(SVG) will be still unsupported on lot of platforms. HTML5 has canvas
on what you can draw on the fly. It is raster canvas so once shape is
drawn you have to draw it again to configure the view. Flash has
similar portability difficulties with SVG. I think that if you really
need dynamic graphics in more or less portable manner then you
probably need to spit on the browsers and take good old things like
OpenGL or LaTeX.
 Similarly for quality typesetting.  But who
expects quality typesetting for text today?  And what GUI
program gives it?  And for that matter, how many users would
even accept it: it certainly wouldn't have the "look and feel"
of other applications on the system.

Ok ... but some formula should look like a formula for some field
engineer or scientist anyway? That they certainly expect and accept.
 
I

Ian Collins

GUI is needed anywhere if amount of data is serious enough and user
wants to configure his view to that data on the fly. Just imagine
browser-based IDE.

I'd bet on browser-based IDEs being the norm before too long. After
all, who would have thought Java based IDEs would be so popular now?

:)
 
P

Paul

[...]
C++ is not a portable programming language and any, non
trivial, program will only work on the system is was
designed to work on.
That's not been my experience. I've moved several large (500
KLoc or more) applications from Windows or Solaris to Linux,
with no real problems. Given the way the language has evolved,
it's often been more work to move to a more recent version of
the compiler than to move from Windows to Unix.
Even a very basic windows winmain function and messsage loop cannot
be
ported, your lucky if it runs on your version of windows nvm Linux.
What's a windows winmain function? I've never seen one.
Standard entry point function for a windows process.
It's certainly not standard, and I've never seen it used.
[...]
I can't think of any programs that requires no user input
User input is often, if not always, from a file.
A lot of Windows "applications" are plugins (e.g. to Excel). In
which case, there isn't really any entry point; they're DLL's,
which require some sort of registration (not just system
dependent, but application dependent) with the hosting
application.
Interestingly enough, you can port such programs to another
system, provided you can find an application which can host it.

Windows DLL's still have entry point functions namely DLLMain.

From the context, I would say they were talking about program entry
point (which is unique in most cases today). For plugin, the entry
points are just some transient callback. Unless you want to execute a
whole application in a dynamic load call; which is not practical
since, the context is then constrained, by example, you can load a
library in a DllMain (I don't know if this applies to threads started
from this point).
......................................................................................................

I think it's quite clear what he is talking about when he says this.."there
isn't really any entry point; they're DLL's, which require some sort of ..."

If you load an Exe you create a new process this is different from loading a
DLL. Although threads are like a mini-process, a process runs in ints own
memory space and has ownership of threads.
threads created in dll's are also owned by the calling process.
I don't know what you mean by a plug-in, I only know of browser plug-ins.


They may be similar across OS's, but the loading/registration process and
function signatures all create a different program structure that cannot
be
ported.
Here is a *very* simple winodws DLL program (at bottom of page). Please
tell
me how it is possible to make this code
portable.http://msdn.microsoft.com/en-us/library/ms682583.aspx

I don't see your point here. The dynamic load process can be
abstracted away and I have done so on many occasions.

IIRC examples are the Boost.Plugin library or DynObj (I don't known
the state of those project nowadays) .

..........................................................................................................

Using a DLL in itself makes code portable(across applications). To make this
code portable across platform you need to isolate the code that is not
imp-specfic and copy/paste that code into a different program structure.

For example:

returnType winDLL(args){
//non portable code
//portable code copyable into Linux DLL
}

returnType nixDLL(args){
//non portable code
//portable code copyable into windows DLL
}


You need to create 2 different DLL's and compile them on their respective
machines.
I don't know if any compiler/linkers have some support for building a Linux
DLL on a windows machine or vice versa.
I don't think this can be abstracted away at programmer level.
 
N

Nick Keighley

It is i think sort of self-defense of developers. Imagine several
hours of data measured from a patient with various instruments 100
times per second. Medic who has to analyze it expects the user
interface to do complex scientific analysis over that data snip and
snip and curses the "slow" and "crappy" software. Now you put that
data into some mainframe, do the analysis there and pass the results
to user as jpg or png into browser. Outcome is not actually quicker.
It is even slower if to measure. However ... for medic everything is
suddenly OK ... internet is expected to be slow and non-
responsive. ;)

nice. What if you don't have a mainframe handy? Not everywhere has
fast internet access.
 
N

Nick Keighley

:)

But I wasn't really thinking of using the internet.  Just doing
all of the calculations in a C++ program, which acts like an
HTTP server (on the local machine).  But graphic applications
are probably an exception---you might want a native GUI for
those.  I'm not sure: I don't know what the possibilities for
displaying graphics are in a browser.

I was wondering that. Are the games people serving HTML much?
 But I can easily imagine
that for quality graphics, you want to be able to control each
pixel yourself.  Similarly for quality typesetting.  But who
expects quality typesetting for text today?  And what GUI
program gives it?  And for that matter, how many users would
even accept it: it certainly wouldn't have the "look and feel"
of other applications on the system.

perhaps you don't care. Perhaps the system doesn't have any other
applications.
 
Ö

Öö Tiib

nice. What if you don't have a mainframe handy? Not everywhere has
fast internet access.

If they do not have money then they can not pay for software that does
analyze their data anyway. Then i suggest them to download open office
and use spreadsheet there. Or what else i can do without budget?
 
N

Nick Keighley

If they do not have money then they can not pay for software that does
analyze their data anyway. Then i suggest them to download open office
and use spreadsheet there. Or what else i can do without budget?

no really your view of the world is limited.
 
J

James Kanze

On 01/29/11 11:05 AM, Tiib wrote:

[...]
I'd bet on browser-based IDEs being the norm before too long. After
all, who would have thought Java based IDEs would be so popular now?

Who would have thought that IDEs, period, would be the norm.
They certainly don't correspond to any reasonable way of
developing software. :)

An editor is clearly an exception; an editor needs to manage the
GUI itself, and probably can't go through a browser. But most
applications aren't editors---and most applications don't use
a GUI.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top