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

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

recovering from std::bad_alloc in std::string reserve

Started byLynn McGuire <lynnmcguire5@gmail.com>
First post2021-05-24 20:46 -0500
Last post2021-06-01 17:35 -0700
Articles 20 on this page of 112 — 21 participants

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

Contents

  recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-24 20:46 -0500
    Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-24 20:50 -0500
      Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-24 20:52 -0500
        Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-25 07:47 +0300
          Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-25 12:20 -0500
            Re: recovering from std::bad_alloc in std::string reserve Christian Gollwitzer <auriocus@gmx.de> - 2021-05-26 08:36 +0200
              Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-26 13:28 -0500
        Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 12:56 +0200
          Re: recovering from std::bad_alloc in std::string reserve scott@slp53.sl.home (Scott Lurndal) - 2021-05-25 14:55 +0000
            Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-25 18:42 +0300
              Re: recovering from std::bad_alloc in std::string reserve MrSpook_Ann1u@d0v_5eh1bqgd.com - 2021-05-25 16:10 +0000
                Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 18:23 +0200
                Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-25 19:57 +0300
                  Re: recovering from std::bad_alloc in std::string reserve MrSpook_ddZgr4t4@okc9_pd48oig5.info - 2021-05-26 07:15 +0000
                    Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-26 09:22 +0200
                    Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-26 10:54 +0300
                      Re: recovering from std::bad_alloc in std::string reserve MrSpook_dw5lvA4g@kak0_42x.edu - 2021-05-26 08:29 +0000
              Re: recovering from std::bad_alloc in std::string reserve Nikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr> - 2021-05-25 16:21 +0000
                Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-25 20:04 +0300
                  Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-25 12:46 -0500
                    Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-25 20:58 +0300
                      Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-25 13:48 -0500
                    Re: recovering from std::bad_alloc in std::string reserve Nikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr> - 2021-05-25 18:23 +0000
                      Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-25 13:49 -0500
                        Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-26 21:07 -0500
            Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 18:23 +0200
    Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-24 22:33 -0500
      Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-24 22:35 -0500
        Re: recovering from std::bad_alloc in std::string reserve Juha Nieminen <nospam@thanks.invalid> - 2021-05-25 05:16 +0000
          Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 13:00 +0200
          Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-25 12:49 -0500
    Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-27 14:08 -0500
      Re: recovering from std::bad_alloc in std::string reserve scott@slp53.sl.home (Scott Lurndal) - 2021-05-27 21:59 +0000
        Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-27 15:33 -0700
          Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-27 15:58 -0700
            Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-27 18:17 -0500
              Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-27 16:58 -0700
                Re: recovering from std::bad_alloc in std::string reserve Öö Tiib <ootiib@hot.ee> - 2021-05-27 18:36 -0700
                  Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-27 21:38 -0500
                    Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-28 08:53 +0300
                    Re: recovering from std::bad_alloc in std::string reserve Bo Persson <bo@bo-persson.se> - 2021-05-28 09:47 +0200
                  Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-27 19:54 -0700
                    Re: recovering from std::bad_alloc in std::string reserve Öö Tiib <ootiib@hot.ee> - 2021-05-27 21:02 -0700
                      Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-28 12:09 -0700
                        Re: recovering from std::bad_alloc in std::string reserve scott@slp53.sl.home (Scott Lurndal) - 2021-05-28 20:26 +0000
                        Re: recovering from std::bad_alloc in std::string reserve Öö Tiib <ootiib@hot.ee> - 2021-05-28 17:10 -0700
                        Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-05-29 11:47 +0200
                          Re: recovering from std::bad_alloc in std::string reserve "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-05-30 15:15 -0700
                            Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-05-31 08:33 +0200
                              Re: recovering from std::bad_alloc in std::string reserve "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-05-31 08:21 -0700
                                Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-05-31 18:13 +0200
                              Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-31 14:43 -0700
                                Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-31 14:44 -0700
                                Re: recovering from std::bad_alloc in std::string reserve "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-05-31 15:20 -0700
                                  Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-01 11:17 -0700
                                    Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-01 20:25 +0200
                                      Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-01 16:55 -0700
                                    Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-02 09:06 +0200
                                      Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-05 17:50 -0700
                                        Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-06 11:10 +0200
                                          Re: recovering from std::bad_alloc in std::string reserve Öö Tiib <ootiib@hot.ee> - 2021-06-06 04:07 -0700
                                          Re: recovering from std::bad_alloc in std::string reserve Richard Damon <Richard@Damon-Family.org> - 2021-06-06 07:49 -0400
                                  Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-01 20:21 +0200
                                    Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-02 09:29 +0200
                                      Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-02 18:43 +0200
                                        Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-02 23:32 +0200
                                          Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-03 00:49 +0200
                                            Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-03 09:08 +0200
                                              Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-03 10:53 +0200
                                              Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-03 16:20 +0200
                                              Re: recovering from std::bad_alloc in std::string reserve James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-03 11:20 -0400
                                                Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-03 19:04 +0200
                                                  Re: recovering from std::bad_alloc in std::string reserve scott@slp53.sl.home (Scott Lurndal) - 2021-06-03 22:24 +0000
                                                    Re: recovering from std::bad_alloc in std::string reserve Öö Tiib <ootiib@hot.ee> - 2021-06-03 16:27 -0700
                                                      Re: recovering from std::bad_alloc in std::string reserve scott@slp53.sl.home (Scott Lurndal) - 2021-06-04 00:36 +0000
                                                        Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-04 08:46 +0200
                                                          Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-05 22:02 -0700
                                                            Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-06 11:17 +0200
                                                              Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-06 18:39 +0200
                                                              Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 16:33 -0700
                                                                Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-07 08:41 +0200
                                                            Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-06 17:46 +0200
                                                            Re: recovering from std::bad_alloc in std::string reserve MrSpook_Qfmtjdmi@nc6.com - 2021-06-06 14:11 +0000
                                          Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-03 16:43 +0200
                                  Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-01 18:00 +0200
                                    Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-01 19:15 +0200
                                  Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-01 15:55 +0200
                                  Re: recovering from std::bad_alloc in std::string reserve Bo Persson <bo@bo-persson.se> - 2021-06-01 13:59 +0200
                                    Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-06-01 13:26 -0500
                                Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-01 08:29 +0200
                                  Re: recovering from std::bad_alloc in std::string reserve Bo Persson <bo@bo-persson.se> - 2021-06-01 14:05 +0200
                                    Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-01 15:58 +0200
                                      Re: recovering from std::bad_alloc in std::string reserve James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-01 11:33 -0400
                                        Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-01 10:52 -0700
              Re: recovering from std::bad_alloc in std::string reserve James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-05-27 23:16 -0400
              Re: recovering from std::bad_alloc in std::string reserve scott@slp53.sl.home (Scott Lurndal) - 2021-05-28 14:34 +0000
            Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-27 18:19 -0500
          Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-28 03:47 +0200
        Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-27 17:45 -0500
          Re: recovering from std::bad_alloc in std::string reserve scott@slp53.sl.home (Scott Lurndal) - 2021-05-28 14:38 +0000
            Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-28 16:44 +0200
            Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-28 16:42 +0200
            Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-28 18:22 +0300
        Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-28 08:47 +0300
    Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-26 06:16 +0200
      Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-26 13:30 -0500
        Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-26 20:37 +0200
          Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-26 14:09 -0500
    Re: recovering from std::bad_alloc in std::string reserve "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-05-26 18:33 +0200
      Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-26 13:32 -0500
        Re: recovering from std::bad_alloc in std::string reserve Christian Gollwitzer <auriocus@gmx.de> - 2021-05-27 07:50 +0200
    Re: recovering from std::bad_alloc in std::string reserve "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-06-01 17:35 -0700

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

