Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #123865 > unrolled thread

argument array sizes in methods

Back to article view | Back to comp.lang.c++

Contents

  argument array sizes in methods Lynn McGuire <lynnmcguire5@gmail.com> - 2026-05-21 18:46 -0500
    Re: argument array sizes in methods Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-21 17:39 -0700
      Re: argument array sizes in methods Lynn McGuire <lynnmcguire5@gmail.com> - 2026-05-21 22:17 -0500
        Re: argument array sizes in methods Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-21 21:03 -0700
          Re: argument array sizes in methods Lynn McGuire <lynnmcguire5@gmail.com> - 2026-05-22 00:30 -0500
          Re: argument array sizes in methods Lynn McGuire <lynnmcguire5@gmail.com> - 2026-05-22 00:32 -0500
        Re: argument array sizes in methods scott@slp53.sl.home (Scott Lurndal) - 2026-05-22 14:14 +0000
          Re: argument array sizes in methods Lynn McGuire <lynnmcguire5@gmail.com> - 2026-05-22 15:20 -0500
            Re: argument array sizes in methods scott@slp53.sl.home (Scott Lurndal) - 2026-05-22 21:11 +0000
              Re: argument array sizes in methods Lynn McGuire <lynnmcguire5@gmail.com> - 2026-05-22 16:45 -0500
                Re: argument array sizes in methods Lynn McGuire <lynnmcguire5@gmail.com> - 2026-05-24 18:45 -0500
      Re: argument array sizes in methods Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-22 08:29 +0200
      Re: argument array sizes in methods boltar@caprica.universe - 2026-05-22 09:16 +0000
      Re: argument array sizes in methods Lynn McGuire <lynnmcguire5@gmail.com> - 2026-05-27 17:08 -0500
        Re: argument array sizes in methods Lynn McGuire <lynnmcguire5@gmail.com> - 2026-05-27 17:18 -0500
          Re: argument array sizes in methods scott@slp53.sl.home (Scott Lurndal) - 2026-05-27 22:52 +0000
            Re: argument array sizes in methods Lynn McGuire <lynnmcguire5@gmail.com> - 2026-05-27 20:40 -0500
              Re: argument array sizes in methods Lynn McGuire <lynnmcguire5@gmail.com> - 2026-05-27 20:52 -0500
                Re: argument array sizes in methods "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-27 19:51 -0700
                  Re: argument array sizes in methods Lynn McGuire <lynnmcguire5@gmail.com> - 2026-05-28 00:17 -0500
              Re: argument array sizes in methods "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-27 19:46 -0700
                Re: argument array sizes in methods Lynn McGuire <lynnmcguire5@gmail.com> - 2026-05-28 00:59 -0500
        Re: argument array sizes in methods James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-27 19:52 -0400
          Re: argument array sizes in methods Lynn McGuire <lynnmcguire5@gmail.com> - 2026-05-27 20:47 -0500
            Re: argument array sizes in methods David Brown <david.brown@hesbynett.no> - 2026-05-28 08:18 +0200
              Re: argument array sizes in methods Lynn McGuire <lynnmcguire5@gmail.com> - 2026-05-28 02:04 -0500
            Re: argument array sizes in methods scott@slp53.sl.home (Scott Lurndal) - 2026-05-28 14:03 +0000
              Re: argument array sizes in methods Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2026-05-28 18:05 +0100
                Re: argument array sizes in methods Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2026-05-28 18:12 +0100
                  Re: argument array sizes in methods red floyd <no.spam.here@its.invalid> - 2026-05-28 15:07 -0700
                    Re: argument array sizes in methods boltar@caprica.universe - 2026-05-29 08:44 +0000
                      Re: argument array sizes in methods scott@slp53.sl.home (Scott Lurndal) - 2026-05-29 14:33 +0000
        Re: argument array sizes in methods Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-27 17:33 -0700
          Re: argument array sizes in methods Lynn McGuire <lynnmcguire5@gmail.com> - 2026-05-27 20:42 -0500
            Re: argument array sizes in methods Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-27 19:17 -0700
              Re: argument array sizes in methods Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-27 19:18 -0700
              Re: argument array sizes in methods Lynn McGuire <lynnmcguire5@gmail.com> - 2026-05-27 21:42 -0500
              Re: argument array sizes in methods Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-27 22:20 -0700
            Re: argument array sizes in methods "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-27 19:45 -0700

Page 2 of 2 — ← Prev page 1 [2]

#123902

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++.

[toc] | [prev] | [next] | [standalone]

#123906

