Hi ,

I am wondering if a SCL vendor implementation must be POSIX compliant (ie
not using a non-posix feature like stricmp)

I have some C++ code which is POSIX (1) compliant. This code is using some
STL from a vendor X but sometime this implementatin use non-posix feature.
and so my compilation stage failed.

Thank in advance,

~Xavier



---
[ 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.research.att.com/~austern/csc/faq.html                ]

Xavier Huet wrote:

> I am wondering if a SCL vendor implementation must be POSIX compliant (ie
> not using a non-posix feature like stricmp)
>
> I have some C++ code which is POSIX (1) compliant. This code is using some
> STL from a vendor X but sometime this implementatin use non-posix feature.
> and so my compilation stage failed.

The C++ standard library doesn't address what underlying operating system
features it is built upon.  It need not be POSIX.  It's really not even
supposed to matter to you.  In my opinion, there's no real provision for
the library to be seperated from the rest of the "implementation."

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Ron Natalie" <ron@sensor.com> wrote in message
news:3C615D1C.792FEEA6@sensor.com...
>
>
> Xavier Huet wrote:
>
> > I am wondering if a SCL vendor implementation must be POSIX compliant
(ie
> > not using a non-posix feature like stricmp)
> >
> > I have some C++ code which is POSIX (1) compliant. This code is using
some
> > STL from a vendor X but sometime this implementatin use non-posix
feature.
> > and so my compilation stage failed.
>
> The C++ standard library doesn't address what underlying operating system
> features it is built upon.  It need not be POSIX.  It's really not even
> supposed to matter to you.

I think that it's matter to me since a big parg of the std lib is template.
In fact,
I am the one that it's going to compile it (instantiation) and in most
compilers
it's my compilation options that are passed to the template instantiation.
And so if I am using -D_POSIX_SOURCE=1, this will be used during the
compilation
of the implementation of the std lib (not all , only what I use of course)
And so if the implementation is non-posix, I am directly impacted.

> In my opinion, there's no real provision for
> the library to be seperated from the rest of the "implementation."




---
[ 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.research.att.com/~austern/csc/faq.html                ]

Xavier Huet wrote:
>

> >
> > The C++ standard library doesn't address what underlying operating system
> > features it is built upon.  It need not be POSIX.  It's really not even
> > supposed to matter to you.
>
> I think that it's matter to me since a big parg of the std lib is template.

What does the fact that it is a template have to do with it?
If your implementation uses stricmp and doesn't take care of providing
it, the implementation is defective.  If you're building this implementation
up yourself (as I suspect you are), then you'll have to worry abou thtat
yourself, but your question was with regards to what implementations are
REQUIRED to do, and they are REQUIRED to implement what the standard says
and the standard doesn't say how that gets accomplished under the covers.

Including the POSIX include files inside the standard C++ includes is almost
certainly the WRONG way to go about.  Despite the fact that these are templates,
these calls should be wrapped in some symbol belonging to the implementation
and compiled elsewhere.

---
[ 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.research.att.com/~austern/csc/faq.html                ]