#79920

FromPaavo Helde <myfirstname@osa.pri.ee>
Date2021-05-25 20:58 +0300
Message-ID<s8jdrd$6b4$1@dont-email.me>
In reply to#79915
25.05.2021 20:46 Lynn McGuire kirjutas:
> 
> Yes, I have Windows 7 x64 Pro.  I cannot convert to win64 at this time. 
>   When we do convert, it will be a steep hill as we started this code in 
> Win16 in 1987.  The Win32 port was a very steep hill in 2000.

Nowadays there are special compiler warnings for 64-bit porting issues. 
When porting, it would make sense to enable them all, turn them into 
errors instead of warnings, and fix them all.

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

#79932

FromLynn McGuire <lynnmcguire5@gmail.com>
Date2021-05-25 13:48 -0500
Message-ID<s8jgqn$hj2$1@dont-email.me>
In reply to#79920
On 5/25/2021 12:58 PM, Paavo Helde wrote:
> 25.05.2021 20:46 Lynn McGuire kirjutas:
>>
>> Yes, I have Windows 7 x64 Pro.  I cannot convert to win64 at this 
>> time.   When we do convert, it will be a steep hill as we started this 
>> code in Win16 in 1987.  The Win32 port was a very steep hill in 2000.
> 
> Nowadays there are special compiler warnings for 64-bit porting issues. 
> When porting, it would make sense to enable them all, turn them into 
> errors instead of warnings, and fix them all.

Thanks !

Lynn

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

#79925

FromNikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr>
Date2021-05-25 18:23 +0000
Message-ID<slrnsaqg57.ekd.nlazicBEZ_OVOGA@mudrac.ffzg.hr>
In reply to#79915
Dana Tue, 25 May 2021 12:46:30 -0500, Lynn McGuire <lynnmcguire5@gmail.com> napis'o:
> On 5/25/2021 12:04 PM, Paavo Helde wrote:
>> 25.05.2021 19:21 Nikolaj Lazic kirjutas:
>>> Dana Tue, 25 May 2021 18:42:54 +0300, Paavo Helde 
>>> <myfirstname@osa.pri.ee> napis'o:
>>>> 25.05.2021 17:55 Scott Lurndal kirjutas:
>>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>>> You've got a 2GB address-space and not a contignous piece of
>>>>>> memory which fits to your 900MB.
>>>>>
>>>>> It doesn't need to be contiguous.  But it needs to exist either
>>>>> as real memory or as configured backing store (i.e. swap space).
>>>>
>>>> For fitting a 900 MB std::string into a memory one needs 900 MB of
>>>> contiguous address space and Bonita is right in pointing out this might
>>>> be problematic because of memory fragmentation.
>>>>
>>>> The OP has 16 GB of RAM so there is plenty of physical memory, it's just
>>>> a problem with the limited address space in 32-bit programs.
>>>
>>> Win7 32bit cannot access 16G. Limit is 3.5G.
>>> She needs 64bit Windows to use it.
>> 
>> OP was a bit unclear in this point. But there would be no point to have 
>> a 32-bit Windows 7 on a machine with 16 GB RAM, so I hope he has got a 
>> 64-bit OS after all.
>
> Yes, I have Windows 7 x64 Pro.  I cannot convert to win64 at this time. 
>   When we do convert, it will be a steep hill as we started this code in 
> Win16 in 1987.  The Win32 port was a very steep hill in 2000.

