How come I cannot do this in argument arrays in C++ ?
int sicmct (const longint nprint, longint nprara [nprint])
longint is just a long long.
Lynn McGuire <lynnmcguire5@gmail.com> writes:
How come I cannot do this in argument arrays in C++ ?
int sicmct (const longint nprint, longint nprara [nprint])
Because C++ does not support variable-length array types.
longint is just a long long.
Just an observation: that's a really poorly chosen name. I would
have assumed that "longint" means "long int" (and wondered why
the code doesn't just use "long int" or "long" directly). I don't necessarily object to having at typedef for long long, but its name
should be meaningful.
On 5/21/2026 7:39 PM, Keith Thompson wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
How come I cannot do this in argument arrays in C++ ?
int sicmct (const longint nprint, longint nprara [nprint])
Because C++ does not support variable-length array types.
longint is just a long long.
Just an observation: that's a really poorly chosen name. I would
have assumed that "longint" means "long int" (and wondered why
the code doesn't just use "long int" or "long" directly). I don't
necessarily object to having at typedef for long long, but its name
should be meaningful.
So, to get the length of the array passed to a debugger, I would need
to use std::array or std::vector?
F2C chose that longint name for me and I was too lazy to change it.
It is a distinctive name which I like.
Yup, you are correct, it is a typedef.
typedef long long longint;
Lynn McGuire <lynnmcguire5@gmail.com> writes:
On 5/21/2026 7:39 PM, Keith Thompson wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
How come I cannot do this in argument arrays in C++ ?
int sicmct (const longint nprint, longint nprara [nprint])
Because C++ does not support variable-length array types.
longint is just a long long.
Just an observation: that's a really poorly chosen name. I would
have assumed that "longint" means "long int" (and wondered why
the code doesn't just use "long int" or "long" directly). I don't
necessarily object to having at typedef for long long, but its name
should be meaningful.
So, to get the length of the array passed to a debugger, I would need
to use std::array or std::vector?
The length of a std::array has to be a constant expression.
std::vector is likely to be a good choice for this kind of thing,
but obviously Fortran doesn't have std::vector.
You could also (in either C or C++) do something like
int sicmct(const longint len, longint *nprara)
and rely on the caller to ensure that nprara points to the first
element of an array with at least len elements.
As I understand it, f2c generates C code by default. It has a
"-C++" option to tell it to generate C++ code. Presumably it
wouldn't generate the above code with the "-C++" option.
Can you (briefly) show the Fortran code that you fed to f2c?
How does the "-C++" option affect the generated code?
F2C chose that longint name for me and I was too lazy to change it.
It is a distinctive name which I like.
Yup, you are correct, it is a typedef.
typedef long long longint;
Style issues are less important in machine-generated code -- unless
the generated code is intended to be maintained. Is it intended to
match some Fortran type?
Lynn McGuire <lynnmcguire5@gmail.com> writes:
On 5/21/2026 7:39 PM, Keith Thompson wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
How come I cannot do this in argument arrays in C++ ?
int sicmct (const longint nprint, longint nprara [nprint])
Because C++ does not support variable-length array types.
longint is just a long long.
Just an observation: that's a really poorly chosen name. I would
have assumed that "longint" means "long int" (and wondered why
the code doesn't just use "long int" or "long" directly). I don't
necessarily object to having at typedef for long long, but its name
should be meaningful.
So, to get the length of the array passed to a debugger, I would need
to use std::array or std::vector?
The length of a std::array has to be a constant expression.
std::vector is likely to be a good choice for this kind of thing,
but obviously Fortran doesn't have std::vector.
You could also (in either C or C++) do something like
int sicmct(const longint len, longint *nprara)
and rely on the caller to ensure that nprara points to the first
element of an array with at least len elements.
As I understand it, f2c generates C code by default. It has a
"-C++" option to tell it to generate C++ code. Presumably it
wouldn't generate the above code with the "-C++" option.
Can you (briefly) show the Fortran code that you fed to f2c?
How does the "-C++" option affect the generated code?
Because C++ does not support variable-length array types.
Just an observation: that's a really poorly chosen name. ...
Lynn McGuire <lynnmcguire5@gmail.com> writes:
How come I cannot do this in argument arrays in C++ ?
int sicmct (const longint nprint, longint nprara [nprint])
Because C++ does not support variable-length array types.
On 5/21/2026 7:39 PM, Keith Thompson wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
How come I cannot do this in argument arrays in C++ ?
int sicmct (const longint nprint, longint nprara [nprint])
Because C++ does not support variable-length array types.
longint is just a long long.
Just an observation: that's a really poorly chosen name. I would
have assumed that "longint" means "long int" (and wondered why
the code doesn't just use "long int" or "long" directly). I don't
necessarily object to having at typedef for long long, but its name
should be meaningful.
So, to get the length of the array passed to a debugger, I would need to
use std::array or std::vector?
F2C chose that longint name for me and I was too lazy to change it. It
is a distinctive name which I like.
Yup, you are correct, it is a typedef.
typedef long long longint;
Lynn McGuire <lynnmcguire5@gmail.com> writes:
On 5/21/2026 7:39 PM, Keith Thompson wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
How come I cannot do this in argument arrays in C++ ?
int sicmct (const longint nprint, longint nprara [nprint])
Because C++ does not support variable-length array types.
longint is just a long long.
Just an observation: that's a really poorly chosen name. I would
have assumed that "longint" means "long int" (and wondered why
the code doesn't just use "long int" or "long" directly). I don't
necessarily object to having at typedef for long long, but its name
should be meaningful.
So, to get the length of the array passed to a debugger, I would need to
use std::array or std::vector?
Surely the length of the array is 'nprint', so 'simmct' (a rather poor
name choice) already knows the length of the array.
On 5/22/2026 9:14 AM, Scott Lurndal wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
On 5/21/2026 7:39 PM, Keith Thompson wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
How come I cannot do this in argument arrays in C++ ?
int sicmct (const longint nprint, longint nprara [nprint])
Because C++ does not support variable-length array types.
longint is just a long long.
Just an observation: that's a really poorly chosen name. I would
have assumed that "longint" means "long int" (and wondered why
the code doesn't just use "long int" or "long" directly). I don't
necessarily object to having at typedef for long long, but its name
should be meaningful.
So, to get the length of the array passed to a debugger, I would need to >>> use std::array or std::vector?
Surely the length of the array is 'nprint', so 'simmct' (a rather poor
name choice) already knows the length of the array.
Simmct was named back in 1975 or so when we
did our software development
on the Univac 1108 at University Computing Company (UCC). All variables
and subroutine names in Fortran were limited to 6 upper case characters
at that time.
Because, the Univac was a 36 bit, 6 bit byte machine.
Simmct was named back in 1975 or so when we
When you were 14?
did our software development
on the Univac 1108 at University Computing Company (UCC). All variables
and subroutine names in Fortran were limited to 6 upper case characters
at that time.
That was, of course a half century ago. The state of the art has
progressed somewhat since then, including limits on identifier sizes.
If you're rewriting in a new language. a simple global search and
replace will easily update those six-character names to something
that actually aids readability rather than obscuring it.
Because, the Univac was a 36 bit, 6 bit byte machine.
Indeed, I worked for the company that still produces and
supports the Sperry 2200 systems for more than a decade
(albeit on the Burroughs side of Unisys).
The actual reason that the Fortran compiler supported only
six uppercase letter&digit identifiers was because that
was what the Fortran IV standard (1966) required.
On 5/22/2026 4:11 PM, Scott Lurndal wrote:
...
Simmct was named back in 1975 or so when we
When you were 14?
did our software development
on the Univac 1108 at University Computing Company (UCC).ÿ All variables >>> and subroutine names in Fortran were limited to 6 upper case characters
at that time.
That was, of course a half century ago.ÿ The state of the art has
progressed somewhat since then, including limits on identifier sizes.
If you're rewriting in a new language. a simple global search and
replace will easily update those six-character names to something
that actually aids readability rather than obscuring it.
Because, the Univac was a 36 bit, 6 bit byte machine.
Indeed, I worked for the company that still produces and
supports the Sperry 2200 systems for more than a decade
(albeit on the Burroughs side of Unisys).
The actual reason that the Fortran compiler supported only
six uppercase letter&digit identifiers was because that
was what the Fortran IV standard (1966) required.
Par Janson wrote simmct.f in 1975, not me.ÿ There have been over a
hundred programmers of this software since 1965 or so.ÿ I started
learning Fortran in June of 1975 when I was 14, yes, as a key puncher
for SunFu Yang.
I have over 5,000 Fortran subroutines with 800,000 lines of code.ÿ The
last thing that I am going to do is willy nilly rename them all.
Continuity is a good thing.
My software is at version 16.27a, I am working on version 17.00 now.ÿ I
have the source code for every version going back to version 8.03.ÿ To
just rename everything would confuse things.
One needs to be careful in life.ÿ Conversion from Fortran to C++ is
enough of a change for today.
Lynn
Lynn McGuire <lynnmcguire5@gmail.com> writes:
How come I cannot do this in argument arrays in C++ ?
int sicmct (const longint nprint, longint nprara [nprint])
Because C++ does not support variable-length array types.
On 5/21/2026 7:39 PM, Keith Thompson wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
How come I cannot do this in argument arrays in C++ ?
int sicmct (const longint nprint, longint nprara [nprint])
Because C++ does not support variable-length array types.
So my C++ compiler likes
ÿÿ int sicmct (const longint nprint, longint nprara [96])
or
ÿÿ int sicmct (const longint nprint, longint nprara [])
So I guess that anything else is classified as variable that is not
typed as const int and initialized.
Lynn
On 5/27/2026 5:08 PM, Lynn McGuire wrote:
On 5/21/2026 7:39 PM, Keith Thompson wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
How come I cannot do this in argument arrays in C++ ?
int sicmct (const longint nprint, longint nprara [nprint])
Because C++ does not support variable-length array types.
So my C++ compiler likes
ÿÿ int sicmct (const longint nprint, longint nprara [96])
or
ÿÿ int sicmct (const longint nprint, longint nprara [])
So I guess that anything else is classified as variable that is not
typed as const int and initialized.
Lynn
BTW, at least my compiler takes this:
int sicmct (const longint nprint, longint nprara [4 * 96])
On 5/21/2026 7:39 PM, Keith Thompson wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
How come I cannot do this in argument arrays in C++ ?
int sicmct (const longint nprint, longint nprara [nprint])
Because C++ does not support variable-length array types.
So my C++ compiler likes
int sicmct (const longint nprint, longint nprara [96])
or
int sicmct (const longint nprint, longint nprara [])
On 5/21/2026 7:39 PM, Keith Thompson wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
How come I cannot do this in argument arrays in C++ ?Because C++ does not support variable-length array types.
int sicmct (const longint nprint, longint nprara [nprint])
So my C++ compiler likes
int sicmct (const longint nprint, longint nprara [96])
or
int sicmct (const longint nprint, longint nprara [])
So I guess that anything else is classified as variable that is not
typed as const int and initialized.
Lynn McGuire <lynnmcguire5@gmail.com> writes:
On 5/27/2026 5:08 PM, Lynn McGuire wrote:
On 5/21/2026 7:39 PM, Keith Thompson wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
How come I cannot do this in argument arrays in C++ ?
int sicmct (const longint nprint, longint nprara [nprint])
Because C++ does not support variable-length array types.
So my C++ compiler likes
ÿÿ int sicmct (const longint nprint, longint nprara [96])
or
ÿÿ int sicmct (const longint nprint, longint nprara [])
So I guess that anything else is classified as variable that is not
typed as const int and initialized.
Lynn
BTW, at least my compiler takes this:
int sicmct (const longint nprint, longint nprara [4 * 96])
The compiler likely simply ignores the value in square brackets since
it is effectively meaningless in C/C++.
It would be helpful if you told us _which_ C++ compiler
you're using, which options you provide to the compiler when
using it, and any #pragmas you use to disable warnings and errors.
Lynn McGuire <lynnmcguire5@gmail.com> writes:
On 5/21/2026 7:39 PM, Keith Thompson wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
How come I cannot do this in argument arrays in C++ ?Because C++ does not support variable-length array types.
int sicmct (const longint nprint, longint nprara [nprint])
So my C++ compiler likes
int sicmct (const longint nprint, longint nprara [96])
or
int sicmct (const longint nprint, longint nprara [])
Right, those are exactly equivalent. (And BTW, the "const" on the
first parameter affects only the parameter object within the body
of the function; it doesn't mean anything to callers.)
A parameter of array type, with or without a constant length,
is adjusted to the corresponding pointer type, so these are all
exactly equivalent (both in C and in C++):
int sicmct (const longint nprint, longint nprara [96])
int sicmct (const longint nprint, longint nprara [])
int sicmct (const longint nprint, longint *nprara)
Yes, the 96 is quietly ignored. Yes, this is annoying. (C99 added
a use of "static" on array parameters, but this is comp.lang.c++
so I won't go into the details.()
So I guess that anything else is classified as variable that is not
typed as const int and initialized.
It depends on what you mean by "anything else" -- and I have no idea
what you mean by "that is not typed as const int and initialized".
In C++, if there's an expression between the [], it has to be a
*constant*, not const, expression. ("Constant" means, roughly,
evaluated at compile time; "const" means read-only. Despite the
obvious relationship of the terms, they're very different things.
For example, `const int r = rand();` is perfectly valid.)
As James Kuyper pointed out elsethread, there are some expressions
that are constant expressions in C++ but not in C. For example,
given
const int answer = 42;
the expression `answer` is a constant expression in C++, but not
in C. But that doesn't seem to be relevant to the current case.
Finally, a comment on the name "longint". You mentioned upthread
that it's an alias (presumably a typedef) for long long. Anyone
reading the code who doesn't already know that will almost certainly
assume that it's a typedef for long, not for long long. The name
"longint" is not just uninformative; it's actively misleading.
If you want a name that suggests an integer type wider than int,
consider something like "wideint".
You said f2c chose the name "longint" for you. Can you provide a
*small* snippet of Fortran code that demonstrates that?
On 2026-05-27 18:08, Lynn McGuire wrote:
On 5/21/2026 7:39 PM, Keith Thompson wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
How come I cannot do this in argument arrays in C++ ?
int sicmct (const longint nprint, longint nprara [nprint])
Because C++ does not support variable-length array types.
So my C++ compiler likes
int sicmct (const longint nprint, longint nprara [96])
Of course - 96 is an integer constant expression, which is allowed in
array declarations, and ignored if the array is declared as a function parameter - that declaration is treated as the equivalent of "longint *npara". Those rules are the same in both C and C++.
Now,. some expressions count as integer constant expressions in C++ that
only count as integer expressions in C. In general, an array declaration
that had one of those expressions for the array length would make that
array a variable length array in C. However, in a function parameter declaration the length simply gets ignored as a result of being
converted to a pointer declaration.
or
int sicmct (const longint nprint, longint nprara [])
Since the integer constant expression is unnecessary, it can be left out
- that declaration is also equivalent to "longint *npara".
On 5/27/2026 5:52 PM, Scott Lurndal wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
On 5/27/2026 5:08 PM, Lynn McGuire wrote:
On 5/21/2026 7:39 PM, Keith Thompson wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
How come I cannot do this in argument arrays in C++ ?
int sicmct (const longint nprint, longint nprara [nprint])
Because C++ does not support variable-length array types.
So my C++ compiler likes
ÿ ÿÿ int sicmct (const longint nprint, longint nprara [96])
or
ÿ ÿÿ int sicmct (const longint nprint, longint nprara [])
So I guess that anything else is classified as variable that is not
typed as const int and initialized.
Lynn
BTW, at least my compiler takes this:
ÿÿÿ int sicmct (const longint nprint, longint nprara [4 * 96])
The compiler likely simply ignores the value in square brackets since
it is effectively meaningless in C/C++.
It would be helpful if you told us _which_ C++ compiler
you're using, which options you provide to the compiler when
using it, and any #pragmas you use to disable warnings and errors.
Microsoft Visual C++ 2015, 32 bit win32, debug code, no pragmas, no
special options.
Lynn
You said f2c chose the name "longint" for you. Can you provide a
*small* snippet of Fortran code that demonstrates that?
integer*8 i
This is almost entirely off-topic for comp.lang.c.
Lynn McGuire <lynnmcguire5@gmail.com> writes:
[...]
You said f2c chose the name "longint" for you. Can you provide a
*small* snippet of Fortran code that demonstrates that?
integer*8 i
OK, thanks.
On my system (Ubuntu), the generated C code has `#include "f2c.h"`,
which is in /usr/include/f2c.h, which is provided by the
libf2c2-dev:amd64 package.
I had to add an "end" statement and an assignment to i to get the type
to show up in the generated C code. Fortran:
integer*8 i
i = 42
end
Generated C:
#include "f2c.h"
// ...
static longint i__;
i__ = 42;
// ...
The f2c.h file has:
#ifdef INTEGER_STAR_8 /* Adjust for integer*8. */
typedef int64_t longit;
typedef uint64_t ulongint;
...
So "longint" is only indirectly an alias for long long, via
"int64_t". And presumably the intent is that C is being used as
an intermediate language, not meant to be maintained. (Defining
consistent names for integer types across languages can be tricky.)
And there's an astonishing typo ("longit" rather than "longint"),
which I can't find in any f2c source code, but it appears in versions 20200916-1 (Ubuntu 24.04.4) and 20240504-1build1 (Ubuntu 26.04).
This is almost entirely off-topic for comp.lang.c.
You said f2c chose the name "longint" for you.ÿ Can you provide a
*small* snippet of Fortran code that demonstrates that?
ÿÿÿÿÿ integer*8 i
Microsoft Visual C++ 2015, 32 bit win32, debug code, no pragmas, no
special options.
And I am creating a very large Win32 DLL with this code.
ÿ When I get it
to working, I will then create a very large Win64 DLL with the code.ÿ I
will have to ship both since several of my customers are using the
current Win32 DLL.ÿ I have customers waiting for the Win64 DLL that will
be callable from Excel x64.
Lynn
On 5/27/2026 6:52 PM, Lynn McGuire wrote:
[...]
And I am creating a very large Win32 DLL with this code.
Two or one? One to hold them all, one to rule them all... ;^D
ÿ When I get it to working, I will then create a very large Win64 DLL
with the code.ÿ I will have to ship both since several of my customers
are using the current Win32 DLL.ÿ I have customers waiting for the
Win64 DLL that will be callable from Excel x64.
Lynn
The f2c.h file has:[...]
#ifdef INTEGER_STAR_8 /* Adjust for integer*8. */
typedef int64_t longit;
typedef uint64_t ulongint;
And there's an astonishing typo ("longit" rather than "longint"),
which I can't find in any f2c source code, but it appears in versions 20200916-1 (Ubuntu 24.04.4) and 20240504-1build1 (Ubuntu 26.04).
On 5/27/2026 6:40 PM, Lynn McGuire wrote:
[...]
Microsoft Visual C++ 2015, 32 bit win32, debug code, no pragmas, no
special options.
Fwiw, I used the live shit out of the compiler! Pretty good with C, C++ okay. Its fun that MSVC used to have better support for C than C++.
On 5/27/2026 6:52 PM, James Kuyper wrote:
On 2026-05-27 18:08, Lynn McGuire wrote:
On 5/21/2026 7:39 PM, Keith Thompson wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
How come I cannot do this in argument arrays in C++ ?
int sicmct (const longint nprint, longint nprara [nprint])
Because C++ does not support variable-length array types.
So my C++ compiler likes
ÿÿÿÿ int sicmct (const longint nprint, longint nprara [96])
Of course - 96 is an integer constant expression, which is allowed in
array declarations, and ignored if the array is declared as a function
parameter - that declaration is treated as the equivalent of "longint
*npara". Those rules are the same in both C and C++.
Now,. some expressions count as integer constant expressions in C++ that
only count as integer expressions in C. In general, an array declaration
that had one of those expressions for the array length would make that
array a variable length array in C. However, in a function parameter
declaration the length simply gets ignored as a result of being
converted to a pointer declaration.
or
ÿÿÿÿ int sicmct (const longint nprint, longint nprara [])
Since the integer constant expression is unnecessary, it can be left out
- that declaration is also equivalent to "longint *npara".
I am really hoping that the debugger will use that [96] to know how much
an array to show me in quickwatch.
Otherwise it is a good hint for the next programmer that deals with this code.
? Then the size is part of the type and you can't make a mistake.
On 28/05/2026 03:47, Lynn McGuire wrote:
On 5/27/2026 6:52 PM, James Kuyper wrote:
On 2026-05-27 18:08, Lynn McGuire wrote:
On 5/21/2026 7:39 PM, Keith Thompson wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
How come I cannot do this in argument arrays in C++ ?
int sicmct (const longint nprint, longint nprara [nprint])
Because C++ does not support variable-length array types.
So my C++ compiler likes
ÿÿÿÿ int sicmct (const longint nprint, longint nprara [96])
Of course - 96 is an integer constant expression, which is allowed in
array declarations, and ignored if the array is declared as a function
parameter - that declaration is treated as the equivalent of "longint
*npara". Those rules are the same in both C and C++.
Now,. some expressions count as integer constant expressions in C++ that >>> only count as integer expressions in C. In general, an array declaration >>> that had one of those expressions for the array length would make that
array a variable length array in C. However, in a function parameter
declaration the length simply gets ignored as a result of being
converted to a pointer declaration.
or
ÿÿÿÿ int sicmct (const longint nprint, longint nprara [])
Since the integer constant expression is unnecessary, it can be left out >>> - that declaration is also equivalent to "longint *npara".
I am really hoping that the debugger will use that [96] to know how
much an array to show me in quickwatch.
Otherwise it is a good hint for the next programmer that deals with
this code.
It is certainly a good thing from the "self-documenting code" viewpoint,
but you need to make sure the value is accurate as the language can't
help you check it.
But if the size of the array is fixed, why not use std::array<longint,
?ÿ Then the size is part of the type and you can't make a mistake.
On 5/27/2026 6:52 PM, James Kuyper wrote:
On 2026-05-27 18:08, Lynn McGuire wrote:
On 5/21/2026 7:39 PM, Keith Thompson wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
How come I cannot do this in argument arrays in C++ ?
int sicmct (const longint nprint, longint nprara [nprint])
Because C++ does not support variable-length array types.
So my C++ compiler likes
int sicmct (const longint nprint, longint nprara [96])
Of course - 96 is an integer constant expression, which is allowed in
array declarations, and ignored if the array is declared as a function
parameter - that declaration is treated as the equivalent of "longint
*npara". Those rules are the same in both C and C++.
Now,. some expressions count as integer constant expressions in C++ that
only count as integer expressions in C. In general, an array declaration
that had one of those expressions for the array length would make that
array a variable length array in C. However, in a function parameter
declaration the length simply gets ignored as a result of being
converted to a pointer declaration.
or
int sicmct (const longint nprint, longint nprara [])
Since the integer constant expression is unnecessary, it can be left out
- that declaration is also equivalent to "longint *npara".
I am really hoping that the debugger will use that [96] to know how much
an array to show me in quickwatch.
Otherwise it is a good hint for the next programmer that deals with this >code.
Lynn McGuire <lynnmcguire5@gmail.com> writes:
On 5/27/2026 6:52 PM, James Kuyper wrote:
On 2026-05-27 18:08, Lynn McGuire wrote:
On 5/21/2026 7:39 PM, Keith Thompson wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
How come I cannot do this in argument arrays in C++ ?
int sicmct (const longint nprint, longint nprara [nprint])
Because C++ does not support variable-length array types.
So my C++ compiler likes
int sicmct (const longint nprint, longint nprara [96])
Of course - 96 is an integer constant expression, which is allowed in
array declarations, and ignored if the array is declared as a function
parameter - that declaration is treated as the equivalent of "longint
*npara". Those rules are the same in both C and C++.
Now,. some expressions count as integer constant expressions in C++ that >>> only count as integer expressions in C. In general, an array declaration >>> that had one of those expressions for the array length would make that
array a variable length array in C. However, in a function parameter
declaration the length simply gets ignored as a result of being
converted to a pointer declaration.
or
int sicmct (const longint nprint, longint nprara [])
Since the integer constant expression is unnecessary, it can be left out >>> - that declaration is also equivalent to "longint *npara".
I am really hoping that the debugger will use that [96] to know how much
an array to show me in quickwatch.
Highly unlikely, as that value will not be preserved in the
debugging information in the executable image.
Otherwise it is a good hint for the next programmer that deals with this
code.
I would think it is a bad hint and poor documentation. At the least,
it should be a macro or a named constant, but the next programmer,
who knows C/C++ would wonder why that was declared that way.
On 28/05/2026 15:03, Scott Lurndal wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
On 5/27/2026 6:52 PM, James Kuyper wrote:
On 2026-05-27 18:08, Lynn McGuire wrote:
On 5/21/2026 7:39 PM, Keith Thompson wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
How come I cannot do this in argument arrays in C++ ?
int sicmct (const longint nprint, longint nprara [nprint])
Because C++ does not support variable-length array types.
So my C++ compiler likes
????? int sicmct (const longint nprint, longint nprara [96])
Of course - 96 is an integer constant expression, which is allowed in
array declarations, and ignored if the array is declared as a function >>>> parameter - that declaration is treated as the equivalent of "longint
*npara". Those rules are the same in both C and C++.
Now,. some expressions count as integer constant expressions in C++ that >>>> only count as integer expressions in C. In general, an array declaration >>>> that had one of those expressions for the array length would make that >>>> array a variable length array in C. However, in a function parameter
declaration the length simply gets ignored as a result of being
converted to a pointer declaration.
or
????? int sicmct (const longint nprint, longint nprara [])
Since the integer constant expression is unnecessary, it can be left out >>>> - that declaration is also equivalent to "longint *npara".
I am really hoping that the debugger will use that [96] to know how much >>> an array to show me in quickwatch.
Highly unlikely, as that value will not be preserved in the
debugging information in the executable image.
Correct.? It's possible to instruct the debugger (at debug time) to display an array of elements of
a given size, for the Watch and QuickWatch windows.? [Basically if buf is the pointer variable being
watched, amend "buf" in the display window to "buf,20" to tell debugger to display array of 20
elements.? There's an online help page somewhere with the full syntax.]? Or of course sort out your
allocation issues and use std::array, which the debugger understands.
[The debugger understands std::array, because somewhere there is a custom debugger "visualiser" for
std::array.? It might be possible to add a similar customisation for your array type.? (Or it might
not - I've never looked into that feature!)]
Mike.
Otherwise it is a good hint for the next programmer that deals with this >>> code.
I would think it is a bad hint and poor documentation.??? At the least,
it should be a macro or a named constant, but the next programmer,
who knows C/C++ would wonder why that was declared that way.
Sorry, that's Visual Studio debugger specific.ÿ Not sure why I just
assumed you were using VS!
On 5/28/2026 10:12 AM, Mike Terry wrote:
[redacted]
Sorry, that's Visual Studio debugger specific.ÿ Not sure why I just
assumed you were using VS!
Lynn *is* using VS. Specifically VS2015.
On Thu, 28 May 2026 15:07:18 -0700
red floyd <no.spam.here@its.invalid> gabbled:
On 5/28/2026 10:12 AM, Mike Terry wrote:
[redacted]
Sorry, that's Visual Studio debugger specific.ÿ Not sure why I just
assumed you were using VS!
Lynn *is* using VS. Specifically VS2015.
Off topic but given gdb crashed on me the other day for the 1st time ever it >made me wonder - how to debugger writers debug their debugger? Presumably >they can't use a debugger on their code because that'll set all the trace >traps their new code will want to use.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 13 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 29:37:24 |
| Calls: | 218 |
| Files: | 21,503 |
| Messages: | 84,138 |