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

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

Type conversion for hundreds of lines

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

Contents

  Type conversion for hundreds of lines JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-12 23:48 +0300
    Re: Type conversion for hundreds of lines JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-12 23:54 +0300
      Re: Type conversion for hundreds of lines JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-12 23:55 +0300
        Re: Type conversion for hundreds of lines Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-12 23:26 +0100
          Re: Type conversion for hundreds of lines JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-13 07:30 +0300
            Re: Type conversion for hundreds of lines Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-13 12:19 +0100
      Re: Type conversion for hundreds of lines Paavo Helde <eesnimi@osa.pri.ee> - 2022-10-13 00:37 +0300
        Re: Type conversion for hundreds of lines JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-13 07:34 +0300
          Re: Type conversion for hundreds of lines Paavo Helde <eesnimi@osa.pri.ee> - 2022-10-13 11:43 +0300
    Re: Type conversion for hundreds of lines Paavo Helde <eesnimi@osa.pri.ee> - 2022-10-13 00:27 +0300
      Re: Type conversion for hundreds of lines JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-13 07:24 +0300
        Re: Type conversion for hundreds of lines Paavo Helde <eesnimi@osa.pri.ee> - 2022-10-13 12:00 +0300
          Re: Type conversion for hundreds of lines JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-13 20:27 +0300
        Re: Type conversion for hundreds of lines David Brown <david.brown@hesbynett.no> - 2022-10-13 11:17 +0200
          Re: Type conversion for hundreds of lines JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-13 20:32 +0300
            Re: Type conversion for hundreds of lines Paavo Helde <eesnimi@osa.pri.ee> - 2022-10-13 21:13 +0300
              Re: Type conversion for hundreds of lines JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-13 21:28 +0300
            Re: Type conversion for hundreds of lines David Brown <david.brown@hesbynett.no> - 2022-10-13 23:10 +0200
            Re: Type conversion for hundreds of lines Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-10-13 22:36 +0100
              Re: Type conversion for hundreds of lines JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-14 07:29 +0300
    Re: Type conversion for hundreds of lines scott@slp53.sl.home (Scott Lurndal) - 2022-10-12 21:27 +0000
      Re: Type conversion for hundreds of lines JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-13 07:25 +0300
    Re: Type conversion for hundreds of lines Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-10-12 14:30 -0700
      Re: Type conversion for hundreds of lines JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-13 07:28 +0300
        Re: Type conversion for hundreds of lines "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-12 21:30 -0700
          Re: Type conversion for hundreds of lines JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-13 07:37 +0300
            Re: Type conversion for hundreds of lines "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-13 14:18 -0700
              Re: Type conversion for hundreds of lines JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-14 00:27 +0300
                Re: Type conversion for hundreds of lines "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-14 00:33 -0700
    Re: Type conversion for hundreds of lines Juha Nieminen <nospam@thanks.invalid> - 2022-10-13 07:52 +0000
      Re: Type conversion for hundreds of lines JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-13 20:35 +0300
    Re: Type conversion for hundreds of lines Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-14 01:43 -0700

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

#86890

JiiPee <kerrttuPoistaTama11@gmail.com> writes:
>I have been pondering this many times. I keep it short:
>If I have hundreds of lines like this:
>
>short a;
>std::vector<int> v;
>...
>a = v.size();
>
>This gives a warning: "warning, assigning size_t to short".
>I know this can be fixed:
>a = static_cast<short>(v.size());

so declare 'a' as size_t. Problem fixed.

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

#86903

On 13/10/2022 00:27, Scott Lurndal wrote:
> JiiPee <kerrttuPoistaTama11@gmail.com> writes:
>> I have been pondering this many times. I keep it short:
>> If I have hundreds of lines like this:
>>
>> short a;
>> std::vector<int> v;
>> ...
>> a = v.size();
>>
>> This gives a warning: "warning, assigning size_t to short".
>> I know this can be fixed:
>> a = static_cast<short>(v.size());
> 
> so declare 'a' as size_t. Problem fixed.

but if in hundreds of places, that would cause othe problems... and 
needs a lot of testing? you would still do it? but the probram should be 
then tested and check it does not cause other side issues.

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

#86891

JiiPee <kerrttuPoistaTama11@gmail.com> writes:
> I have been pondering this many times. I keep it short:
> If I have hundreds of lines like this:
>
> short a;
> std::vector<int> v;
> ...
> a = v.size();
>
> This gives a warning: "warning, assigning size_t to short".
> I know this can be fixed:
> a = static_cast<short>(v.size());
>
> but if we have hundreds of those lines, how would you fix this? Place
> a static cast in all of them? Of create some helper funktion to do
> this?

Why is `a` defined as a short and not as a size_t?

If there's a very good reason that `a` *needs* to be a short, it makes
sense to consider some kind of cast.  If not, just make it a size_t.

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

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

#86904

On 13/10/2022 00:30, Keith Thompson wrote:
> Why is `a` defined as a short and not as a size_t?
> 
> If there's a very good reason that `a`*needs*  to be a short, it makes
> sense to consider some kind of cast.  If not, just make it a size_t.


Lets assume its some old code... for example from 80's... and you have 
it now. Would you do this change to hundreds of places, to change a to 
size_t? But that might cause sides issues, isnt it? What if the other 
code is relying on the short, and for example takes sizeof() of the 
short when storing to a file.

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