Maybe this can help:
https://stackoverflow.com/questions/639540/how-much-memory-can-a-32-bit-process-access-on-a-64-bit-operating-system

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

#79931

FromLynn McGuire <lynnmcguire5@gmail.com>
Date2021-05-25 13:49 -0500
Message-ID<s8jgrk$hj2$2@dont-email.me>
In reply to#79925
On 5/25/2021 1:23 PM, Nikolaj Lazic wrote:
> Dana Tue, 25 May 2021 12:46:30 -0500, Lynn McGuire <lynnmcguire5@gmail.com> napis'o:
>> On 5/25/2021 12:04 PM, Paavo Helde wrote:
>>> 25.05.2021 19:21 Nikolaj Lazic kirjutas:
>>>> Dana Tue, 25 May 2021 18:42:54 +0300, Paavo Helde
>>>> <myfirstname@osa.pri.ee> napis'o:
>>>>> 25.05.2021 17:55 Scott Lurndal kirjutas:
>>>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>>>> You've got a 2GB address-space and not a contignous piece of
>>>>>>> memory which fits to your 900MB.
>>>>>>
>>>>>> It doesn't need to be contiguous.  But it needs to exist either
>>>>>> as real memory or as configured backing store (i.e. swap space).
>>>>>
>>>>> For fitting a 900 MB std::string into a memory one needs 900 MB of
>>>>> contiguous address space and Bonita is right in pointing out this might
>>>>> be problematic because of memory fragmentation.
>>>>>
>>>>> The OP has 16 GB of RAM so there is plenty of physical memory, it's just
>>>>> a problem with the limited address space in 32-bit programs.
>>>>
>>>> Win7 32bit cannot access 16G. Limit is 3.5G.
>>>> She needs 64bit Windows to use it.
>>>
>>> OP was a bit unclear in this point. But there would be no point to have
>>> a 32-bit Windows 7 on a machine with 16 GB RAM, so I hope he has got a
>>> 64-bit OS after all.
>>
>> Yes, I have Windows 7 x64 Pro.  I cannot convert to win64 at this time.
>>    When we do convert, it will be a steep hill as we started this code in
>> Win16 in 1987.  The Win32 port was a very steep hill in 2000.
> 
> Maybe this can help:
> https://stackoverflow.com/questions/639540/how-much-memory-can-a-32-bit-process-access-on-a-64-bit-operating-system

Thanks !  I was aware of that but I had not tried it yet.

Lynn

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

#80021

FromLynn McGuire <lynnmcguire5@gmail.com>
Date2021-05-26 21:07 -0500
Message-ID<s8musm$mpc$1@dont-email.me>
In reply to#79931
On 5/25/2021 1:49 PM, Lynn McGuire wrote:
> On 5/25/2021 1:23 PM, Nikolaj Lazic wrote:
>> Dana Tue, 25 May 2021 12:46:30 -0500, Lynn McGuire 
>> <lynnmcguire5@gmail.com> napis'o:
>>> On 5/25/2021 12:04 PM, Paavo Helde wrote:
>>>> 25.05.2021 19:21 Nikolaj Lazic kirjutas:
>>>>> Dana Tue, 25 May 2021 18:42:54 +0300, Paavo Helde
>>>>> <myfirstname@osa.pri.ee> napis'o:
>>>>>> 25.05.2021 17:55 Scott Lurndal kirjutas:
>>>>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>>>>> You've got a 2GB address-space and not a contignous piece of
>>>>>>>> memory which fits to your 900MB.
>>>>>>>
>>>>>>> It doesn't need to be contiguous.  But it needs to exist either
>>>>>>> as real memory or as configured backing store (i.e. swap space).
>>>>>>
>>>>>> For fitting a 900 MB std::string into a memory one needs 900 MB of
>>>>>> contiguous address space and Bonita is right in pointing out this 
>>>>>> might
>>>>>> be problematic because of memory fragmentation.
>>>>>>
>>>>>> The OP has 16 GB of RAM so there is plenty of physical memory, 
>>>>>> it's just
>>>>>> a problem with the limited address space in 32-bit programs.
>>>>>
>>>>> Win7 32bit cannot access 16G. Limit is 3.5G.
>>>>> She needs 64bit Windows to use it.
>>>>
>>>> OP was a bit unclear in this point. But there would be no point to have
>>>> a 32-bit Windows 7 on a machine with 16 GB RAM, so I hope he has got a
>>>> 64-bit OS after all.
>>>
>>> Yes, I have Windows 7 x64 Pro.  I cannot convert to win64 at this time.
>>>    When we do convert, it will be a steep hill as we started this 
>>> code in
>>> Win16 in 1987.  The Win32 port was a very steep hill in 2000.
>>
>> Maybe this can help:
>> https://stackoverflow.com/questions/639540/how-much-memory-can-a-32-bit-process-access-on-a-64-bit-operating-system 
>>
> 
> Thanks !  I was aware of that but I had not tried it yet.
> 
> Lynn

