Frederick Gotham ha scritto:
> Alberto Ganesh Barbati posted:
>
>> BTW, I won't use C-style casts, but
>> would prefer functional casts:
>>
>>   unsigned CalculateHoursWorked( unsigned long wages, unsigned
>>   hourly_wage ) {
>>     return unsigned(wages / hourly_wage);
>>   }
>
>
> They're exactly the same. A "functional cast" doesn't act as an implicit
> conversion, nor as a static_cast -- it has all the power of a C-style cast.
> Compile this:
>
> int main()
> {
>     char c;
>
>     unsigned(&c);
> }
>
>

I know, as I clearly state in another post of mine title "functional
cast notation" of two days ago. In this case it was just a style issue.

Ganesh

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

===================================== MODERATOR'S COMMENT:

Please try to keep follow-ups topical for comp.std.c++, and redirect more general discussions of programming technique to more suitable forums.


===================================== END OF MODERATOR'S COMMENT

Although a particular program may compile without error, the compiler may
specify a few warnings.

There are times when programming in C++ where it would be pertinent (even
convenient) that the compiler issue a warning, for example:

    int &ArbitraryFunc()
    {
        int i = 7;

        return i;
    }

    WARNING: Returning reference to local variable.


or:


    int ArbitraryFunc()
    {
        int i;
    }

    WARNING: Function has no return statement.


There are times when programming in C++ however that the programmer
intentionally performs an action which the compiler will warn about, but
the programmer has acted deliberately and doesn't want to be warned.
Here's a good example:

    unsigned CalculateHoursWorked( unsigned long wages, unsigned
hourly_wage )
    {
        return wages / hourly_wage;
    }


    WARNING: Truncation from unsigned long int to unsigned int

Imagine that this function is part of a program which is to be compiled
for a multitude of different machines, and so it will be churned through
several different compilers --

Unnecessary warnings from a compiler just constitute clutter, and so
they're best done away with.

However, the C++ Standard doesn't specify any way in which the programmer
can make their intentions clear to the compiler.

Presently, I myself solve the problem with:


    unsigned CalculateHoursWorked( unsigned long wages, unsigned
hourly_wage )
    {
        return (unsigned)(wages / hourly_wage);
        /* Cast to supress truncation warning */
    }


But that isn't what casts are for.

Is there a general consensus on how this problem should be handled? Do
the vast majority of proficient programmers simplictly use a cast to
supress the warning?


--

Frederick Gotham

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Frederick Gotham ha scritto:
>
>     unsigned CalculateHoursWorked( unsigned long wages, unsigned
> hourly_wage )
>     {
>         return (unsigned)(wages / hourly_wage);
>         /* Cast to supress truncation warning */
>     }
>
>
> But that isn't what casts are for.

I disagree. That's precisely what cast are there for: to explictly
convert the type of an expression. BTW, I won't use C-style casts, but
would prefer functional casts:

  unsigned CalculateHoursWorked( unsigned long wages, unsigned hourly_wage )
  {
    return unsigned(wages / hourly_wage);
  }

but that's just personal style (and you can't use it for two-keyword
types, I know). I can't think of a more compact way to clearly indicate
my intent. So why should I look for a different solution? Can you
propose a warning-suppression notation/syntax that is able to do the
same with merely three additional tokens? The Lint notation is perhaps
the only one that can compete with this approach:

  unsigned CalculateHoursWorked( unsigned long wages, unsigned hourly_wage )
  {
    return wages / hourly_wage; //lint !e712
  }

Although I find lint to be a wonderful product, it's quite complex and
difficult to master, so I don't believe it can be taken as general
solution to the problem.

> Is there a general consensus on how this problem should be handled? Do
> the vast majority of proficient programmers simplictly use a cast to
> supress the warning?

I can't speak about the programming style of the vast majority ;)

Anyway that's not something that can be solved at the C++ language
level. There is a very simple reason for that: warnings do *not* exist
in the C++ language. Yes, you read well. The Holy Standard requires the
compiler to issue diagnostics *only* when the program is ill-formed and
not even in every case. A warning is a hint, kindly provided by the
compiler, that says: "hey, the program is well-formed, but looks
suspicious". The compiler is not required to say that. Notice that even
in front of the two examples in the OP "Returning reference to local
variable" and "Function has no return statement" the compiler is not
required to issue a diagnostic. That's because they are examples of
undefined behaviour, not ill-formedness.

