c++.command-line - -wc is too good
- Matthew (17/17) Feb 14 2005 Walter
-
Walter
(3/8)
Feb 24 2005
Suppression pragmas? Uggh.
- Matthew (3/14) Feb 24 2005 So what's the answer?
- Walter (4/20) Feb 27 2005 I'd rather not. Switches to turn warnings on, pragmas to turn them off -...
- Matthew (5/31) Feb 27 2005 Ok. The alternative is to fix the C-style casts in the DMC++ headers.
- Walter (3/10) Feb 28 2005 Sure.
- Matthew (3/16) Feb 28 2005 Cool. I'll stick it on the to-do. ;)
- Matthew (57/69) Mar 23 2005 string.h, lines 312-324
- Matthew (8/8) Mar 23 2005 stlport/stl/_algobase.h
- Matthew (6/18) Mar 23 2005 stlport/stl/_uninitialized.h
- Matthew (4/16) Mar 23 2005 stlport/stl/_string.h
- Matthew (17/17) Mar 23 2005 assert.h
- Matthew (4/16) Mar 23 2005 stlport/stl/_ios_base.h
- Matthew (25/37) Mar 23 2005 stlport/stl/_string.c
- Matthew (11/23) Mar 23 2005 stddef.h
- Matthew (7/18) Mar 23 2005 Interestingly, we need to use const in there. :-)
- Matthew (5/17) Mar 23 2005 stlport/stl/_iterator_base.h
- Matthew (4/16) Mar 23 2005 stlport/stl/_algobase.h
- Matthew (4/16) Mar 23 2005 stlport/stl/_alloc.h
- Matthew (7/19) Mar 23 2005 stlport/stl/char_traits.h
- Matthew (5/17) Mar 23 2005 stlport/stl/_string.h
- Matthew (9/21) Mar 23 2005 stlport/stl/_string.h
- Matthew (6/18) Mar 23 2005 stlport/stl/_list.c
- Matthew (13/25) Mar 23 2005 stlport/stl/_list.h
- Matthew (8/19) Mar 23 2005 stlport/stl/char_traits.h
- Matthew (6/18) Mar 23 2005 stlport/stl/_ios.h
- Matthew (5/5) Mar 23 2005 stlport/stl/_ctype.h
- Matthew (7/7) Mar 23 2005 stlport/stl/_limits.h
- Matthew (3/3) Mar 23 2005 stlport/stl/_ostream.c
- Matthew (23/23) Mar 23 2005 stlport/stl/_istream.c
- Matthew (3/3) Mar 23 2005 stlport/stl/_ios.c
- Matthew (33/33) Mar 23 2005 Last one: stdarg.h
- Matthew (3/3) Mar 23 2005 stlport/stl/_algobase.h
- Matthew (7/7) Mar 23 2005 stlport/stl/_vector.h
- Matthew (6/6) Mar 23 2005 stlport/stl/_fstream.h
- Matthew (5/5) Mar 23 2005 stlport/stl/_fstream.c
- Matthew (7/7) Mar 23 2005 stlport/stl/_bvector.h
- Matthew (37/37) Mar 23 2005 stlport/stl/_num_put.c
- Matthew (10/10) Mar 23 2005 stlport/stl/_vector.c
- Matthew (2/2) Mar 23 2005 Again, most of the ones were in STLport. A couple of useful things raise...
- Matthew (2/2) Mar 23 2005 No changes needed over and above those for recls and b64, apart from in ...
- Matthew (19/19) Mar 27 2005 WinSock.h
- Matthew (11/11) Mar 27 2005 WinError.h
- Matthew (11/22) Mar 27 2005 Also
- Matthew (2/27) Mar 27 2005 Spoke too soon. The sc in "# define _HRESULT_TYPEDEF_(_sc) static_cast...
- Matthew (9/20) Mar 27 2005 More:
- Matthew (19/19) Mar 27 2005 I'm now working through compilation of all the Synesis Software headers....
Walter
I know I was the one who asked for it, but it's _too_ effective. Or, at
least, is there a suppression pragma, and, if so, can you arrange to
have that specified in the DMC++ header files?
<G>
--
Matthew Wilson
Author: "Imperfect C++", Addison-Wesley, 2004
(http://www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
(http://www.synesis.com.au/articles.html#columns)
STLSoft moderator
(http://www.stlsoft.org)
"I can't sleep nights till I found out who hurled what ball through what
apparatus" -- Dr Niles Crane
-------------------------------------------------------------------------------
Feb 14 2005
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:cuppnc$84h$1 digitaldaemon.com...Walter I know I was the one who asked for it, but it's _too_ effective. Or, at least, is there a suppression pragma, and, if so, can you arrange to have that specified in the DMC++ header files? <G>Suppression pragmas? Uggh. <g>
Feb 24 2005
"Walter" <newshound digitalmars.com> wrote in message news:cvmcdp$2qt3$1 digitaldaemon.com..."Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:cuppnc$84h$1 digitaldaemon.com...So what's the answer?Walter I know I was the one who asked for it, but it's _too_ effective. Or, at least, is there a suppression pragma, and, if so, can you arrange to have that specified in the DMC++ header files? <G>Suppression pragmas? Uggh. <g>
Feb 24 2005
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:cvmgdk$2ut2$1 digitaldaemon.com..."Walter" <newshound digitalmars.com> wrote in message news:cvmcdp$2qt3$1 digitaldaemon.com...I'd rather not. Switches to turn warnings on, pragmas to turn them off - I don't think there's much to be gained here that's worth the complexity."Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:cuppnc$84h$1 digitaldaemon.com...So what's the answer?Walter I know I was the one who asked for it, but it's _too_ effective. Or, at least, is there a suppression pragma, and, if so, can you arrange to have that specified in the DMC++ header files? <G>Suppression pragmas? Uggh. <g>
Feb 27 2005
"Walter" <newshound digitalmars.com> wrote in message news:cvt8q3$mra$1 digitaldaemon.com..."Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:cvmgdk$2ut2$1 digitaldaemon.com...Ok. The alternative is to fix the C-style casts in the DMC++ headers. Are you amenable to adopting fixes, should I be motivated, from time to time, to detect and effect them?"Walter" <newshound digitalmars.com> wrote in message news:cvmcdp$2qt3$1 digitaldaemon.com...I'd rather not. Switches to turn warnings on, pragmas to turn them off - I don't think there's much to be gained here that's worth the complexity."Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:cuppnc$84h$1 digitaldaemon.com...So what's the answer?Walter I know I was the one who asked for it, but it's _too_ effective. Or, at least, is there a suppression pragma, and, if so, can you arrange to have that specified in the DMC++ header files? <G>Suppression pragmas? Uggh. <g>
Feb 27 2005
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:cvtkn4$12j7$1 digitaldaemon.com...Sure.I'd rather not. Switches to turn warnings on, pragmas to turn them off - I don't think there's much to be gained here that's worth the complexity.Ok. The alternative is to fix the C-style casts in the DMC++ headers. Are you amenable to adopting fixes, should I be motivated, from time to time, to detect and effect them?
Feb 28 2005
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> Cool. I'll stick it on the to-do. ;) "Walter" <newshound digitalmars.com> wrote in message news:cvvt4t$fot$2 digitaldaemon.com..."Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:cvtkn4$12j7$1 digitaldaemon.com...Sure.I'd rather not. Switches to turn warnings on, pragmas to turn them off - I don't think there's much to be gained here that's worth the complexity.Ok. The alternative is to fix the C-style casts in the DMC++ headers. Are you amenable to adopting fixes, should I be motivated, from time to time, to detect and effect them?
Feb 28 2005
string.h, lines 312-324
inline const char *strchr(const char *s, int n) { return
strchr(const_cast<char*>(s), n); }
inline const char *strrchr(const char *s, int n) { return
strrchr(const_cast<char*>(s), n); }
inline const char *strpbrk(const char *s1,const char *s2) { return
strpbrk(const_cast<char*>(s1), s2); }
inline const char *strstr(const char *s1,const char *s2) { return
strstr(const_cast<char*>(s1), s2); }
inline const void *memchr(const void *s, int c, size_t n) { return
memchr(const_cast<void*>(s), c, n); }
#ifndef __WCS_INLINE
#define __WCS_INLINE
inline const wchar_t *wcschr(const wchar_t *s, wchar_t c) { return
wcschr(const_cast<wchar_t*>(s), c); }
inline const wchar_t *wcsrchr(const wchar_t *s, wchar_t c) { return
wcsrchr(const_cast<wchar_t*>(s), c); }
inline const wchar_t *wcspbrk(const wchar_t *s1,const wchar_t *s2) { return
wcspbrk(const_cast<wchar_t*>(s1), s2); }
inline const wchar_t *wcswcs(const wchar_t *s1,const wchar_t *s2) { return
wcswcs(const_cast<wchar_t*>(s1), s2); }
inline const void *wmemchr(const void *s, wchar_t c, size_t n) { return
wmemchr(const_cast<void*>(s), c, n); }
Note: the strpbrk/wcspbrk were actually wrong. They were:
inline const char *strpbrk(const char *s1,const char *s2) { return (char *)
strpbrk((const char *)s1,s2); }
inline const wchar_t *wcspbrk(const wchar_t *s1,const wchar_t *s2) { return
(wchar_t *) wcspbrk((const wchar_t *)s1,s2); }
The cast on the return type is not necessary, but benign.
The incorrect cast on the s1 argument looks like it'd result in a nasty stack
exhaustion. ;)
The following test program produces correct behaviour when used with the
modified
string.h, and just dies in the strpbrk() call in the original (i.e. we never
see
"Exiting" or "Something bad happened" or "s: uff")
//#include <string.h.old>
#include <string.h>
#include <stdio.h>
int main()
{
try
{
const char stuff[] = "stuff";
printf("Calling strpbrk()\n");
char const *s = strpbrk(stuff, "fu");
printf("s: %s\n", s);
return 0;
}
catch(...)
{
printf("Something bad happened\n");
return 1;
}
printf("Exiting\n");
return 0;
}
"Walter" <newshound digitalmars.com> wrote in message
news:cvvt4t$fot$2 digitaldaemon.com...
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cvtkn4$12j7$1 digitaldaemon.com...
I'd rather not. Switches to turn warnings on, pragmas to turn them
off - I
don't think there's much to be gained here that's worth the
complexity.
Ok. The alternative is to fix the C-style casts in the DMC++ headers.
Are you amenable to adopting fixes, should I be motivated, from time to
time, to detect and effect them?
Sure.
Mar 23 2005
stlport/stl/_algobase.h
Lines 159-150
(static_cast<char*>(memmove(__result, __first, (static_cast<char
const*>(__last) - static_cast<char
const*>(__first))))) +
(static_cast<char const*>(__last) - static_cast<char const*>(__first));
Lines 183-184
const ptrdiff_t _Num = static_cast<char const*>(__last) - static_cast<char
const*>(__first);
return (_Num > 0) ? memmove(static_cast<char*>(__result) - _Num, __first,
_Num) : __result ;
Mar 23 2005
stlport/stl/_uninitialized.h Line 84: return static_cast<char*>(__copy_trivial (__first, __last, __result)); Line 90: return static_cast<wchar_t*>(__copy_trivial (__first, __last, __result)); "Walter" <newshound digitalmars.com> wrote in message news:cvvt4t$fot$2 digitaldaemon.com..."Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:cvtkn4$12j7$1 digitaldaemon.com...Sure.I'd rather not. Switches to turn warnings on, pragmas to turn them off - I don't think there's much to be gained here that's worth the complexity.Ok. The alternative is to fix the C-style casts in the DMC++ headers. Are you amenable to adopting fixes, should I be motivated, from time to time, to detect and effect them?
Mar 23 2005
stlport/stl/_string.h Line 193 static const size_t npos = ~static_cast<size_t>(0); "Walter" <newshound digitalmars.com> wrote in message news:cvvt4t$fot$2 digitaldaemon.com..."Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:cvtkn4$12j7$1 digitaldaemon.com...Sure.I'd rather not. Switches to turn warnings on, pragmas to turn them off - I don't think there's much to be gained here that's worth the complexity.Ok. The alternative is to fix the C-style casts in the DMC++ headers. Are you amenable to adopting fixes, should I be motivated, from time to time, to detect and effect them?
Mar 23 2005
assert.h
Was (lines 39-41):
#define assert(ignore) ((void) 0)
#else
#define assert(e) ((void)((e) || (_assert(#e,__FILE__,__LINE__),1)))
Now (lines 39-49):
#define assert(ignore) (static_cast<void>(0))
#define assert(ignore) ((void) 0)
#else
#define assert(e) (static_cast<void>((e) ||
(_assert(#e,__FILE__,__LINE__),1)))
#define assert(e) ((void)((e) || (_assert(#e,__FILE__,__LINE__),1)))
Mar 23 2005
stlport/stl/_ios_base.h
Line 175:
operator void*() const { return !fail() ?
static_cast<void*>(__CONST_CAST(ios_base*,this)) : static_cast<void*>(0); }
"Walter" <newshound digitalmars.com> wrote in message
news:cvvt4t$fot$2 digitaldaemon.com...
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cvtkn4$12j7$1 digitaldaemon.com...
I'd rather not. Switches to turn warnings on, pragmas to turn them
off - I
don't think there's much to be gained here that's worth the
complexity.
Ok. The alternative is to fix the C-style casts in the DMC++ headers.
Are you amenable to adopting fixes, should I be motivated, from time to
time, to detect and effect them?
Sure.
Mar 23 2005
stlport/stl/_string.c
Line 301:
size_type __len = static_cast<size_type>(__last - __first);
Line 343:
_STLP_STD::search(static_cast<const _CharT*>(this->_M_start) + __pos,
static_cast<const _CharT*>(this->_M_finish),
Line 356:
_STLP_STD::find_if(static_cast<const _CharT*>(this->_M_start) + __pos,
static_cast<const
_CharT*>(this->_M_finish),
Line 373:
const_pointer __result =
_STLP_STD::find_end(static_cast<const_pointer>(this->_M_start), __last,
Lines 435-438:
const_pointer __result = _STLP_STD::find_if(static_cast<const
_CharT*>(this->_M_start) + __pos,
static_cast<const _CharT*>(this->_M_finish),
_Not_within_traits<_Traits>(static_cast<const
_CharType*>(__s),
static_cast<const _CharType*>(__s) + __n));
Line 449:
const_pointer __result = _STLP_STD::find_if(static_cast<const
_CharT*>(this->_M_start) + __pos, static_cast<const
_CharT*>(this->_M_finish),
Lines 469-470:
_Not_within_traits<_Traits>(static_cast<const _CharType*>(__s),
static_cast<const _CharType*>(__s) + __n));
I'm getting very unimpressed with STLport as a result of all this.
As can be imagined, knowing what type of cast to apply is not immediately
obvious in all cases. This, in and of itself,
is clear demonstration why C++ casts should have been used in the first place!!
"Walter" <newshound digitalmars.com> wrote in message
news:cvvt4t$fot$2 digitaldaemon.com...
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cvtkn4$12j7$1 digitaldaemon.com...
I'd rather not. Switches to turn warnings on, pragmas to turn them
off - I
don't think there's much to be gained here that's worth the
complexity.
Ok. The alternative is to fix the C-style casts in the DMC++ headers.
Are you amenable to adopting fixes, should I be motivated, from time to
time, to detect and effect them?
Sure.
Mar 23 2005
stddef.h NOTE: This one's not just to be thrown in, as it's sufficiently complex to need some more eyes on it. Was (Line 66): #define offsetof(t,i) ((size_t)((char *)&((t *)0)->i - (char *)0)) Now (Lines 66-70): #ifdef __cplusplus (static_cast<size_t>(reinterpret_cast<char*>(&(static_cast<t*>(0))->i) - static_cast<char*>(0))) #else /* ? __cplusplus */ #endif /* __cplusplus */ "Walter" <newshound digitalmars.com> wrote in message news:cvvt4t$fot$2 digitaldaemon.com..."Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:cvtkn4$12j7$1 digitaldaemon.com...Sure.I'd rather not. Switches to turn warnings on, pragmas to turn them off - I don't think there's much to be gained here that's worth the complexity.Ok. The alternative is to fix the C-style casts in the DMC++ headers. Are you amenable to adopting fixes, should I be motivated, from time to time, to detect and effect them?
Mar 23 2005
stddef.h NOTE: This one's not just to be thrown in, as it's sufficiently complex to need some more eyes on it. Was (Line 66): #define offsetof(t,i) ((size_t)((char *)&((t *)0)->i - (char *)0)) Now (Lines 66-70): #ifdef __cplusplus (static_cast<size_t>(reinterpret_cast<char*>(&(static_cast<t*>(0))->i) - static_cast<char*>(0))) #else /* ? __cplusplus */ #endif /* __cplusplus */Interestingly, we need to use const in there. :-) #ifdef __cplusplus const*>(&(static_cast<t const*>(0))->i) - static_cast<char const*>(0))) #else /* ? __cplusplus */ #endif /* __cplusplus */
Mar 23 2005
stlport/stl/_iterator_base.h Lines 76-77: iterator_traits< _Tp >::value_type*>(0) iterator_traits< _Tp >::difference_type*>(0) "Walter" <newshound digitalmars.com> wrote in message news:cvvt4t$fot$2 digitaldaemon.com..."Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:cvtkn4$12j7$1 digitaldaemon.com...Sure.I'd rather not. Switches to turn warnings on, pragmas to turn them off - I don't think there's much to be gained here that's worth the complexity.Ok. The alternative is to fix the C-style casts in the DMC++ headers. Are you amenable to adopting fixes, should I be motivated, from time to time, to detect and effect them?
Mar 23 2005
stlport/stl/_algobase.h Line 197: return static_cast<_OutputIter>(__copy_trivial(__first, __last, __result)); "Walter" <newshound digitalmars.com> wrote in message news:cvvt4t$fot$2 digitaldaemon.com..."Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:cvtkn4$12j7$1 digitaldaemon.com...Sure.I'd rather not. Switches to turn warnings on, pragmas to turn them off - I don't think there's much to be gained here that's worth the complexity.Ok. The alternative is to fix the C-style casts in the DMC++ headers. Are you amenable to adopting fixes, should I be motivated, from time to time, to detect and effect them?
Mar 23 2005
stlport/stl/_alloc.h
Line 360:
if (__p != 0) __sgi_alloc::deallocate(static_cast<void*>(__p), __n *
sizeof(value_type));
"Walter" <newshound digitalmars.com> wrote in message
news:cvvt4t$fot$2 digitaldaemon.com...
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cvtkn4$12j7$1 digitaldaemon.com...
I'd rather not. Switches to turn warnings on, pragmas to turn them
off - I
don't think there's much to be gained here that's worth the
complexity.
Ok. The alternative is to fix the C-style casts in the DMC++ headers.
Are you amenable to adopting fixes, should I be motivated, from time to
time, to detect and effect them?
Sure.
Mar 23 2005
stlport/stl/char_traits.h
Line 166:
return (_Sz == 0 ? __s1 : static_cast<_CharT*>(memmove(__s1, __s2, _Sz *
sizeof(_CharT))));
Line 171:
static_cast<_CharT*>(memcpy(__s1, __s2, __n * sizeof(_CharT))));
Anyone getting a nervous feeling about STLport yet? :-(
"Walter" <newshound digitalmars.com> wrote in message
news:cvvt4t$fot$2 digitaldaemon.com...
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cvtkn4$12j7$1 digitaldaemon.com...
I'd rather not. Switches to turn warnings on, pragmas to turn them
off - I
don't think there's much to be gained here that's worth the
complexity.
Ok. The alternative is to fix the C-style casts in the DMC++ headers.
Are you amenable to adopting fixes, should I be motivated, from time to
time, to detect and effect them?
Sure.
Mar 23 2005
stlport/stl/_string.h
Lines 98-99:
return find_if(static_cast<_CharT*>(_M_first),
static_cast<_CharT*>(_M_last),
_Eq_char_bound<_Traits>(__x)) ==
static_cast<_CharT*>(_M_last);
"Walter" <newshound digitalmars.com> wrote in message
news:cvvt4t$fot$2 digitaldaemon.com...
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cvtkn4$12j7$1 digitaldaemon.com...
I'd rather not. Switches to turn warnings on, pragmas to turn them
off - I
don't think there's much to be gained here that's worth the
complexity.
Ok. The alternative is to fix the C-style casts in the DMC++ headers.
Are you amenable to adopting fixes, should I be motivated, from time to
time, to detect and effect them?
Sure.
Mar 23 2005
stlport/stl/_string.h
Line 129:
: _M_start(0), _M_finish(0), _M_end_of_storage(__a, static_cast<_Tp*>(0)) {}
Line 132:
: _M_start(0), _M_finish(0), _M_end_of_storage(__a, static_cast<_Tp*>(0))
Line 213:
return _STLP_CONVERT_ALLOCATOR(static_cast<const
allocator_type&>(this->_M_end_of_storage), _CharT);
The third one I'm not 100% on. Other eyes'd be helpful.
"Walter" <newshound digitalmars.com> wrote in message
news:cvvt4t$fot$2 digitaldaemon.com...
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cvtkn4$12j7$1 digitaldaemon.com...
I'd rather not. Switches to turn warnings on, pragmas to turn them
off - I
don't think there's much to be gained here that's worth the
complexity.
Ok. The alternative is to fix the C-style casts in the DMC++ headers.
Are you amenable to adopting fixes, should I be motivated, from time to
time, to detect and effect them?
Sure.
Mar 23 2005
stlport/stl/_list.c
Line 69:
_List_node<_Tp>* __cur =
static_cast<_List_node<_Tp>*>(this->_M_node._M_data->_M_next);
Line 72:
__cur = static_cast<_List_node<_Tp>*>(__cur->_M_next);
"Walter" <newshound digitalmars.com> wrote in message
news:cvvt4t$fot$2 digitaldaemon.com...
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cvtkn4$12j7$1 digitaldaemon.com...
I'd rather not. Switches to turn warnings on, pragmas to turn them
off - I
don't think there's much to be gained here that's worth the
complexity.
Ok. The alternative is to fix the C-style casts in the DMC++ headers.
Are you amenable to adopting fixes, should I be motivated, from time to
time, to detect and effect them?
Sure.
Mar 23 2005
stlport/stl/_list.h
Line 130:
reference operator*() const { return static_cast<_Node*>(_M_node)->_M_data; }
Line 182:
_List_base(const allocator_type& __a) : _M_node(_STLP_CONVERT_ALLOCATOR(__a,
_Node), static_cast<_Node*>(0)) {
Lines 266-7:
iterator begin() { return
iterator(static_cast<_Node*>(this->_M_node._M_data->_M_next)); }
const_iterator begin() const { return
const_iterator(static_cast<_Node*>(this->_M_node._M_data->_M_next)); }
Line 356:
_Node* __n = static_cast<_Node*>(__position._M_node);
Line 361:
return iterator(static_cast<_Node*>(__next_node));
"Walter" <newshound digitalmars.com> wrote in message
news:cvvt4t$fot$2 digitaldaemon.com...
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cvtkn4$12j7$1 digitaldaemon.com...
I'd rather not. Switches to turn warnings on, pragmas to turn them
off - I
don't think there's much to be gained here that's worth the
complexity.
Ok. The alternative is to fix the C-style casts in the DMC++ headers.
Are you amenable to adopting fixes, should I be motivated, from time to
time, to detect and effect them?
Sure.
Mar 23 2005
stlport/stl/char_traits.h
Line 198:
return static_cast<int_type>(-1);
Line 229:
return static_cast<char>(static_cast<unsigned char>(__c));
Line 232:
return static_cast<unsigned char>(__c);
"Walter" <newshound digitalmars.com> wrote in message
news:cvvt4t$fot$2 digitaldaemon.com...
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cvtkn4$12j7$1 digitaldaemon.com...
I'd rather not. Switches to turn warnings on, pragmas to turn them
off - I
don't think there's much to be gained here that's worth the
complexity.
Ok. The alternative is to fix the C-style casts in the DMC++ headers.
Are you amenable to adopting fixes, should I be motivated, from time to
time, to detect and effect them?
Sure.
Mar 23 2005
stlport/stl/_ios.h
Line 137:
{ return static_cast<const ctype<_CharT>*>(this->_M_ctype_facet())->narrow(__c,
__default); }
Line 143:
return static_cast<const ctype<_CharT>*>(this->_M_ctype_facet())->widen(__c);
}
"Walter" <newshound digitalmars.com> wrote in message
news:cvvt4t$fot$2 digitaldaemon.com...
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cvtkn4$12j7$1 digitaldaemon.com...
I'd rather not. Switches to turn warnings on, pragmas to turn them
off - I
don't think there's much to be gained here that's worth the
complexity.
Ok. The alternative is to fix the C-style casts in the DMC++ headers.
Are you amenable to adopting fixes, should I be motivated, from time to
time, to detect and effect them?
Sure.
Mar 23 2005
stlport/stl/_ctype.h
Line 80:
{ return ((*(_M_ctype_table+static_cast<unsigned char>(__c))) & __m) != 0; }
Line 142:
bool operator()(char __c) {return (__m & static_cast<unsigned char>(__c)) !=
0;}
Mar 23 2005
stlport/stl/_limits.h
Line 141:
static _Int (_STLP_CALL min) () _STLP_NOTHROW { return
static_cast<_Int>(__imin); }
Line 142:
static _Int (_STLP_CALL max) () _STLP_NOTHROW { return
static_cast<_Int>(__imax); }
Line 150:
(static_cast<int>((sizeof(_Int) * (CHAR_BIT))) - ((__imin == 0) ? 0 : 1))
Mar 23 2005
stlport/stl/_ostream.c
Line 105:
__from->gbump(static_cast<int>(__nwritten));
Mar 23 2005
stlport/stl/_istream.c
Line 602:
__buf->_M_gbump(static_cast<int>(__chunk));
Line 816:
_Is_wspace_null<_Traits>(static_cast<const
ctype<_CharT>*>(this->_M_ctype_facet())),
Line 817:
_Scan_wspace_null<_Traits>(static_cast<const
ctype<_CharT>*>(this->_M_ctype_facet())),
Line 820:
_Is_wspace_null<_Traits>(static_cast<const
ctype<_CharT>*>(this->_M_ctype_facet())),
Line 887:
__buf->_M_gbump(static_cast<int>(__p - __buf->_M_gptr()));
Line 996:
__buf->_M_gbump(static_cast<int>(__chunk));
Line 1010:
__buf->_M_gbump(static_cast<int>(__chunk));
Line 1150:
_Is_not_wspace<_Traits>(static_cast<const
ctype<_CharT>*>(this->_M_ctype_facet())),
Line 1151:
_Scan_for_not_wspace<_Traits>(static_cast<const
ctype<_CharT>*>(this->_M_ctype_facet())),
Line 1155:
_Is_not_wspace<_Traits>(static_cast<const
ctype<_CharT>*>(this->_M_ctype_facet())),
Line 1266:
__src->_M_gbump(static_cast<int>(__n));
Mar 23 2005
stlport/stl/_ios.c Line 83: this->_M_cached_grouping = static_cast<numpunct<char_type>*>(_M_cached_numpunct)->grouping() ;
Mar 23 2005
Last one: stdarg.h #ifdef __cplusplus static_cast<va_list>(&(parmn)) + __va_size(parmn))) #else /* ? __cplusplus */ __va_size(parmn))) #endif /* __cplusplus */ #define va_arg(ap, type) (*(type __SS *)(((ap)+=__va_size(type)) - (__va_size(type)))) #ifdef __cplusplus #else /* ? __cplusplus */ #endif /* __cplusplus */ #define va_copy(dest, src) ((dest) = (src)) I've built recls 1.6.2 with -wc, and with all the changes posted today. It runs perfectly fine. The upshot was that of all the c-style casts: - most were within STLport. (And from what I've been exposed to of STLport as a result, I'm rather glad I'm not working on its development) - a few were within std headers - some were within Windows headers. Since this'd be a gargantuan task to fix, I've contented myself to #undef/#define within winstl.h and using some of the components from within winstl_windows_type_conversions.h - quite a few were within STLSoft headers. The result is that: - I found some bugs within DMC++'s string.h, which otherwise would have continued to lay there, undiscovered - found quite a few dodgy things within STLSoft, which are now fixed - had a few annoying little things (such as changing "((void)0)" to "static_cast<void>(0)" - got the heeby-geebies about STLport. I'd say 30% of the totality of things found were worth having attention drawn to them, 30% were annoying irrelevances, and 40% were worth at least looking at (and now more maintainable for having had their casting actions documented more unambiguously). I'd say it was well worth the effort, and I will, now that I've got DMC++'s headers fixed, be using -wc wherever I can. :-) Cheers Matthew
Mar 23 2005
stlport/stl/_algobase.h Line 225: return static_cast<_OutputIter>(__copy_trivial_backward(__first, __last, __result));
Mar 23 2005
stlport/stl/_vector.h
Line 118:
return _STLP_CONVERT_ALLOCATOR(static_cast<const
allocator_type&>(this->_M_end_of_storage), _Tp);
Line 156:
pointer __new_finish = static_cast<pointer>(__copy_trivial(this->_M_start,
__position, __new_start));
Line 161:
__new_finish = static_cast<pointer>(__copy_trivial(__position,
this->_M_finish, __new_finish));
Mar 23 2005
stlport/stl/_fstream.h
Line 149:
int __o_mode() const { return static_cast<int>(_M_openmode); }
Line 355:
this->setg(static_cast<char_type*>(_M_ext_buf),
static_cast<char_type*>(_M_ext_buf),
static_cast<char_type*>(_M_ext_buf_end));
Mar 23 2005
stlport/stl/_fstream.c
Line 310:
streamoff __adjust = _M_mmap_len - (this->gptr() -
static_cast<_CharT*>(_M_mmap_base));
Line 447:
if (this->is_open() && ((static_cast<int>(_M_base.__o_mode()) &
static_cast<int>(ios_base::in)) !=0)
Mar 23 2005
stlport/stl/_bvector.h
Line 68:
bool __tmp = static_cast<bool>(__x);
Line 106:
_M_offset = static_cast<unsigned int>(__n) + __WORD_BIT;
Line 109:
_M_offset = static_cast<unsigned int>(__n);
Mar 23 2005
stlport/stl/_num_put.c
Line 146:
char* __iend = __write_float(__buf, __f.flags(),
static_cast<int>(__f.precision()), __x);
Line 149:
const numpunct<_CharT>& __np = *static_cast<const
numpunct<_CharT>*>(__f._M_numpunct_facet());
Line 253:
const numpunct<char>& __np = *static_cast<const
numpunct<char>*>(__f._M_numpunct_facet());
Line 270:
copy(__buf, __iend, static_cast<char*>(__grpbuf));
Line 302:
*--__ptr = static_cast<int>(__temp % 10) + '0';
Line 316:
*--__ptr = static_cast<int>(__x % 10) + '0';
Line 342:
*--__ptr = (static_cast<unsigned>(__temp)& 0x7) + '0';
Line 358:
*--__ptr = __table_ptr[(static_cast<unsigned>(__temp) & 0xF)];
Line 443:
const numpunct<_CharT>& __np = *static_cast<const
numpunct<_CharT>*>(__f._M_numpunct_facet());
Line 446:
static_cast<_CharT>(0),
static_cast<_CharT>(0));
Line 459:
char* __ibeg = __write_integer_backward(static_cast<char*>(__buf) + 64,
__flags, __val);
Line 460:
return __put_integer(__ibeg, static_cast<char*>(__buf) + 64, __s, __f,
__flags, __fill);
Line 472:
char* __ibeg = __write_integer_backward(static_cast<char*>(__buf) + 64,
__flags, __val);
Line 473:
return __put_integer(__ibeg, static_cast<char*>(__buf) + 64, __s, __f,
__flags, __fill);
Line 501:
char* __ibeg = __write_integer_backward(static_cast<char*>(__buf) + 64,
__flags, __val);
Line 502:
return __put_integer(__ibeg, static_cast<char*>(__buf) + 64, __s, __f,
__flags, __fill);
Line 513:
char* __ibeg = __write_integer_backward(static_cast<char*>(__buf) + 64,
__flags, __val);
Line 514:
return __put_integer(__ibeg, static_cast<char*>(__buf) + 64, __s, __f,
__flags, __fill);
Mar 23 2005
stlport/stl/_vector.c
Line 95:
pointer __tmp = _M_allocate_and_copy(__xlen,
static_cast<const_pointer>(__x._M_start) + 0,
static_cast<const_pointer>(__x._M_finish) + 0);
Line 101:
pointer __i = __copy_ptrs(static_cast<const_pointer>(__x._M_start) + 0,
static_cast<const_pointer>(__x._M_finish)
+ 0, static_cast<pointer>(this->_M_start), _TrivialAss());
Line 105:
__copy_ptrs(static_cast<const_pointer>(__x._M_start),
static_cast<const_pointer>(__x._M_start) + size(),
static_cast<pointer>(this->_M_start), _TrivialAss());
Mar 23 2005
Again, most of the ones were in STLport. A couple of useful things raised in winstl. All compiles/builds/executes fine.
Mar 23 2005
No changes needed over and above those for recls and b64, apart from in a couple of the Open-RJ test files. Compiles/builds/executes fine.
Mar 23 2005
WinSock.h #define INVALID_SOCKET (SOCKET)(~0) => #ifdef __cplusplus #else /* ? __cplusplus */ #endif /* __cplusplus */ wtypes.h #define VARIANT_TRUE ((VARIANT_BOOL)0xffff) #define VARIANT_FALSE ((VARIANT_BOOL)0) => #ifdef __cplusplus #else /* ? __cplusplus */ #endif /* __cplusplus */
Mar 27 2005
WinError.h #if __cplusplus #else /* ? __cplusplus */ #endif /* __cplusplus */ #if __cplusplus #else /* ? __cplusplus */ #endif /* __cplusplus */
Mar 27 2005
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d2638f$1u8m$1 digitaldaemon.com...WinError.h #if __cplusplus #else /* ? __cplusplus */ #endif /* __cplusplus */ #if __cplusplus #else /* ? __cplusplus */ #endif /* __cplusplus */Also #ifdef RC_INVOKED #else // RC_INVOKED #endif // RC_INVOKED
Mar 27 2005
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d264kq$2062$1 digitaldaemon.com..."Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d2638f$1u8m$1 digitaldaemon.com...static_cast<HRESULT>(sc)" needs an underscore. :-)WinError.h #if __cplusplus #else /* ? __cplusplus */ #endif /* __cplusplus */ #if __cplusplus #else /* ? __cplusplus */ #endif /* __cplusplus */Also #ifdef RC_INVOKED #else // RC_INVOKED #endif // RC_INVOKED
Mar 27 2005
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d2638f$1u8m$1 digitaldaemon.com...WinError.h #if __cplusplus #else /* ? __cplusplus */ #endif /* __cplusplus */ #if __cplusplus #else /* ? __cplusplus */ #endif /* __cplusplus */More: #if __cplusplus #else /* ? __cplusplus */ #endif /* __cplusplus */
Mar 27 2005
I'm now working through compilation of all the Synesis Software headers. This stuff's been around since the early 90s, and I'm finding a huge number of C-style casts in the C++ code. Some of these are plain bugs, others, once sorted, are enormously helpful in clearing up long forgotten nuances of well-established classes that one has to be careful not to alter except with great care. It's easy to fix them, since I've used the following cast macros for many years: #ifdef __cplusplus reinterpret_cast<_type>(_var) #else /* ? __cplusplus */ #endif /* __cplusplus */ If DMC++ takes up this header update seriously, I'd suggest doing something similar.
Mar 27 2005