I tried the /LARGEADDRESSAWARE linker option but it did not help.  I 
suspect that the memory is fragmented.

We will need to move to Win64 to fix this problem long term.

Thanks,
Lynn

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

#79889

FromBonita Montero <Bonita.Montero@gmail.com>
Date2021-05-25 18:23 +0200
Message-ID<s8j8ad$pvk$2@dont-email.me>
In reply to#79869
> It doesn't need to be contiguous. ...

I don't know exactly since when, but the standard-containers
guarantee linear memory for years.

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

#79740

FromLynn McGuire <lynnmcguire5@gmail.com>
Date2021-05-24 22:33 -0500
Message-ID<s8hr6h$6a2$1@dont-email.me>
In reply to#79727
On 5/24/2021 8:46 PM, Lynn McGuire wrote:
> I am getting std::bad_alloc from the following code when I try to 
> reserve a std::string of size 937,180,144:
> 
> std::string filename = getFormsMainOwner () -> getOutputFileName ();
> FILE * pOutputFile = nullptr;
> errno_t err = fopen_s_UTF8 ( & pOutputFile, filename.c_str (), "rt");
> if (err == 0)
> {
>      std::string outputFileBuffer;
>          //  need to preallocate the space in case the output file is a 
> gigabyte or more, PMR 6408
>      fseek (pOutputFile, 0, SEEK_END);
>      size_t outputFileLength = ftell (pOutputFile) + 42;  // give it 
> some slop
>      fseek (pOutputFile, 0, SEEK_SET);
>      outputFileBuffer.reserve (outputFileLength);
> 
> Any thoughts here on how to handle the std::bad_alloc in std::string 
> reserve ?
> 
> Thanks,
> Lynn

I googled this problem and the predominating solution was to put the 
std::string reserve into a try catch.  I did so and it works like a 
champ !  My first try catch.

try
{
	outputFileBuffer.reserve (outputFileLength);
	//  now read the file into the preallocated buffer
	while ((num = fread (buffer, sizeof (char), sizeof (buffer) - 1, 
pOutputFile)) > 0)
	{
		//  make sure that there is a trailing zero
		buffer [num] = '\0';
		outputFileBuffer += buffer;
		total += num;
		}
	}
	catch (...)
	{
		//  nothing to catch since any error causes this code to bypass
	}
}

Thanks,
Lynn

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

#79741

FromLynn McGuire <lynnmcguire5@gmail.com>
Date2021-05-24 22:35 -0500
Message-ID<s8hr9h$6a2$2@dont-email.me>
In reply to#79740
On 5/24/2021 10:33 PM, Lynn McGuire wrote:
> On 5/24/2021 8:46 PM, Lynn McGuire wrote:
>> I am getting std::bad_alloc from the following code when I try to 
>> reserve a std::string of size 937,180,144:
>>
>> std::string filename = getFormsMainOwner () -> getOutputFileName ();
>> FILE * pOutputFile = nullptr;
>> errno_t err = fopen_s_UTF8 ( & pOutputFile, filename.c_str (), "rt");
>> if (err == 0)
>> {
>>      std::string outputFileBuffer;
>>          //  need to preallocate the space in case the output file is 
>> a gigabyte or more, PMR 6408
>>      fseek (pOutputFile, 0, SEEK_END);
>>      size_t outputFileLength = ftell (pOutputFile) + 42;  // give it 
>> some slop
>>      fseek (pOutputFile, 0, SEEK_SET);
>>      outputFileBuffer.reserve (outputFileLength);
>>
>> Any thoughts here on how to handle the std::bad_alloc in std::string 
>> reserve ?
>>
>> Thanks,
>> Lynn
> 
> I googled this problem and the predominating solution was to put the 
> std::string reserve into a try catch.  I did so and it works like a 
> champ !  My first try catch.
> 
> try
> {
>      outputFileBuffer.reserve (outputFileLength);
>      //  now read the file into the preallocated buffer
>      while ((num = fread (buffer, sizeof (char), sizeof (buffer) - 1, 
> pOutputFile)) > 0)
>      {
>          //  make sure that there is a trailing zero
>          buffer [num] = '\0';
>          outputFileBuffer += buffer;
>          total += num;
>          }
>      }
>      catch (...)
>      {
>          //  nothing to catch since any error causes this code to bypass
>      }
> }
> 
> Thanks,
> Lynn

Let's try this code instead:

try
{
     outputFileBuffer.reserve (outputFileLength);
     //  now read the file into the preallocated buffer
     while ((num = fread (buffer, sizeof (char), sizeof (buffer) - 1, 
pOutputFile)) > 0)
     {
         //  make sure that there is a trailing zero
         buffer [num] = '\0';
         outputFileBuffer += buffer;
         total += num;
         }
     }
}
catch (...)
{
     //  nothing to catch since any error causes this code to bypass
}

Thanks,
Lynn

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

#79749

