• "Shawn Poulson" <spoulson2 comcast.net> Jun 20 2003
• "Matthew Wilson" <matthew stlsoft.org> Jun 20 2003
• "Shawn Poulson" <spoulson2 comcast.net> Jun 22 2003
• "Matthew Wilson" <matthew stlsoft.org> Jun 23 2003
• "Matthew Wilson" <matthew stlsoft.org> Jun 23 2003

"Shawn Poulson" <spoulson2 comcast.net> writes:

Hello all,

Please excuse if this is not an STLSoft related issue, but it is one I've
been trying to figure out and it happens when I use the COMSTL library.
I've only just begin to use COMSTL.

I'm using the create_bstr() function, which worked well in one project that
uses OLE Automation to create an Excel sheet and fill in some cells with
string data.  This works.

Now I'm creating a DLL for another application (which happens to be a Palm
conduit) that does similar work to create an Excel sheet using OLE
Automation.  I use the same basic code as used in the previous project and
it compiles fine, but I get this link error:

MMCdPcMgr.obj : error LNK2019: unresolved external symbol __CrtDbgReport
referenced in function "public: __thiscall stlsoft::auto_buffer<unsigned
short,class stlsoft::comstl_project::task_allocator<unsigned
short>,512>::auto_buffer<unsigned short,class
stlsoft::comstl_project::task_allocator<unsigned short>,512>(unsigned int)"
(??0?$auto_buffer GV?$task_allocator G comstl_project stlsoft  $0CAA  stlsof
t  QAE I Z)

I've seen this before but haven't been able to track it down.  Any ideas?

Thanks
Shawn Poulson
spoulson2 comcast.net

"Matthew Wilson" <matthew stlsoft.org> writes:

Hi Shawn

The problem here is not directly-related to STLSoft, but that's not an issue
(for me, at least).

I presume you're using either Intel or Visual C++, since in their respective
compiler-specific headers - stlsoft_cccap_intel.h & stlsoft_cccap_msvc.h -
<CrtDbg.h> is the following two lines:

 #define __STLSOFT_CF_ASSERT_INCLUDE_NAME    <crtdbg.h>
 #define stlsoft_assert(_x)
_ASSERTE(_x)

( All other compilers use <assert.h> and assert(_x) )

Hence, the Microsoft CRT debug header, CrtDbg.h, is included in the
appropriate place within stlsoft.h, and all assertions within the library
are then effected in terms of _ASSERTE(), which boils down in debug
compilers to a call to _CrtDbgReport().

