Friday, September 30, 2022

Digest for comp.lang.c++@googlegroups.com - 6 updates in 2 topics

Lynn McGuire <lynnmcguire5@gmail.com>: Sep 30 01:32PM -0500

On 9/30/2022 12:05 AM, James Kuyper wrote:
> examining the macro definitions. However, if any of those three is an
> ordinary function, it seems to me that this statement does unnecessarily
> use the comma operator.
 
hkl and f_calc are two dimensioned arrayed objects.
 
Thanks,
Lynn
Lynn McGuire <lynnmcguire5@gmail.com>: Sep 30 01:53PM -0500

On 9/30/2022 10:16 AM, Scott Lurndal wrote:
 
> The write here is an analog of the fortran write,
 
> WRITE unit,format,iolist
 
> And yes, it will conflict with the Unix (and POSIX) write function signature.
 
Yes, the Fortran write is "WRITE (unit, format) var1, var2, var3, etc..."
https://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vnbs/index.html
 
And yes, I am wondering if I will have to use the abhorrent "using
namespace fem;" statement to make sure that I get the correct write
function (which is no guarantee at all). Or, if I will have to use
"fem::write".
 
Thanks,
Lynn
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 30 12:41PM -0700

> Is this C++ statement using the comma operator ?
 
> write(6, "(3(1x,i3),1x,f12.6,1x,f12.6)"), hkl(1, i), hkl(2, i),
> hkl(3, i), f_calc(1, i), f_calc(2, i);
 
Yes, five of them, easily seen by reformatting the code:
 
write(6, "(3(1x,i3),1x,f12.6,1x,f12.6)"),
hkl(1, i),
hkl(2, i),
hkl(3, i),
f_calc(1, i),
f_calc(2, i);
 
Assuming there's no macro funny business going on, that's 6 function
calls (or macro invocations?) separated by comma operators. (The commas
separating function arguments are of course not comma operators.)
 
Replacing the comma at the end of each line by a semicolon (and possibly
surrounding the whole thing with curly braces) yields equivalent code.
The braces are needed if the context is something like:
 
if (condition)
write(6, "(3(1x,i3),1x,f12.6,1x,f12.6)"), hkl(1, i), hkl(2, i),
hkl(3, i), f_calc(1, i), f_calc(2, i);
 
Things might change if any of write, hkl, and f_calc is a macro. If
they're well behaved macros, it shouldn't matter.
 
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
Gawr Gura <gawrgura@mail.hololive.com>: Sep 30 01:17PM -0700

> namespace fem;" statement to make sure that I get the correct write
> function (which is no guarantee at all).  Or, if I will have to use
> "fem::write".
 
The write symbol in the example program is an object of the type
fem::common_writer (you can see the declaration on line 70). Obviously,
you will have to name the type explicitly, provide a using declaration,
or rely on type inference when you declare a value of that type. write
is just the name of the object though so you could call it anything you
like. Perhaps:
 
fem::common_writer gregory(cmn);
 
or
 
fem::common_writer louise(cmn);
 
If you want to be able to use the POSIX write function in the same
program you could get it with ::write rather than just write.
Manfred <noname@add.invalid>: Oct 01 01:03AM +0200

On 9/30/2022 7:05 AM, James Kuyper wrote:
> examining the macro definitions. However, if any of those three is an
> ordinary function, it seems to me that this statement does unnecessarily
> use the comma operator.
 
"unnecessarily" is not necessarily true here: others have mentioned an
overloaded comma operator.
/If/ this is what is actually going on here, then you might need to keep
the sequence of commas in place, or go through some nontrivial rewrite.
Jivanmukta <jivanmukta@poczta.onet.pl>: Sep 30 09:05PM +0200

W dniu 30.09.2022 o 09:12, Juha Nieminen pisze:
 
> That's completely normal. Just because it seems to "work fine" that
> doesn't mean there isn't a problem (it just so happens that it isn't
> crashing in that particular situation).
 
I run my program from prompt and with debugger using the same arguments
and input data.
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.

No comments: