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

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

standard error messages in a std::string or in a const char *

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

Contents

  standard error messages in a std::string or in a const char * Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-11 00:35 +0200
    Re: standard error messages in a std::string or in a const char * Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-11 00:37 +0200
      Re: standard error messages in a std::string or in a const char * Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-09-11 08:28 +0000
        Re: standard error messages in a std::string or in a const char * Juha Nieminen <nospam@thanks.invalid> - 2019-09-11 08:58 +0000
          Re: standard error messages in a std::string or in a const char * Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-11 11:09 +0200
            Re: standard error messages in a std::string or in a const char * Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-11 11:37 +0200
          Re: standard error messages in a std::string or in a const char * Keith Thompson <kst-u@mib.org> - 2019-09-11 02:37 -0700
            Re: standard error messages in a std::string or in a const char * Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-11 11:47 +0200
              Re: standard error messages in a std::string or in a const char * Öö Tiib <ootiib@hot.ee> - 2019-09-11 04:43 -0700
                Re: standard error messages in a std::string or in a const char * James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-11 08:27 -0400
                  Re: standard error messages in a std::string or in a const char * Manfred <noname@add.invalid> - 2019-09-11 14:56 +0200
                    Re: standard error messages in a std::string or in a const char * Daniel <danielaparker@gmail.com> - 2019-09-11 07:00 -0700
            Re: standard error messages in a std::string or in a const char * Thiago Adams <thiago.adams@gmail.com> - 2019-09-11 09:44 -0700
            Re: standard error messages in a std::string or in a const char * Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-09-12 10:21 +0000
              Re: standard error messages in a std::string or in a const char * Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-12 13:05 +0200
          Re: standard error messages in a std::string or in a const char * Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-11 17:43 +0200
            Re: standard error messages in a std::string or in a const char * Paavo Helde <myfirstname@osa.pri.ee> - 2019-09-11 19:23 +0300
              Re: standard error messages in a std::string or in a const char * Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-11 19:19 +0200
                Re: standard error messages in a std::string or in a const char * Paavo Helde <myfirstname@osa.pri.ee> - 2019-09-11 20:32 +0300
                  Re: standard error messages in a std::string or in a const char * Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-12 13:08 +0200
                    Re: standard error messages in a std::string or in a const char * Thiago Adams <thiago.adams@gmail.com> - 2019-09-12 04:29 -0700
                      Re: standard error messages in a std::string or in a const char * Keith Thompson <kst-u@mib.org> - 2019-09-12 14:41 -0700
                Re: standard error messages in a std::string or in a const char * Thiago Adams <thiago.adams@gmail.com> - 2019-09-11 10:39 -0700
                Re: standard error messages in a std::string or in a const char * James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-11 19:50 -0400
                  Re: standard error messages in a std::string or in a const char * Keith Thompson <kst-u@mib.org> - 2019-09-11 17:11 -0700
                    Re: standard error messages in a std::string or in a const char * James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-11 20:23 -0400
                      Re: standard error messages in a std::string or in a const char * David Brown <david.brown@hesbynett.no> - 2019-09-12 11:21 +0200
                        Re: standard error messages in a std::string or in a const char * James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-12 07:31 -0400
                          Re: standard error messages in a std::string or in a const char * Manfred <noname@add.invalid> - 2019-09-12 15:44 +0200

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

#68361

On Thursday, September 12, 2019 at 8:08:46 AM UTC-3, Soviet_Mario wrote:
...
> ahhhh ! Got it. Strangely I had included the (useless) 
> <cerrno> but not completely consciously, and did not include 

C++ standard is creating differences from the same C header. 

For instance:
C++ <cerrno> defines a lot of POSIX error codes.
"E2BIG, EACCES, ..., EXDEV"
https://en.cppreference.com/w/cpp/error/errno_macros

And C defines only EDOM, EILSEQ and ERANGE
https://en.cppreference.com/w/c/error/errno_macros

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

#68371

Thiago Adams <thiago.adams@gmail.com> writes:
> On Thursday, September 12, 2019 at 8:08:46 AM UTC-3, Soviet_Mario wrote:
> ...
>> ahhhh ! Got it. Strangely I had included the (useless) 
>> <cerrno> but not completely consciously, and did not include 
>
> C++ standard is creating differences from the same C header. 
>
> For instance:
> C++ <cerrno> defines a lot of POSIX error codes.
> "E2BIG, EACCES, ..., EXDEV"
> https://en.cppreference.com/w/cpp/error/errno_macros
>
> And C defines only EDOM, EILSEQ and ERANGE
> https://en.cppreference.com/w/c/error/errno_macros

The C standard only requires EDOM, EILSEQ, and ERANGE, but C
implementations can, and commonly do, define additional macros.

Both C and POSIX specifically permit additional E* macros to
be defined.  I don't see such a permission in the C++ standard,
though I could be missing it.

(I'm a little surprised C++ mandates the POSIX error codes, given
that C++ can be implemented on non-POSIX systems.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#68340

On Wednesday, September 11, 2019 at 2:20:07 PM UTC-3, Soviet_Mario wrote:
> Il 11/09/19 18:23, Paavo Helde ha scritto:
> > On 11.09.2019 18:43, Soviet_Mario wrote:
> >>
> >> but my main problem is : even including all possible 
> >> headers, QT IDE
> >> does not see strerror prototype.
> > 
> > "All possible headers" are not needed, man strerror clearly 
> > says it is declared in <string.h>.
> > 
> 
> thanks a lot.
> I included C++ like headers, among them "plain" <string>
> and guess what ?
> the C++ header DONT have a strerror prototype.
> But later I replaced that header with the C-like you 
> suggested, and exploring the code I found the prototype.
> 
> Many thanks Paavo !
> 
> -- 
> 1) Resistere, resistere, resistere.
> 2) Se tutti pagano le tasse, le tasse le pagano tutti
> Soviet_Mario - (aka Gatto_Vizzato)