So in order to solve the problem at the language level, you need the
amend the standard to:

1) define what a warning is
2) provide a list of all "required" warnings
3) describe when each "required" warning must be issued
4) provide a way to selectively suppress the undesired warnings, which
is descriptive enough to cope with common-day needs and at the same time
that is compellingly better than requiring the programmer to tweak the code

If you want an idea of how big this work is, you should have a look at
the lint manual (367 pages). Of course, one need not be that
comprehensive, yet it looks like a huge amount of effort to me. I
believe the committee can spend its time better on more serious issues
and leave this task to tools developers, as it is now. That is a field
where a bit of competition is good for the end-user (that is, us
programmers) ;)

Just my opinion.

Ganesh

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Frederick Gotham" <fgothamNO@SPAM.com> wrote in message
news:Xns97E4ABC38CB52fgothamNOSPAM@194.125.133.14...
[...]
> Unnecessary warnings from a compiler just constitute clutter, and so
> they're best done away with.

There is no such thing as unnecessary warnings. Either a compiler is poorly
designed, or all warnings are warranted. I think what you are trying to say is
that inability to explicitly express constraints in the language cause compiler
to issue a warning about a potential problem, which in the presence of
constraints can never materialize.

>
> However, the C++ Standard doesn't specify any way in which the programmer
> can make their intentions clear to the compiler.
>
> Presently, I myself solve the problem with:
>
>
>    unsigned CalculateHoursWorked( unsigned long wages, unsigned
> hourly_wage )
>    {
>        return (unsigned)(wages / hourly_wage);
>        /* Cast to supress truncation warning */
>    }
>
>
> But that isn't what casts are for.

Not really, casts are for doing conversions explicitly, even when there is an
implicit conversion. A well behaved compiler provides you with warnings when it
has to perform dangerous stuff implicitly. Casts make your intentions explicit,
so a good compiler will shut up and let you break your neck if you choose to. I
don't see any logical problems with that.

--
Gene Bushuyev (www.gbresearch.com)
----------------------------------------------------------------
To see what is in front of one's nose needs a constant struggle ~ George Orwell

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

* Gene Bushuyev:
> "Frederick Gotham" <fgothamNO@SPAM.com> wrote in message=20
> news:Xns97E4ABC38CB52fgothamNOSPAM@194.125.133.14...
> [...]
>> Unnecessary warnings from a compiler just constitute clutter, and so
>> they're best done away with.
>=20
> There is no such thing as unnecessary warnings.

There are.  They're called silly-warnings.  One of the most annoying is=20
a warning that serves to make code macro-oriented, e.g.

   #ifdef NDEBUG
   bool const debugVersion =3D false;
   #else
   bool const debugVersion =3D true;
   #endif

   if( debugVersion ) { trace( "M=E5ker har en eminent flyveteknikk" ); }

   * Warning: unreachable code
   * Warning: boolean expression is constant
   * Warning: code will always be executed

Another very annoying silly-warning is about a local object not being use=
d:

   ScopeGuard deallocation =3D CreateGuard( &Deallocate, p );

   * Warning: local variable declared but not used

As these two examples show, casts are not a general solution to the=20
silly-warning problem.

The last example is a case where different compilers offer different=20
/language extensions/ to avoid the warning, in addition to their=20
language extensions for general warning suppression.  One might argue=20
that a compiler should be smart enough to understand that a non-trivial=20
destructor means the object is not unused.  But the existence of various=20
language extensions seems to indicate that that argument is simplistic,=20
and that for at least this situation some language support would be nice.


 > Either a compiler is poorly designed, or all warnings are warranted.

Nope.  A compiler is not a small toy program.  Parts of it can be poorly=20
designed, without the whole compiler being poorly designed.

--=20
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Alberto Ganesh Barbati posted:

> BTW, I won't use C-style casts, but
> would prefer functional casts:
>
>   unsigned CalculateHoursWorked( unsigned long wages, unsigned
>   hourly_wage ) {
>     return unsigned(wages / hourly_wage);
>   }


They're exactly the same. A "functional cast" doesn't act as an implicit
conversion, nor as a static_cast -- it has all the power of a C-style cast.
Compile this:

int main()
{
    char c;

    unsigned(&c);
}


--

Frederick Gotham

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]