FromJuha Nieminen <nospam@thanks.invalid>
Date2021-05-25 05:16 +0000
Message-ID<s8i17q$1fo5$1@gioia.aioe.org>
In reply to#79741
Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>     while ((num = fread (buffer, sizeof (char), sizeof (buffer) - 1, 
> pOutputFile)) > 0)

The standard mandates that sizeof(char) is 1. It cannot have any other
value.

> catch (...)
> {
>     //  nothing to catch since any error causes this code to bypass
> }

If you are catching a memory allocation, why not catch it explicitly and
return an error code or print an informative error message or something
that indicates what happened, rather than silently failing and doing
nothing?

try
{
    // your code here
}
catch(const std::bad_alloc& e)
{
    // Could do, for example:
    std::cout << "Memory allocation failed: " << e.what() << "\n";
}
catch(...)
{
    std::cout << "Unknown excpetion thrown while trying to read file\n";
}

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

#79834

FromBonita Montero <Bonita.Montero@gmail.com>
Date2021-05-25 13:00 +0200
Message-ID<s8ilcq$968$1@dont-email.me>
In reply to#79749
> If you are catching a memory allocation, why not catch it explicitly and
> return an error code or print an informative error message or something
> that indicates what happened, rather than silently failing and doing
> nothing?

On the other side:
if bad_alloc is the only expectable exception you could stick with "..."

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

#79916

FromLynn McGuire <lynnmcguire5@gmail.com>
Date2021-05-25 12:49 -0500
Message-ID<s8jdba$vlv$2@dont-email.me>
In reply to#79749
On 5/25/2021 12:16 AM, Juha Nieminen wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>      while ((num = fread (buffer, sizeof (char), sizeof (buffer) - 1,
>> pOutputFile)) > 0)
> 
> The standard mandates that sizeof(char) is 1. It cannot have any other
> value.
> 
>> catch (...)
>> {
>>      //  nothing to catch since any error causes this code to bypass
>> }
> 
> If you are catching a memory allocation, why not catch it explicitly and
> return an error code or print an informative error message or something
> that indicates what happened, rather than silently failing and doing
> nothing?
> 
> try
> {
>      // your code here
> }
> catch(const std::bad_alloc& e)
> {
>      // Could do, for example:
>      std::cout << "Memory allocation failed: " << e.what() << "\n";
> }
> catch(...)
> {
>      std::cout << "Unknown excpetion thrown while trying to read file\n";
> }

Thanks, I did not know the code for catching the bad_alloc explicitly.

Lynn

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

#79804

FromLynn McGuire <lynnmcguire5@gmail.com>
Date2021-05-27 14:08 -0500
Message-ID<s8oqn6$fbj$1@dont-email.me>
In reply to#79727
On 5/27/2021 12:50 AM, Christian Gollwitzer wrote:
> Am 26.05.21 um 20:32 schrieb Lynn McGuire: - Alf
>>
>> I have already replaced the fell code with _ftelli64.
>>
>> //  get the size of the output file
>> fseek (pOutputFile, 0, SEEK_END);
>> __int64 outputFileLength = _ftelli64 (pOutputFile) + 42;  // give it 
>> some slop
>> int outputFileLengthInt = (int) outputFileLength;
> 
> ...and here you restrict it to 2GB again, or worse, retrieve a negative 
> file size for sizes between 2GB and 4GB.
> 
> 
> To prepare for a 64bit move, you should replace all size variables with 
> size_t for unsigned or ptrdiff_t for signed. That will correspond to a 
> 32bit integer in 32 bit and a 64 bit integer in 64 bit.
> 
>      Christian

Done.  With checking against SIZE_MAX before casting the variable to size_t.

Yeah, if 1 GB is having trouble in Win32, 2+ GB will be much worse.  The 
code is now ok to fail without crashing the program.  Porting to Win64 
is needed in the near future.  So many thing to do, so little time.  I 
will be 61 in a couple of weeks, kinda hoping to retire before 75.

Thanks,
Lynn

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

#79807

Fromscott@slp53.sl.home (Scott Lurndal)
Date2021-05-27 21:59 +0000
Message-ID<_CUrI.452334$ST2.205157@fx47.iad>
In reply to#79804
Lynn McGuire <lynnmcguire5@gmail.com> writes:
>On 5/27/2021 12:50 AM, Christian Gollwitzer wrote:
>> Am 26.05.21 um 20:32 schrieb Lynn McGuire: - Alf
>>>
>>> I have already replaced the fell code with _ftelli64.
>>>
>>> //  get the size of the output file
>>> fseek (pOutputFile, 0, SEEK_END);
>>> __int64 outputFileLength = _ftelli64 (pOutputFile) + 42;  // give it 
>>> some slop
>>> int outputFileLengthInt = (int) outputFileLength;
>> 
>> ...and here you restrict it to 2GB again, or worse, retrieve a negative 
>> file size for sizes between 2GB and 4GB.
>> 
>> 
>> To prepare for a 64bit move, you should replace all size variables with 
>> size_t for unsigned or ptrdiff_t for signed. That will correspond to a 
>> 32bit integer in 32 bit and a 64 bit integer in 64 bit.
>> 
>>      Christian
>
>Done.  With checking against SIZE_MAX before casting the variable to size_t.

