On 27.01.2024 18:24, Scott Lurndal wrote:
Janis Papanagnou <[email protected]> writes:
As someone who as programmed daily in C++ since 1989, usually
I started C++ around the same time, actually since C++'s beginning,
so probably only few years earlier. But today I use C++ only in my
private context since, professionally, I'm not programming any more.
in performance sensitive code, I've never found the C++ input
and output operators useful.
I'm sure whether one finds a language (or features of a language)
useful certainly depends on various factors; education, the area
of work, the specific company (including its culture), and own
personality (own experiences, and personal background, where from
one comes).
This is why I think it makes no sense to start a dispute here.
Either you have experienced the advantages, or you haven't, or only
partly.
The run-time cost both in space
and time is far more than the *printf formatting functions,
and they're less flexible when the formatting changes based,
e.g., on locale.
Runtime costs and memory space considerations had been relevant
in my DSP assembler deep-space-satellite-communication project
(in the late 1980's).
In my C++ projects it was irrelevant whether language feature A
was 10% faster or slower compared to language feature B. There
were other factors that influenced performance; like complexity
of the algorithmic solutions. And there were other requirements
that had precedence anyway; like robust and extensible designs.
Amongst many other things.
So all I can do, if you like - but I don't know whether it helps
you, since your experiences and background certainly differs -,
is to illustrate it with a small project where specifically the
feature of discussion helped to a clear and extensible design,
simply to use and integrate; a flexibility and robust solution.
In C++ I implemented an Application Management Interface - that was
already 30 years ago, before Java provided some library like that -
that made it possible to control any object instance in a software
component by (informally written) "interface.register(item)", and
you could then interrogate or change state of such registered items asynchronously during runtime by exchanging the de-/linearized data
through some text oriented IPC channel. There was no need to adjust
application logic and no functional dependencies. It was transparent
WRT the type of object (it could be, say, a primitive 'int' counter
or a complex 'Car' object); items of any complexity and type could
be controlled through any stream based communication interface. The
only precondition was that the object class provides operators '<<'
and '>>' for de-/serialization (and these operators were anyway
defined in our contexts, for obvious reasons), and (IIRC) that it
had the property "controllable" (an interface derivation). Thanks
to OO principles and (beside other features) C++'s '<<' operator.
(I don't want to imagine such functionality with printf and all
it's impact to the rest of the program system.)
Java (as a newer language) has also some advantages, but was in many
respects far behind C++ (IMO).
Wow, that's a strong statement. What led you to hold that opinion?
Experience with many programming languages (including Java), and
a pair of open eyes, and an open mind.
Java, as a language, was rather well designed.
(It would have never occurred to me to to make such a statement.)
The run-time costs,
however, precluded the use of Java in most of the projects that I've
worked on since Java was introduced.
This is just one observation. But, yes.
Janis
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)