c++.command-line - -wc is too good
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Feb 14 2005
- "Walter" <newshound digitalmars.com> Feb 24 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Feb 24 2005
- "Walter" <newshound digitalmars.com> Feb 27 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Feb 27 2005
- "Walter" <newshound digitalmars.com> Feb 28 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Feb 28 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 23 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 27 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 27 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 27 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 27 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 27 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Mar 27 2005
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...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>
So what's the answer?
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..."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>
So what's the answer?
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.
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..."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...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>
So what's the answer?
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 27 2005
"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.
Feb 28 2005
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...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.
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...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 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...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
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):
# if defined(__cplusplus)
#define assert(ignore) (static_cast<void>(0))
# else /* ? __cplusplus */
#define assert(ignore) ((void) 0)
# endif /* __cplusplus */
#else
# if defined(__cplusplus)
#define assert(e) (static_cast<void>((e) ||
(_assert(#e,__FILE__,__LINE__),1)))
# else /* ? __cplusplus */
#define assert(e) ((void)((e) || (_assert(#e,__FILE__,__LINE__),1)))
# endif /* __cplusplus */
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 # define offsetof(t,i) (static_cast<size_t>(reinterpret_cast<char*>(&(static_cast<t*>(0))->i) - static_cast<char*>(0))) #else /* ? __cplusplus */ # define offsetof(t,i) ((size_t)((char *)&((t *)0)->i - (char *)0)) #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...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 # define offsetof(t,i) (static_cast<size_t>(reinterpret_cast<char*>(&(static_cast<t*>(0))->i) - static_cast<char*>(0))) #else /* ? __cplusplus */ # define offsetof(t,i) ((size_t)((char *)&((t *)0)->i - (char *)0)) #endif /* __cplusplus */
Interestingly, we need to use const in there. :-) #ifdef __cplusplus # define offsetof(t,i) (static_cast<size_t>(reinterpret_cast<char const*>(&(static_cast<t const*>(0))->i) - static_cast<char const*>(0))) #else /* ? __cplusplus */ # define offsetof(t,i) ((size_t)((char *)&((t *)0)->i - (char *)0)) #endif /* __cplusplus */
Mar 23 2005
stlport/stl/_iterator_base.h Lines 76-77: # define _STLP_VALUE_TYPE(_It, _Tp) static_cast<typename iterator_traits< _Tp >::value_type*>(0) # define _STLP_DISTANCE_TYPE(_It, _Tp) static_cast<typename 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...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 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...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/_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
# define va_start(ap, parmn) (static_cast<void>((ap) =
static_cast<va_list>(&(parmn)) + __va_size(parmn)))
#else /* ? __cplusplus */
# define va_start(ap, parmn) ((void)((ap) = (va_list)&(parmn) +
__va_size(parmn)))
#endif /* __cplusplus */
#define va_arg(ap, type) (*(type __SS *)(((ap)+=__va_size(type)) -
(__va_size(type))))
#ifdef __cplusplus
# define va_end(ap) (static_cast<void>(0))
#else /* ? __cplusplus */
# define va_end(ap) ((void)0)
#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 # define INVALID_SOCKET static_cast<SOCKET>(~0) #else /* ? __cplusplus */ # define INVALID_SOCKET (SOCKET)(~0) #endif /* __cplusplus */ wtypes.h #define VARIANT_TRUE ((VARIANT_BOOL)0xffff) #define VARIANT_FALSE ((VARIANT_BOOL)0) => #ifdef __cplusplus # define VARIANT_TRUE static_cast<VARIANT_BOOL>(0xffff) # define VARIANT_FALSE static_cast<VARIANT_BOOL>(0) #else /* ? __cplusplus */ # define VARIANT_TRUE ((VARIANT_BOOL)0xffff) # define VARIANT_FALSE ((VARIANT_BOOL)0) #endif /* __cplusplus */
Mar 27 2005
WinError.h #if __cplusplus # define SUCCEEDED(Status) (static_cast<HRESULT>(Status) >= 0) #else /* ? __cplusplus */ # define SUCCEEDED(Status) ((HRESULT)(Status) >= 0) #endif /* __cplusplus */ #if __cplusplus # define FAILED(Status) (static_cast<HRESULT>(Status) < 0) #else /* ? __cplusplus */ # define FAILED(Status) ((HRESULT)(Status) < 0) #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 # define SUCCEEDED(Status) (static_cast<HRESULT>(Status) >= 0) #else /* ? __cplusplus */ # define SUCCEEDED(Status) ((HRESULT)(Status) >= 0) #endif /* __cplusplus */ #if __cplusplus # define FAILED(Status) (static_cast<HRESULT>(Status) < 0) #else /* ? __cplusplus */ # define FAILED(Status) ((HRESULT)(Status) < 0) #endif /* __cplusplus */
Also #ifdef RC_INVOKED # define _HRESULT_TYPEDEF_(_sc) _sc #else // RC_INVOKED # if __cplusplus # define _HRESULT_TYPEDEF_(_sc) static_cast<HRESULT>(sc) # else /* ? __cplusplus */ # define _HRESULT_TYPEDEF_(_sc) ((HRESULT)_sc) # endif /* __cplusplus */ #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...WinError.h #if __cplusplus # define SUCCEEDED(Status) (static_cast<HRESULT>(Status) >= 0) #else /* ? __cplusplus */ # define SUCCEEDED(Status) ((HRESULT)(Status) >= 0) #endif /* __cplusplus */ #if __cplusplus # define FAILED(Status) (static_cast<HRESULT>(Status) < 0) #else /* ? __cplusplus */ # define FAILED(Status) ((HRESULT)(Status) < 0) #endif /* __cplusplus */
Also #ifdef RC_INVOKED # define _HRESULT_TYPEDEF_(_sc) _sc #else // RC_INVOKED # if __cplusplus # define _HRESULT_TYPEDEF_(_sc) static_cast<HRESULT>(sc) # else /* ? __cplusplus */ # define _HRESULT_TYPEDEF_(_sc) ((HRESULT)_sc) # endif /* __cplusplus */ #endif // RC_INVOKED
Spoke too soon. The sc in "# define _HRESULT_TYPEDEF_(_sc) static_cast<HRESULT>(sc)" needs an underscore. :-)
Mar 27 2005
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d2638f$1u8m$1 digitaldaemon.com...WinError.h #if __cplusplus # define SUCCEEDED(Status) (static_cast<HRESULT>(Status) >= 0) #else /* ? __cplusplus */ # define SUCCEEDED(Status) ((HRESULT)(Status) >= 0) #endif /* __cplusplus */ #if __cplusplus # define FAILED(Status) (static_cast<HRESULT>(Status) < 0) #else /* ? __cplusplus */ # define FAILED(Status) ((HRESULT)(Status) < 0) #endif /* __cplusplus */
More: #if __cplusplus # define S_OK static_cast<HRESULT>(0x00000000L) # define S_FALSE static_cast<HRESULT>(0x00000001L) #else /* ? __cplusplus */ # define S_OK ((HRESULT)0x00000000L) # define S_FALSE ((HRESULT)0x00000001L) #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 # define SyCastStatic(_type, _var) static_cast<_type>(_var) # define SyCastDynamic(_type, _var) dynamic_cast<_type>(_var) # define SyCastConst(_type, _var) const_cast<_type>(_var) # define SyCastVolatile(_type, _var) const_cast<_type>(_var) # define SyCastRaw(_type, _var) reinterpret_cast<_type>(_var) #else /* ? __cplusplus */ # define SyCastStatic(_type, _var) ((_type)(_var)) # define SyCastDynamic(_type, _var) ((_type)(_var)) # define SyCastConst(_type, _var) ((_type)(_var)) # define SyCastVolatile(_type, _var) ((_type)(_var)) # define SyCastRaw(_type, _var) ((_type)(_var)) #endif /* __cplusplus */ If DMC++ takes up this header update seriously, I'd suggest doing something similar.
Mar 27 2005









"Matthew" <admin stlsoft.dot.dot.dot.dot.org> 