Why?   size_t is guaranteed to hold the size of any object, which implies that
it must be large enough to accomodate an object the size of the virtual address
space.   Generally it's minimum size in bits is the same as long.

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

#79808

FromKeith Thompson <Keith.S.Thompson+u@gmail.com>
Date2021-05-27 15:33 -0700
Message-ID<87sg27zu0i.fsf@nosuchdomain.example.com>
In reply to#79807
scott@slp53.sl.home (Scott Lurndal) writes:
> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>On 5/27/2021 12:50 AM, Christian Gollwitzer wrote:
>>> Am 26.05.21 um 20:32 schrieb Lynn McGuire: - Alf
>>>>
>>>> I have already replaced the fell code with _ftelli64.
>>>>
>>>> //  get the size of the output file
>>>> fseek (pOutputFile, 0, SEEK_END);
>>>> __int64 outputFileLength = _ftelli64 (pOutputFile) + 42;  // give it 
>>>> some slop
>>>> int outputFileLengthInt = (int) outputFileLength;
>>> 
>>> ...and here you restrict it to 2GB again, or worse, retrieve a negative 
>>> file size for sizes between 2GB and 4GB.
>>> 
>>> 
>>> To prepare for a 64bit move, you should replace all size variables with 
>>> size_t for unsigned or ptrdiff_t for signed. That will correspond to a 
>>> 32bit integer in 32 bit and a 64 bit integer in 64 bit.
>>> 
>>>      Christian
>>
>>Done.  With checking against SIZE_MAX before casting the variable to size_t.
>
> Why?   size_t is guaranteed to hold the size of any object, which implies that
> it must be large enough to accomodate an object the size of the virtual address
> space.   Generally it's minimum size in bits is the same as long.

That's likely to be true, but it's not absolutely guaranteed.

size_t is intended to hold the size of any single object, but it may
not be able to hold the sum of sizes of all objects or the size of
the virtual address space.  An implementation might restrict the
size of any single object to something smaller than the size of
the entire virtual address space.  (Think segments.)

Also, I haven't found anything in the standard that says you
can't at least try to create an object bigger than SIZE_MAX bytes.
calloc(SIZE_MAX, 2) attempts to allocate such an object, and I don't
see a requirement that it must fail.  If an implementation lets you
define a named object bigger than SIZE_MAX bytes, then presumably
applying sizeof to it would result in an overflow, and therefore
undefined behavior.

Any reasonable implementation will simply make size_t big enough
to hold the size of any object it can create, but I don't see a
requirement for it.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#79810

FromKeith Thompson <Keith.S.Thompson+u@gmail.com>
Date2021-05-27 15:58 -0700
Message-ID<87o8cvzsux.fsf@nosuchdomain.example.com>
In reply to#79808
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>>On 5/27/2021 12:50 AM, Christian Gollwitzer wrote:
>>>> Am 26.05.21 um 20:32 schrieb Lynn McGuire: - Alf
>>>>>
>>>>> I have already replaced the fell code with _ftelli64.
>>>>>
>>>>> //  get the size of the output file
>>>>> fseek (pOutputFile, 0, SEEK_END);
>>>>> __int64 outputFileLength = _ftelli64 (pOutputFile) + 42;  // give it 
>>>>> some slop
>>>>> int outputFileLengthInt = (int) outputFileLength;
>>>> 
>>>> ...and here you restrict it to 2GB again, or worse, retrieve a negative 
>>>> file size for sizes between 2GB and 4GB.
>>>> 
>>>> 
>>>> To prepare for a 64bit move, you should replace all size variables with 
>>>> size_t for unsigned or ptrdiff_t for signed. That will correspond to a 
>>>> 32bit integer in 32 bit and a 64 bit integer in 64 bit.
>>>> 
>>>>      Christian
>>>
>>>Done.  With checking against SIZE_MAX before casting the variable to size_t.
>>
>> Why?   size_t is guaranteed to hold the size of any object, which implies that
>> it must be large enough to accomodate an object the size of the virtual address
>> space.   Generally it's minimum size in bits is the same as long.
>
> That's likely to be true, but it's not absolutely guaranteed.

My apologies, I was wrong.

> size_t is intended to hold the size of any single object, but it may
> not be able to hold the sum of sizes of all objects or the size of
> the virtual address space.  An implementation might restrict the
> size of any single object to something smaller than the size of
> the entire virtual address space.  (Think segments.)

I believe this is still correct.

> Also, I haven't found anything in the standard that says you
> can't at least try to create an object bigger than SIZE_MAX bytes.
> calloc(SIZE_MAX, 2) attempts to allocate such an object, and I don't
> see a requirement that it must fail.  If an implementation lets you
> define a named object bigger than SIZE_MAX bytes, then presumably
> applying sizeof to it would result in an overflow, and therefore
> undefined behavior.
>
> Any reasonable implementation will simply make size_t big enough
> to hold the size of any object it can create, but I don't see a
> requirement for it.

The above is correct in C, but not in C++, which makes an additional
guarantee that C doesn't.  C++17 21.2.4 [support.types.layout] says:

    The type size_t is an implementation-defined unsigned integer type
    that is large enough to contain the size in bytes of any object
    (8.3.3).

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#79814