#86906

On 10/12/2022 9:28 PM, JiiPee wrote:
> On 13/10/2022 00:30, Keith Thompson wrote:
>> Why is `a` defined as a short and not as a size_t?
>>
>> If there's a very good reason that `a`*needs*  to be a short, it makes
>> sense to consider some kind of cast.  If not, just make it a size_t.
> 
> 
> Lets assume its some old code... for example from 80's... and you have 
> it now. Would you do this change to hundreds of places, to change a to 
> size_t? But that might cause sides issues, isnt it? What if the other 
> code is relying on the short, and for example takes sizeof() of the 
> short when storing to a file.

Is the code busted as-is using a short? Do you actually _need_ to change 
short to size_t? Warnings aside for a moment...

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

#86908

On 13/10/2022 07:30, Chris M. Thomasson wrote:
> Do you actually _need_ to change short to size_t? Warnings aside for a 
> moment...

Good question. No, not necessarily... its only a warning in a compiler.
But.. obviously if the compiler is warning alot then better to check all 
those warnings, isnt it? At least check all of them... but are you 
saying I do not need to change anything, just leave the warnings there? 
Just check the code, and if its OK then just not minding the warnings 
rather than change hundreds of places?

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

#86935

On 10/12/2022 9:37 PM, JiiPee wrote:
> On 13/10/2022 07:30, Chris M. Thomasson wrote:
>> Do you actually _need_ to change short to size_t? Warnings aside for a 
>> moment...
> 
> Good question. No, not necessarily... its only a warning in a compiler.
> But.. obviously if the compiler is warning alot then better to check all 
> those warnings, isnt it? At least check all of them... but are you 
> saying I do not need to change anything, just leave the warnings there? 
> Just check the code, and if its OK then just not minding the warnings 
> rather than change hundreds of places?

Well, is using short an actual source of real bugs in the original code 
base? Please, define "not necessarily"? I was under the impression that 
this is "legacy" code, so to speak. Your compiler might have a way to 
suppress certain warnings. Let's say, you know that the code works 
as-is, period. So, the warnings are not worth your time. Therefore, 
artificially suppress them.

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

#86936

On 14/10/2022 00:18, Chris M. Thomasson wrote:
> So, the warnings are not worth your time. Therefore, artificially 
> suppress them.

yes this is something to consider.
Then in new code can focus making it warning free.

"Please, define "not necessarily"?"

I mean, likely the code does not need change. so its only a warning 
coming but does not need action.

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

#86950

On 10/13/2022 2:27 PM, JiiPee wrote:
> On 14/10/2022 00:18, Chris M. Thomasson wrote:
>> So, the warnings are not worth your time. Therefore, artificially 
>> suppress them.
> 
> yes this is something to consider.
> Then in new code can focus making it warning free.
> 
> "Please, define "not necessarily"?"
> 
> I mean, likely the code does not need change. so its only a warning 
> coming but does not need action.

Can you isolate the code in a shared or static library with an API 
interface and label it version_original or something? Perhaps, stuff it 
under its own namespace?

There are some tricks wrt introducing new functions on existing code in C.

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

#86910

JiiPee <kerrttuPoistaTama11@gmail.com> wrote:
> I have been pondering this many times. I keep it short:
> If I have hundreds of lines like this:
> 
> short a;
> std::vector<int> v;
> ...
> a = v.size();
> 
> This gives a warning: "warning, assigning size_t to short".
> I know this can be fixed:
> a = static_cast<short>(v.size());
> 
> but if we have hundreds of those lines, how would you fix this? Place a 
> static cast in all of them? Of create some helper funktion to do this?

Explicitly saying "static_cast<short>(...)" kind of indicates that you
are saying "yes, I'm fully aware that the value inside the parentheses
technically speaking may be larger than fits in a short, but I know
that it never will in this particular code, so this assignment is done
intentionally and it's not just an oversight (and yes, I am doing this
even knowing the risk that it could potentially cause a bug in the
future)".

So, in a manner of speaking, it's self-documenting code. Thus, I would
use that.

However, if you want to safeguard against that possible future bug,
you could use a function instead, and add a check in the function
(for example an assert(), or possibly a throw), unless this is a
very time-critical code (which I assume it isn't).

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

#86930

On 13/10/2022 10:52, Juha Nieminen wrote:
> So, in a manner of speaking, it's self-documenting code. Thus, I would
> use that.

I was thinking the same.

> 
> However, if you want to safeguard against that possible future bug,
> you could use a function instead, and add a check in the function
> (for example an assert(), or possibly a throw), unless this is a
> very time-critical code (which I assume it isn't).

yes like other also said, function more accurate. So Currently I kinda 
lean on the function solution.

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

#86952

On Wednesday, October 12, 2022 at 9:49:01 PM UTC+1, JiiPee wrote:

> This gives a warning: "warning, assigning size_t to short". 
> I know this can be fixed: 
> a = static_cast<short>(v.size()); 
> 
> but if we have hundreds of those lines, how would you fix this? Place a 
> static cast in all of them? Of create some helper funktion to do this? 


Try this regex:

    https://regex101.com/r/5tsXx3/1

[toc] | [prev] | [standalone]

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

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

csiph-web