You can create our own thread safe function replacing strerror.

int main(void)
{
  printf("const char* mystrerror(int i){\n");
  printf("  switch(i) {\n");
  for (int i = 0; i < 134; i++)
  {
    printf("    case %d: return \"%s\";\n", i, strerror(i));
  }
  printf("  }\n");
  printf("  return \"Unknown error\";\n");
  printf("}");
}

I did this for curiosity in windows and linux.
Window prints  "Unknown error" error >= 43
Linux prints "Unknown error 134" error >= 134

I also printed side by side. (I think is to big to put here)
There are some diferences for instance:

Linux | Windows
7 Argument list too long | Arg list too long 
35 Resource deadlock avoided | Unknown error 

etc..

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

#68344

On 9/11/19 1:19 PM, Soviet_Mario wrote:
> Il 11/09/19 18:23, Paavo Helde ha scritto:
>> On 11.09.2019 18:43, Soviet_Mario wrote:
>>>
>>> but my main problem is : even including all possible 
>>> headers, QT IDE
>>> does not see strerror prototype.
>>
>> "All possible headers" are not needed, man strerror clearly 
>> says it is declared in <string.h>.
>>
> 
> thanks a lot.
> I included C++ like headers, among them "plain" <string>
> and guess what ?
> the C++ header DONT have a strerror prototype.

The C++ header <string.h> has essentially the same contents as the C
header of the same name. The C++ header <cstring> differs from
<string.h> mainly in that the functions are declared inside the std::
namespace.

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

#68345

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
> The C++ header <string.h> has essentially the same contents as the C
> header of the same name. The C++ header <cstring> differs from
> <string.h> mainly in that the functions are declared inside the std::
> namespace.

<string.h> defines strerror and other identifiers in the global
namespace, and may optionally define them in the std namespace, while
<cstring> defines them in the std namespace and may optionally define
them in the global namespace.

(I dislike this, but that's the way the language specifies it.)

Also, the <*.h> C headers are deprecated as of C++17.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#68346

On 9/11/19 8:11 PM, Keith Thompson wrote:
...
> Also, the <*.h> C headers are deprecated as of C++17.

I hadn't noticed that.

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

#68356

On 12/09/2019 02:23, James Kuyper wrote:
> On 9/11/19 8:11 PM, Keith Thompson wrote:
> ...
>> Also, the <*.h> C headers are deprecated as of C++17.
> 
> I hadn't noticed that.
> 

It is not going to make any practical difference, as any real-world C++
implementation also supports C, and has the C headers.  I guess the aim
is to move C++ programmers to use the std:: namespace for standard C
functions as much as possible, reducing the global namespace usage.

I don't know how that works for macros defined in C standard headers -
they can't go into a namespace.

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

#68362

On 9/12/19 5:21 AM, David Brown wrote:
> On 12/09/2019 02:23, James Kuyper wrote:
>> On 9/11/19 8:11 PM, Keith Thompson wrote:
>> ...
>>> Also, the <*.h> C headers are deprecated as of C++17.
>>
>> I hadn't noticed that.
>>
> 
> It is not going to make any practical difference, as any real-world C++
> implementation also supports C, and has the C headers. ...

If they're deprecated now, it's a warning that they may be removed in
the future. If they are removed someday, that will give implementations
permission to no longer provide them, and sooner or later an
implementation will be created that doesn't. That date might be a long
time coming, but when it does, it will mark a major step in the
separation of C++ from C.

> ...  I guess the aim
> is to move C++ programmers to use the std:: namespace for standard C
> functions as much as possible, reducing the global namespace usage.
> 
> I don't know how that works for macros defined in C standard headers -
> they can't go into a namespace.

How it works is that they don't go in a namespace.

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

#68363

On 9/12/2019 1:31 PM, James Kuyper wrote:
> On 9/12/19 5:21 AM, David Brown wrote:
>> On 12/09/2019 02:23, James Kuyper wrote:
>>> On 9/11/19 8:11 PM, Keith Thompson wrote:
>>> ...
>>>> Also, the <*.h> C headers are deprecated as of C++17.
>>>
>>> I hadn't noticed that.
>>>
>>
>> It is not going to make any practical difference, as any real-world C++
>> implementation also supports C, and has the C headers. ...
> 
> If they're deprecated now, it's a warning that they may be removed in
> the future. If they are removed someday, that will give implementations
> permission to no longer provide them, and sooner or later an
> implementation will be created that doesn't. That date might be a long
> time coming, but when it does, it will mark a major step in the
> separation of C++ from C.
> 
>> ...  I guess the aim
>> is to move C++ programmers to use the std:: namespace for standard C
>> functions as much as possible, reducing the global namespace usage.
>>
>> I don't know how that works for macros defined in C standard headers -
>> they can't go into a namespace.
> 
> How it works is that they don't go in a namespace.
> 

Which is not really working, IMVVHO - I mean they compile and do the 
job, but you end up with a mixture of std:: and non-std-qualified names 
which I find ungood at best.
How bad it is varies from one implementation to one other, though.

[toc] | [prev] | [standalone]

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

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

csiph-web