FromLynn McGuire <lynnmcguire5@gmail.com>
Date2021-05-27 18:17 -0500
Message-ID<s8p9ak$gun$1@dont-email.me>
In reply to#79810
On 5/27/2021 5:58 PM, Keith Thompson wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>>> On 5/27/2021 12:50 AM, Christian Gollwitzer wrote:
>>>>> Am 26.05.21 um 20:32 schrieb Lynn McGuire: - Alf
>>>>>>
>>>>>> I have already replaced the fell code with _ftelli64.
>>>>>>
>>>>>> //  get the size of the output file
>>>>>> fseek (pOutputFile, 0, SEEK_END);
>>>>>> __int64 outputFileLength = _ftelli64 (pOutputFile) + 42;  // give it
>>>>>> some slop
>>>>>> int outputFileLengthInt = (int) outputFileLength;
>>>>>
>>>>> ...and here you restrict it to 2GB again, or worse, retrieve a negative
>>>>> file size for sizes between 2GB and 4GB.
>>>>>
>>>>>
>>>>> To prepare for a 64bit move, you should replace all size variables with
>>>>> size_t for unsigned or ptrdiff_t for signed. That will correspond to a
>>>>> 32bit integer in 32 bit and a 64 bit integer in 64 bit.
>>>>>
>>>>>       Christian
>>>>
>>>> Done.  With checking against SIZE_MAX before casting the variable to size_t.
>>>
>>> Why?   size_t is guaranteed to hold the size of any object, which implies that
>>> it must be large enough to accomodate an object the size of the virtual address
>>> space.   Generally it's minimum size in bits is the same as long.
>>
>> That's likely to be true, but it's not absolutely guaranteed.
> 
> My apologies, I was wrong.
> 
>> size_t is intended to hold the size of any single object, but it may
>> not be able to hold the sum of sizes of all objects or the size of
>> the virtual address space.  An implementation might restrict the
>> size of any single object to something smaller than the size of
>> the entire virtual address space.  (Think segments.)
> 
> I believe this is still correct.
> 
>> Also, I haven't found anything in the standard that says you
>> can't at least try to create an object bigger than SIZE_MAX bytes.
>> calloc(SIZE_MAX, 2) attempts to allocate such an object, and I don't
>> see a requirement that it must fail.  If an implementation lets you
>> define a named object bigger than SIZE_MAX bytes, then presumably
>> applying sizeof to it would result in an overflow, and therefore
>> undefined behavior.
>>
>> Any reasonable implementation will simply make size_t big enough
>> to hold the size of any object it can create, but I don't see a
>> requirement for it.
> 
> The above is correct in C, but not in C++, which makes an additional
> guarantee that C doesn't.  C++17 21.2.4 [support.types.layout] says:
> 
>      The type size_t is an implementation-defined unsigned integer type
>      that is large enough to contain the size in bytes of any object
>      (8.3.3).

Except the actual size of a FILE * object in the filesystem.  Size_t can 
hold the size of the FILE * structure but if the actual file size is 
greater than 4 GB in a Win32 program, size_t will be wrong.

Now if the program is Win64, size_t can hold the actual size of any file 
in the filesystem.

#ifdef _WIN64
     typedef unsigned __int64 size_t;
     typedef __int64          ptrdiff_t;
     typedef __int64          intptr_t;
#else
     typedef unsigned int     size_t;
     typedef int              ptrdiff_t;
     typedef int              intptr_t;
#endif

Lynn

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

#79816

FromKeith Thompson <Keith.S.Thompson+u@gmail.com>
Date2021-05-27 16:58 -0700
Message-ID<87k0njzq45.fsf@nosuchdomain.example.com>
In reply to#79814
Lynn McGuire <lynnmcguire5@gmail.com> writes:
> On 5/27/2021 5:58 PM, Keith Thompson wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>>>> On 5/27/2021 12:50 AM, Christian Gollwitzer wrote:
>>>>>> Am 26.05.21 um 20:32 schrieb Lynn McGuire: - Alf
>>>>>>>
>>>>>>> I have already replaced the fell code with _ftelli64.
>>>>>>>
>>>>>>> //  get the size of the output file
>>>>>>> fseek (pOutputFile, 0, SEEK_END);
>>>>>>> __int64 outputFileLength = _ftelli64 (pOutputFile) + 42;  // give it
>>>>>>> some slop
>>>>>>> int outputFileLengthInt = (int) outputFileLength;
>>>>>>
>>>>>> ...and here you restrict it to 2GB again, or worse, retrieve a negative
>>>>>> file size for sizes between 2GB and 4GB.
>>>>>>
>>>>>>
>>>>>> To prepare for a 64bit move, you should replace all size variables with
>>>>>> size_t for unsigned or ptrdiff_t for signed. That will correspond to a
>>>>>> 32bit integer in 32 bit and a 64 bit integer in 64 bit.
>>>>>>
>>>>>>       Christian
>>>>>
>>>>> Done.  With checking against SIZE_MAX before casting the variable to size_t.
>>>>
>>>> Why?   size_t is guaranteed to hold the size of any object, which implies that
>>>> it must be large enough to accomodate an object the size of the virtual address
>>>> space.   Generally it's minimum size in bits is the same as long.
>>>
>>> That's likely to be true, but it's not absolutely guaranteed.
>>
>> My apologies, I was wrong.
>>
>>> size_t is intended to hold the size of any single object, but it may
>>> not be able to hold the sum of sizes of all objects or the size of
>>> the virtual address space.  An implementation might restrict the
>>> size of any single object to something smaller than the size of
>>> the entire virtual address space.  (Think segments.)
>>
>> I believe this is still correct.
>>
>>> Also, I haven't found anything in the standard that says you
>>> can't at least try to create an object bigger than SIZE_MAX bytes.
>>> calloc(SIZE_MAX, 2) attempts to allocate such an object, and I don't
>>> see a requirement that it must fail.  If an implementation lets you
>>> define a named object bigger than SIZE_MAX bytes, then presumably
>>> applying sizeof to it would result in an overflow, and therefore
>>> undefined behavior.
>>>
>>> Any reasonable implementation will simply make size_t big enough
>>> to hold the size of any object it can create, but I don't see a
>>> requirement for it.
>>
>> The above is correct in C, but not in C++, which makes an additional
>> guarantee that C doesn't.  C++17 21.2.4 [support.types.layout] says:
>>
>>      The type size_t is an implementation-defined unsigned integer type
>>      that is large enough to contain the size in bytes of any object
>>      (8.3.3).
>
> Except the actual size of a FILE * object in the filesystem.  Size_t
> can hold the size of the FILE * structure but if the actual file size
> is greater than 4 GB in a Win32 program, size_t will be wrong.