The only possible explanation I can think of is that your debug mode DLL has
chosen (and for possibly good reasons; see
http://www.windevnet.com/documents/win0302c/) to prevent linking of the
Visual C++ CRT libraries, via the /NODEFAULTLIB flag, or the "Ignore all
default libraries" check box from within (General page of) the Link tab in
the project settings. (That's speaking for Visual Studio 6 - I don't know
the VS.NET dialogs off the top of my head.)

So you have two answers:

 (i) Enable linking to the VC++ CRT library in debug (or both) mode(s), or
 (ii) #define _STLSOFT_NO_ASSERT to deactivate all the STLSoft assertions.

I'd go with the first one, if I were you.

I had planned to allow users to specify their own _ThrowMyAssert() type
assert, but haven't got round to it through lack of demand. If that demand
arises I'll do it, in which case you'd be able to do something as simple as

 #define _STLSOFT_CUSTOM_ASSERT(_x)    _ThrowMyAssert(_x)

or some such. However, I suspect this is not what you're after so, you
should go with (i) or (ii)

Hope that helps.

btw, since you're working with COMSTL, I'd very much appreciate receiving
comment on what areas you feel are missing from that project. (From my point
of view this project has only just started, and will likely end up being
larger than WinSTL.) I have a very long list of things I'll be creating or
moving over (from my company's source) into COMSTL for the next big release
(1.7.1, planned late July) of STLSoft, so any help with prioritisation would
be much appreciated. Although it's not as popular as WinSTL, I've had quite
a few emails recently from people using COMSTL, so I want to give it a big
boost for the next release.

Matthew


"Shawn Poulson" <spoulson2 comcast.net> wrote in message
news:bd0k13$m96$1 digitaldaemon.com...
 Hello all,

 Please excuse if this is not an STLSoft related issue, but it is one I've
 been trying to figure out and it happens when I use the COMSTL library.
 I've only just begin to use COMSTL.

 I'm using the create_bstr() function, which worked well in one project


 uses OLE Automation to create an Excel sheet and fill in some cells with
 string data.  This works.

 Now I'm creating a DLL for another application (which happens to be a Palm
 conduit) that does similar work to create an Excel sheet using OLE
 Automation.  I use the same basic code as used in the previous project and
 it compiles fine, but I get this link error:

 MMCdPcMgr.obj : error LNK2019: unresolved external symbol __CrtDbgReport
 referenced in function "public: __thiscall stlsoft::auto_buffer<unsigned
 short,class stlsoft::comstl_project::task_allocator<unsigned
 short>,512>::auto_buffer<unsigned short,class
 stlsoft::comstl_project::task_allocator<unsigned short>,512>(unsigned




 t  QAE I Z)

 I've seen this before but haven't been able to track it down.  Any ideas?

 Thanks
 Shawn Poulson
 spoulson2 comcast.net

"Shawn Poulson" <spoulson2 comcast.net> writes:

Thanks, Matt for the quick response.

I did neglect to mention I am using VS.NET.  My project config is pretty
straightforward.  I am not using "Ignore all default libraries" nor am I
using "Ignore specific library".  My additional libs are "sync20.lib
hslog20.lib palmcmn.lib comctl32.lib", which are all Palm-related libs
except for the last which is just for dialog controls.  I'm not using ATL,
MFC, or any other framework.  My code is straight DLL C++ code with some
Win32 and Palm calls.

I'm not sure what else I could set.  I did try to use some macros available
in ATL that make BSTR's (A2WBSTR and CComBSTR class), which worked in my exe
test but gave the same CrtDbgReport link error in my DLL project.  It's not
clear why the DLL project had this problem since I synchronized all my
project settings between exe and DLL.  I don't see any other settings I can
change to address the two options.

Now, option (ii) worked.  I'll stick with this for now.  I'm not very adept
at assertions so I've really not used them anyway.

I've only used the create_bstr() function so I'm no critic of the library,
yet.  However, I would like to see functionality for SAFEARRAY.  It is
really nice to see open source projects like this and boost.  If there's
anyway I can help, please tell me how.


"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bd0sts$tl4$1 digitaldaemon.com...
 Hi Shawn

 The problem here is not directly-related to STLSoft, but that's not an


 (for me, at least).

 I presume you're using either Intel or Visual C++, since in their


 compiler-specific headers - stlsoft_cccap_intel.h & stlsoft_cccap_msvc.h -
 <CrtDbg.h> is the following two lines:

  #define __STLSOFT_CF_ASSERT_INCLUDE_NAME    <crtdbg.h>
  #define stlsoft_assert(_x)
 _ASSERTE(_x)

 ( All other compilers use <assert.h> and assert(_x) )

 Hence, the Microsoft CRT debug header, CrtDbg.h, is included in the
 appropriate place within stlsoft.h, and all assertions within the library
 are then effected in terms of _ASSERTE(), which boils down in debug
 compilers to a call to _CrtDbgReport().

 The only possible explanation I can think of is that your debug mode DLL


 chosen (and for possibly good reasons; see
 http://www.windevnet.com/documents/win0302c/) to prevent linking of the
 Visual C++ CRT libraries, via the /NODEFAULTLIB flag, or the "Ignore all
 default libraries" check box from within (General page of) the Link tab in
 the project settings. (That's speaking for Visual Studio 6 - I don't know
 the VS.NET dialogs off the top of my head.)

 So you have two answers:

  (i) Enable linking to the VC++ CRT library in debug (or both) mode(s), or
  (ii) #define _STLSOFT_NO_ASSERT to deactivate all the STLSoft assertions.

 I'd go with the first one, if I were you.

 I had planned to allow users to specify their own _ThrowMyAssert() type
 assert, but haven't got round to it through lack of demand. If that demand
 arises I'll do it, in which case you'd be able to do something as simple


  #define _STLSOFT_CUSTOM_ASSERT(_x)    _ThrowMyAssert(_x)

 or some such. However, I suspect this is not what you're after so, you
 should go with (i) or (ii)

 Hope that helps.

 btw, since you're working with COMSTL, I'd very much appreciate receiving
 comment on what areas you feel are missing from that project. (From my


 of view this project has only just started, and will likely end up being
 larger than WinSTL.) I have a very long list of things I'll be creating or
 moving over (from my company's source) into COMSTL for the next big


 (1.7.1, planned late July) of STLSoft, so any help with prioritisation


 be much appreciated. Although it's not as popular as WinSTL, I've had


 a few emails recently from people using COMSTL, so I want to give it a big
 boost for the next release.

 Matthew


 "Shawn Poulson" <spoulson2 comcast.net> wrote in message
 news:bd0k13$m96$1 digitaldaemon.com...
 Hello all,

 Please excuse if this is not an STLSoft related issue, but it is one




 been trying to figure out and it happens when I use the COMSTL library.
 I've only just begin to use COMSTL.

 I'm using the create_bstr() function, which worked well in one project


 uses OLE Automation to create an Excel sheet and fill in some cells with
 string data.  This works.

 Now I'm creating a DLL for another application (which happens to be a




 conduit) that does similar work to create an Excel sheet using OLE
 Automation.  I use the same basic code as used in the previous project




 it compiles fine, but I get this link error:

 MMCdPcMgr.obj : error LNK2019: unresolved external symbol __CrtDbgReport
 referenced in function "public: __thiscall stlsoft::auto_buffer<unsigned
 short,class stlsoft::comstl_project::task_allocator<unsigned
 short>,512>::auto_buffer<unsigned short,class
 stlsoft::comstl_project::task_allocator<unsigned short>,512>(unsigned






 t  QAE I Z)

 I've seen this before but haven't been able to track it down.  Any




 Thanks
 Shawn Poulson
 spoulson2 comcast.net

"Matthew Wilson" <matthew stlsoft.org> writes:

"Shawn Poulson" <spoulson2 comcast.net> wrote in message
news:bd5mnv$29vj$1 digitaldaemon.com...
 Thanks, Matt for the quick response.


Happy to serve/share. :)

 I did neglect to mention I am using VS.NET.  My project config is pretty
 straightforward.  I am not using "Ignore all default libraries" nor am I
 using "Ignore specific library".  My additional libs are "sync20.lib
 hslog20.lib palmcmn.lib comctl32.lib", which are all Palm-related libs
 except for the last which is just for dialog controls.  I'm not using ATL,
 MFC, or any other framework.  My code is straight DLL C++ code with some
 Win32 and Palm calls.


It's a bit hard to diagnose your problem any further without getting my paws
on the project ...
 I'm not sure what else I could set.  I did try to use some macros


 in ATL that make BSTR's (A2WBSTR and CComBSTR class), which worked in my


 test but gave the same CrtDbgReport link error in my DLL project.  It's


 clear why the DLL project had this problem since I synchronized all my
 project settings between exe and DLL.  I don't see any other settings I


 change to address the two options.

 Now, option (ii) worked.  I'll stick with this for now.  I'm not very


 at assertions so I've really not used them anyway.


... but it looks like you're sort of happy for the moment.

 I've only used the create_bstr() function so I'm no critic of the library,
 yet.  However, I would like to see functionality for SAFEARRAY.


I'll have a look at that for 1.7.1 (which I plan for July). I am thinking at
least of sequence-iteration over SAFEARRAY contents, and may even get so far
as converting an SA wrapper which has been lurking around in the company
code for some years.

  It is


 anyway I can help, please tell me how.


Just keep giving feedback, and, I guess, sharing the message.

One thing I'm keen to focus on is making the help really good. At the moment
one might, kindly, call it antiseptic. I'm very keen to enhance this to give
examples wherever necessary, so if you can feed back _specific_ criticisms I
will do my best to address them asap.

Cheers

Matthew

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bd0sts$tl4$1 digitaldaemon.com...
 Hi Shawn

 The problem here is not directly-related to STLSoft, but that's not an


 (for me, at least).

 I presume you're using either Intel or Visual C++, since in their


 compiler-specific headers - stlsoft_cccap_intel.h &




 <CrtDbg.h> is the following two lines:

  #define __STLSOFT_CF_ASSERT_INCLUDE_NAME    <crtdbg.h>
  #define stlsoft_assert(_x)
 _ASSERTE(_x)

 ( All other compilers use <assert.h> and assert(_x) )

 Hence, the Microsoft CRT debug header, CrtDbg.h, is included in the
 appropriate place within stlsoft.h, and all assertions within the




 are then effected in terms of _ASSERTE(), which boils down in debug
 compilers to a call to _CrtDbgReport().

 The only possible explanation I can think of is that your debug mode DLL


 chosen (and for possibly good reasons; see
 http://www.windevnet.com/documents/win0302c/) to prevent linking of the
 Visual C++ CRT libraries, via the /NODEFAULTLIB flag, or the "Ignore all
 default libraries" check box from within (General page of) the Link tab




 the project settings. (That's speaking for Visual Studio 6 - I don't




 the VS.NET dialogs off the top of my head.)

 So you have two answers:

  (i) Enable linking to the VC++ CRT library in debug (or both) mode(s),




  (ii) #define _STLSOFT_NO_ASSERT to deactivate all the STLSoft




 I'd go with the first one, if I were you.

 I had planned to allow users to specify their own _ThrowMyAssert() type
 assert, but haven't got round to it through lack of demand. If that




 arises I'll do it, in which case you'd be able to do something as simple


  #define _STLSOFT_CUSTOM_ASSERT(_x)    _ThrowMyAssert(_x)

 or some such. However, I suspect this is not what you're after so, you
 should go with (i) or (ii)

 Hope that helps.

 btw, since you're working with COMSTL, I'd very much appreciate




 comment on what areas you feel are missing from that project. (From my


 of view this project has only just started, and will likely end up being
 larger than WinSTL.) I have a very long list of things I'll be creating




 moving over (from my company's source) into COMSTL for the next big


 (1.7.1, planned late July) of STLSoft, so any help with prioritisation


 be much appreciated. Although it's not as popular as WinSTL, I've had


 a few emails recently from people using COMSTL, so I want to give it a




 boost for the next release.

 Matthew


 "Shawn Poulson" <spoulson2 comcast.net> wrote in message
 news:bd0k13$m96$1 digitaldaemon.com...
 Hello all,

 Please excuse if this is not an STLSoft related issue, but it is one




 been trying to figure out and it happens when I use the COMSTL






 I've only just begin to use COMSTL.

 I'm using the create_bstr() function, which worked well in one project


 uses OLE Automation to create an Excel sheet and fill in some cells






 string data.  This works.

 Now I'm creating a DLL for another application (which happens to be a




 conduit) that does similar work to create an Excel sheet using OLE
 Automation.  I use the same basic code as used in the previous project




 it compiles fine, but I get this link error:

 MMCdPcMgr.obj : error LNK2019: unresolved external symbol






 referenced in function "public: __thiscall






 short,class stlsoft::comstl_project::task_allocator<unsigned
 short>,512>::auto_buffer<unsigned short,class
 stlsoft::comstl_project::task_allocator<unsigned short>,512>(unsigned








 t  QAE I Z)

 I've seen this before but haven't been able to track it down.  Any




 Thanks
 Shawn Poulson
 spoulson2 comcast.net

"Matthew Wilson" <matthew stlsoft.org> writes:

LOL!

I've been gradually moving more and more STLSoft stuff back into my
company's libraries, and I've now run into this exact problem in one of the
base DLLs which does indeed eschew use of the VC++ libraries.

So it looks like I'm going to have to implement the change I spoke of right
now, which'll mean it'll be in the next release (1.6.4) which is planned for
the end of the month.



"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bd0sts$tl4$1 digitaldaemon.com...
 Hi Shawn

 The problem here is not directly-related to STLSoft, but that's not an


 (for me, at least).

 I presume you're using either Intel or Visual C++, since in their


 compiler-specific headers - stlsoft_cccap_intel.h & stlsoft_cccap_msvc.h -
 <CrtDbg.h> is the following two lines:

  #define __STLSOFT_CF_ASSERT_INCLUDE_NAME    <crtdbg.h>
  #define stlsoft_assert(_x)
 _ASSERTE(_x)

 ( All other compilers use <assert.h> and assert(_x) )

 Hence, the Microsoft CRT debug header, CrtDbg.h, is included in the
 appropriate place within stlsoft.h, and all assertions within the library
 are then effected in terms of _ASSERTE(), which boils down in debug
 compilers to a call to _CrtDbgReport().

 The only possible explanation I can think of is that your debug mode DLL


 chosen (and for possibly good reasons; see
 http://www.windevnet.com/documents/win0302c/) to prevent linking of the
 Visual C++ CRT libraries, via the /NODEFAULTLIB flag, or the "Ignore all
 default libraries" check box from within (General page of) the Link tab in
 the project settings. (That's speaking for Visual Studio 6 - I don't know
 the VS.NET dialogs off the top of my head.)

 So you have two answers:

  (i) Enable linking to the VC++ CRT library in debug (or both) mode(s), or
  (ii) #define _STLSOFT_NO_ASSERT to deactivate all the STLSoft assertions.

 I'd go with the first one, if I were you.

 I had planned to allow users to specify their own _ThrowMyAssert() type
 assert, but haven't got round to it through lack of demand. If that demand
 arises I'll do it, in which case you'd be able to do something as simple


  #define _STLSOFT_CUSTOM_ASSERT(_x)    _ThrowMyAssert(_x)

 or some such. However, I suspect this is not what you're after so, you
 should go with (i) or (ii)

 Hope that helps.

 btw, since you're working with COMSTL, I'd very much appreciate receiving
 comment on what areas you feel are missing from that project. (From my


 of view this project has only just started, and will likely end up being
 larger than WinSTL.) I have a very long list of things I'll be creating or
 moving over (from my company's source) into COMSTL for the next big


 (1.7.1, planned late July) of STLSoft, so any help with prioritisation


 be much appreciated. Although it's not as popular as WinSTL, I've had


 a few emails recently from people using COMSTL, so I want to give it a big
 boost for the next release.

 Matthew


 "Shawn Poulson" <spoulson2 comcast.net> wrote in message
 news:bd0k13$m96$1 digitaldaemon.com...
 Hello all,

 Please excuse if this is not an STLSoft related issue, but it is one




 been trying to figure out and it happens when I use the COMSTL library.
 I've only just begin to use COMSTL.

 I'm using the create_bstr() function, which worked well in one project


 uses OLE Automation to create an Excel sheet and fill in some cells with
 string data.  This works.

 Now I'm creating a DLL for another application (which happens to be a




 conduit) that does similar work to create an Excel sheet using OLE
 Automation.  I use the same basic code as used in the previous project




 it compiles fine, but I get this link error:

 MMCdPcMgr.obj : error LNK2019: unresolved external symbol __CrtDbgReport
 referenced in function "public: __thiscall stlsoft::auto_buffer<unsigned
 short,class stlsoft::comstl_project::task_allocator<unsigned
 short>,512>::auto_buffer<unsigned short,class
 stlsoft::comstl_project::task_allocator<unsigned short>,512>(unsigned






 t  QAE I Z)

 I've seen this before but haven't been able to track it down.  Any




 Thanks
 Shawn Poulson
 spoulson2 comcast.net