On 5/27/2026 9:46 PM, Chris M. Thomasson wrote:
> 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++.

The first C compiler I used was Turbo C in 1986 ?.  The IDE was awesome 
for this guy who started programming with Fortran on punch cards in 1975 
in my Dads software company on a 4800 baud lease line to a Univac 1108.

I went back to work with Dad in 1989, worked with the Unix boxen that we 
were shipping our software on.  The cc compiler was fairly primitive and 
so was f77.  For a while we were maintaining our software across ten 
platforms from Microsoft DOS, Vax VMS, VaxWindows, Prime, Apollo Domain, 
IBM RS/6000, Sun Workstation, HP UX, to two different types of IBM 3090 
mainframes.

The nice thing about Visual C++ 2015 is that the EXEs and DLLs work all 
the way back to Windows XP.  We still have couple of customers on 
Windows XP at my last count, they may have upgraded by now.

Lynn

[toc] | [prev] | [next] | [standalone]

#123892

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".

[toc] | [prev] | [next] | [standalone]

#123896

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

[toc] | [prev] | [next] | [standalone]

#123907

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, 
96> ?  Then the size is part of the type and you can't make a mistake.

[toc] | [prev] | [next] | [standalone]

#123908

On 5/28/2026 1:18 AM, David Brown wrote:
> 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, 
> 96> ?  Then the size is part of the type and you can't make a mistake.

Because I have a dynamic memory allocator in the old Fortran code and I 
do not want to deal with it today.  There are thousands of memory 
allocations, reallocations, and frees in the old code.  I may get rid of 
them someday but not today.

Thanks,
Lynn

[toc] | [prev] | [next] | [standalone]

#123909

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.

[toc] | [prev] | [next] | [standalone]

#123910

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.
> 

[toc] | [prev] | [next] | [standalone]

#123911

On 28/05/2026 18:05, Mike Terry wrote:
> 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!)]
> 

Sorry, that's Visual Studio debugger specific.  Not sure why I just assumed you were using VS!

> 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.
>>

[toc] | [prev] | [next] | [standalone]

#123912

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.

[toc] | [prev] | [next] | [standalone]

#123913

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.

[toc] | [prev] | [next] | [standalone]

#123914

boltar@caprica.universe writes:
>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.

Back in 1998, I wrote the in-kernel debugger (kdb) for linux.

Debugging techniques in those days (on x86) involved a lot
of logging, and where available, in-circuit emulators or
simulators like AMD SimNow, although it was actually possible in most cases
to use kdb to debug kdb, just as it is possible to debug
gdb using gdb.

$ gdb -q --args gdb -q --args ls /tmp/bb
Reading symbols from gdb...Reading symbols from /home/scott/gdb...(no debugging symbols found)...done.
(no debugging symbols found)...done.
Missing separate debuginfos, use: debuginfo-install gdb-7.7.1-21.fc20.x86_64
(gdb) r
Starting program: /usr/bin/gdb -q --args ls /tmp/bb

(gdb) r
Starting program: /usr/bin/ls /tmp/bb
Detaching after fork from child process 29871.
Detaching after fork from child process 29872.
Detaching after fork from child process 29874.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
a  b
[Inferior 1 (process 29871) exited normally]
(gdb) q
[Inferior 1 (process 29866) exited normally]
(gdb) q
$ 

[toc] | [prev] | [next] | [standalone]

#123893

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.
>
> 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?

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#123895

On 5/27/2026 7:33 PM, Keith Thompson 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.
>>
>> 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?

       integer*8 i

Lynn

[toc] | [prev] | [next] | [standalone]

#123898

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.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#123899

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
> This is almost entirely off-topic for comp.lang.c.

And of course for comp.lang.c++, which is what I meant to type.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#123900

On 5/27/2026 9:17 PM, Keith Thompson wrote:
> 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.

I have heavily modified f2c for my needs and to generate C++ code.

Thanks,
Lynn

[toc] | [prev] | [next] | [standalone]

#123905

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
> 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).

This bug originated in a Debian-specific patch in 2020, and
propagated to Ubuntu (and presumably other Debian-based systems).

I've reported it here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1138079

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#123901

On 5/27/2026 6:42 PM, Lynn McGuire wrote:
[...]
>> You said f2c chose the name "longint" for you.  Can you provide a
>> *small* snippet of Fortran code that demonstrates that?
> 
>        integer*8 i

Shit man, that can make me think of integer*8 + 0i

integer, how large does it fit with a word on the system? I don't know.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c++

csiph-web