Friday, November 25, 2022

Digest for comp.lang.c++@googlegroups.com - 13 updates in 5 topics

Lynn McGuire <lynnmcguire5@gmail.com>: Nov 24 11:06PM -0600

On 11/24/2022 7:28 AM, JRR wrote:
> using things like OO, polymorphism and features of the C++ stdlib took
> the authors much more time than the simple translation from Fortran77 to
> C(++).
 
Interesting. Are there any public writeups to the experiences ?
 
I wonder if the problems were due to a lack of familiarity with C++ or
the fact that C++ has a much larger toolset than Fortran does.
 
Thanks,
Lynn
Lynn McGuire <lynnmcguire5@gmail.com>: Nov 24 11:38PM -0600

On 11/24/2022 9:00 AM, Thomas Koenig wrote:
 
> Which begs the question - why not introduce the OO featues that
> modern Fortran can do, without first converting to the common
> subset of C and C++?
 
The problem that I have run into in modern Fortran is that there is not
a good IDE (interactive development environment) on Windows. Since we
do not have any current customers on Unix / Linux, I do not know about
those platforms.
 
I tried Simply Fortran using GCC and GFortran and was very unsatisfied
with the debugger, we need to be able to stop at the 459th call to a
certain method. I tried Visual Studio 2019 with Intel Fortran and
Visual C++ and was very unhappy with the poor integration of Intel
Fortran into the IDE.
 
I like the modern features that C++ offers such as polymorphism but I am
very happy with the fact that C++ is a better compiler than C. I do
happen to use polymorphism in some of our common methods (pow, abs,
writing to an output file, etc) but it is a matter of convenience rather
than a goal of the project.
 
I will report next when I get my small data analysis tool running if
anyone is interested.
 
Thanks,
Lynn
Gary Scott <garylscott@sbcglobal.net>: Nov 25 10:13AM -0600

On 11/24/2022 11:38 PM, Lynn McGuire wrote:
> certain method.  I tried Visual Studio 2019 with Intel Fortran and
> Visual C++ and was very unhappy with the poor integration of Intel
> Fortran into the IDE.
 
VS on windows is the premier option. When the IVF integration works, it
is pretty good. What I've found though is that the integration breaks
frequently. In my case at present, it is broken and I can't seem to get
it repaired. The repair mechanism/upgrades think it is already
integrated when it isn't. So the help integration works, but the IDE
doesn't recognize the existing solutions (VS 2019) that worked a few
months ago. Very frustrating. I'll probably have to
uninstall/reinstall VS and then reinstall IVF in order to fix the
problem. It stopped working when VS installed one of it's own updates.
 
 
Lynn McGuire <lynnmcguire5@gmail.com>: Nov 25 01:58PM -0600

On 11/25/2022 10:13 AM, Gary Scott wrote:
>> anyone is interested.
 
>> Thanks,
>> Lynn
 
Unfortunately, Microsoft does not care about Fortran. They showed that
many years ago when they dropped Powerstation. I do not know why Visual
Studio does not work with Intel Fortran more but it is disappointing.
We use Visual C++ 2015 to build our Windows user interface with 450,000
lines of C++ code. It works extremely well for us even though our code
dates back to Windows 1.0.
 
The only thing that I know to do at this time is to move my Fortran code
to a Microsoft supported language. After all, there is some evidence
floating about that Microsoft is getting ready to follow Apple, once
more, and jump to the ARM cpus and leave Intel behind.
 
Thanks,
Lynn
Muttley@dastardlyhq.com: Nov 25 10:14AM

On Wed, 23 Nov 2022 13:27:30 +0100
>Am 23.11.2022 um 09:15 schrieb Muttley@dastardlyhq.com:
 
>> [snip usual Bonita mess]
 
>If that is a mess for you this is rather a statement about you.
 
Indeed it does. It says I like tidy, readable code that doesn't look like it was
written by a drunk cat walking around the keyboard.
 
>> Thank god you didn't write task manager.
 
>It would be much more safe and efficient - for no practical reason.
 
Your modesty matches your coding skills.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 25 11:57AM +0100


> Indeed it does. It says I like tidy, readable code that doesn't
> look like it was written by a drunk cat walking around the keyboard.
 
I understand C++, you don't.
Muttley@dastardlyhq.com: Nov 25 03:42PM

On Fri, 25 Nov 2022 11:57:19 +0100
 
>> Indeed it does. It says I like tidy, readable code that doesn't
>> look like it was written by a drunk cat walking around the keyboard.
 
>I understand C++, you don't.
 
Oh you are priceless :)
wij <wyniijj5@gmail.com>: Nov 25 04:40AM -0800