A FILE* object is a pointer, likely 4 or 8 bytes.  A FILE object is
probably a struct, 216 bytes on my system.

> Now if the program is Win64, size_t can hold the actual size of any
> file in the filesystem.
>
> #ifdef _WIN64
>     typedef unsigned __int64 size_t;
>     typedef __int64          ptrdiff_t;
>     typedef __int64          intptr_t;
> #else
>     typedef unsigned int     size_t;
>     typedef int              ptrdiff_t;
>     typedef int              intptr_t;
> #endif

size_t isn't for representing sizes of files, which are not objects.
In fact C doesn't define a type for representing file sizes.
(It might be nice if it did.)  ftell() returns a long, which is not
big enough on systems with 32-bit long (and reasonable file systems).
fgetpos gives you an fpos_t, which isn't necessarily an integer type.

You can use long long or unsigned long long, guaranteed to be at least
64 bits (or [u]int64_t, or [u]intmax_t).

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#79823

FromÖö Tiib <ootiib@hot.ee>
Date2021-05-27 18:36 -0700
Message-ID<664dd958-6042-4d5d-951c-191b0e26421dn@googlegroups.com>
In reply to#79816
On Friday, 28 May 2021 at 02:58:18 UTC+3, Keith Thompson wrote:
> In fact C doesn't define a type for representing file sizes. 
> (It might be nice if it did.)

Or may be it might be nice if it did take it back from C++ where
std::filesystem::file_size() is of type std::uintmax_t.
Also standard should end the woo allowing implementations to
have integers that are not integers. It is awful.

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

#79831

FromLynn McGuire <lynnmcguire5@gmail.com>
Date2021-05-27 21:38 -0500
Message-ID<s8pl3n$dmt$1@dont-email.me>
In reply to#79823
On 5/27/2021 8:36 PM, Öö Tiib wrote:
> On Friday, 28 May 2021 at 02:58:18 UTC+3, Keith Thompson wrote:
>> In fact C doesn't define a type for representing file sizes.
>> (It might be nice if it did.)
> 
> Or may be it might be nice if it did take it back from C++ where
> std::filesystem::file_size() is of type std::uintmax_t.
> Also standard should end the woo allowing implementations to
> have integers that are not integers. It is awful.

For some reason, Microsoft is using __int64.  Not my favorite variable 
type.  Even "long long" is better (and the same) imho.   __int64 
_ftelli64 (FILE *stream);
 
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/ftell-ftelli64?view=msvc-160

Apparently no one else is using _ftelli64.  This sucks.
    https://www.vogons.org/viewtopic.php?t=65070

Lynn

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

#79845

FromPaavo Helde <myfirstname@osa.pri.ee>
Date2021-05-28 08:53 +0300
Message-ID<s8q0g1$uvm$1@dont-email.me>
In reply to#79831
28.05.2021 05:38 Lynn McGuire kirjutas:
> On 5/27/2021 8:36 PM, Öö Tiib wrote:
>> On Friday, 28 May 2021 at 02:58:18 UTC+3, Keith Thompson wrote:
>>> In fact C doesn't define a type for representing file sizes.
>>> (It might be nice if it did.)
>>
>> Or may be it might be nice if it did take it back from C++ where
>> std::filesystem::file_size() is of type std::uintmax_t.
>> Also standard should end the woo allowing implementations to
>> have integers that are not integers. It is awful.
> 
> For some reason, Microsoft is using __int64.  Not my favorite variable 
> type.  Even "long long" is better (and the same) imho.   __int64 
> _ftelli64 (FILE *stream);
> 
> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/ftell-ftelli64?view=msvc-160 

In C++ we have std::int64_t.

> 
> Apparently no one else is using _ftelli64.  This sucks.

I'm using _filelengthi64() in some places. Less hassle than with seek/tell.

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

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

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

csiph-web