Basic proof (using C-like notation):
Define: bool S(Prog,Arg): S(c,n)==true iff ∃c(x), |x|<=|n|, c(x) returns true in P-time.
 
S is a language interpreter. Prog and Arg are pass-by-value arguments. E.g.
scripts, TM description, CNF evaluator,... and their possible solutions for
Prog to check.
 
From definition of S, S computes a problem in ℕℙ.
If Problem(S)∈ℙ, there exists a P-time Prog f defined as follow:
bool f(Arg x) {
return !S(f,x);
}
 
From Liar's paradox and the HP proof, f is an undecidable case for S. And, f and
S cannot both be in the same P-time convertible set. Therefore, ℙ≠ℕℙ.
QED.
 
Prog f exists in various forms, shown as a 'function' to make the basic proof
succinct by avoiding lots of symbol/definition/axiom/lemma...coding issues stuff.
If the above is correct, then, we change to use 'executable' to demonstrate,
because 'executable' is easier to understand and VERIFIABLE by real TM.
 
Executable: S2 <prog> <uint>
Definition: The exit status of "S2 <prog> <uint>" is 1 iff there exists an
"p x" instance, where x<=n, and the exit status of "p x" is 1.
 
// From the spec, S2 can be built in this C program (error checks are omitted).
//
int main(int argc, char* argv[]) { // main() takes exactly two arguments
const char* FuncName= argv[1]; // argv[1] is <prog>
const UInt MaxN= atoi(argv[2]); // convert argv[2] to UInt
 
for(Uint x=0; x<=MaxN; ++n) {
const char* cmd= make_cmd(FuncName,x); // make command string for system(..)
if(system(cmd)==1) { // exec: S2(f,x)
return 1;
}
}
return 0;
}
 
// As S2 exists, an executable f2 can be built in this C program (error checks are omitted).
//
int main(int argc, char* argv[]) {
const char* cmd= make_cmd("S2 f2 ", argv[1]); // make command string for system(..)
return !system(cmd); // exec: S2(f,n)
}
 
// After S2 and f2 are built, test with "S2 f2 8"
[] S2 f2 8 // execute from terminal
...
Aborted (core dumped) // infinite recursive call (expression of undecidable)
 
----------------
I am not familiar with complexity theory. For such a proof to be really
convincing, one needs to explain existing ℕℙℂ examples as a double check and
possibly some others I may be unaware of. So, I should stop here and ask
question for possible flaws of this basic proof.
 
I'd like to know C++ programer's idea for such proof. If you insist a "C++"
question. You can say , e.g. "Confirmed, C++ program has no way to prove N==NP"
Richard Damon <Richard@Damon-Family.org>: Nov 24 06:49PM -0500

On 11/24/22 12:18 PM, Bonita Montero wrote:
> assume that nearly everyone doesn't do that also.
 
>> Why use the WRONG type, when the right type exists.
 
> size_t fits here and I will never run into troubles with that
 
Your choice.
 
Note, That also means you need to be careful about ports to DSPs that
decide to use extended pointers to handle character addressing.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 25 04:32AM +0100

Am 25.11.2022 um 00:49 schrieb Richard Damon:
 
> Note, That also means you need to be careful about ports to DSPs
> that decide to use extended pointers to handle character addressing.
 
These DSPs don't need portable code anyway.
Richard Damon <Richard@Damon-Family.org>: Nov 24 10:45PM -0500

On 11/24/22 10:32 PM, Bonita Montero wrote:
 
>> Note, That also means you need to be careful about ports to DSPs
>> that decide to use extended pointers to handle character addressing.
 
> These DSPs don't need portable code anyway.
 
SOME of the code will be specific for them, but other, typically
non-time critical code could well want to be portable.
 
You never really know what code might want to be ported to what
architectures in the future. Intentionally making it non-portable
without reason just adds to the technical debt in the code.
"Öö Tiib" <ootiib@hot.ee>: Nov 24 11:46PM -0800

On Friday, 25 November 2022 at 05:45:24 UTC+2, Richard Damon wrote:
 
> You never really know what code might want to be ported to what
> architectures in the future. Intentionally making it non-portable
> without reason just adds to the technical debt in the code.
 
Comparing texts sounds like some kind of text configuration reading
or receiving requests with text-based protocol. So if it is time-critical
then it should be replaced with some more compact binary like
flatbuffers or such anyway.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 25 04:31AM +0100

Am 24.11.2022 um 19:24 schrieb Andrey Tarasevich:
 
> I would, because of my taste that whenever possible, loops should
> support plain `continue`, i.e. immediate `continue` should not break
> iteration logic.
 
You're compulsive.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)