dev-cpp-users — Dev-C++ users discussion list

[Dev-C++] Linking errors with winmme and dsound libraries.

[Gabriel M. <g.m...@in...>]

Hi all,
I'm completely new to Dev-C++, but an old user of MSVC 6.
Excuse me for the length of this message.
I'm attempting to convert my MSVC projects to devcpp, but I'm blocked by
persistent linking errors. The error messages are the following:
=================================================
Compiler: Default compiler
Building Makefile:
"C:\LibroBoulanger\maldonado\codeDEV++\applications\hellotableRT\Makefile.win"
Executing  make...
make.exe -f
"C:\LibroBoulanger\maldonado\codeDEV++\applications\hellotableRT\Makefile.win" 

all
g++.exe devcpp/hellotable.o  -o "devcpp\hellotableRT.exe"
-L"C:/Dev-Cpp/lib" -L"../../Libraries/tinyAudioLib/Release"
-L"../../Libraries/PortaudioMSVC/pablioLIB_mme___Win32_Release"
-L"../../Libraries/tinyAudioLib/Release" -lkernel32 -luser32 -lgdi32
-lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -luuid
-lodbc32 -lodbccp32 -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32
-ladvapi32 -lshell32 -lole32 -loleaut32 -luuid -lodbc32 -lodbccp32
-lwinmm -ldsound -lpablioLIB_mme -ltinyAudioLib

../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x165):C:\LibroBoulanger\: 

variable '_iob' can't be auto-imported. Please read the documentation
for ld's --enable-auto-import for details.
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x3a7):C:\LibroBoulanger\: 

variable '_iob' can't be auto-imported. Please read the documentation
for ld's --enable-auto-import for details.
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0xc9):C:\LibroBoulanger\: 

variable '_iob' can't be auto-imported. Please read the documentation
for ld's --enable-auto-import for details.
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x10a):C:\LibroBoulanger\: 

variable '_iob' can't be auto-imported. Please read the documentation
for ld's --enable-auto-import for details.
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x88):C:\LibroBoulanger\: 

variable '_iob' can't be auto-imported. Please read the documentation
for ld's --enable-auto-import for details.

../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x83):C:\LibroBoulanger\: 

undefined reference to `_imp__waveInGetDevCapsA@12'
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x1df):C:\LibroBoulanger\: 

undefined reference to `_imp__waveInOpen@24'
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x2a9):C:\LibroBoulanger\: 

undefined reference to `_imp__waveOutGetDevCapsA@12'

../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x41a):C:\LibroBoulanger\: 

undefined reference to `_imp__waveOutOpen@24'
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x2):C:\LibroBoulanger\: 

undefined reference to `_imp__waveInGetNumDevs@0'

../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x2d):C:\LibroBoulanger\: 

undefined reference to `_imp__waveOutGetNumDevs@0'
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0xb4):C:\LibroBoulanger\: 

undefined reference to `_imp__waveInOpen@24'

../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x116):C:\LibroBoulanger\: 

undefined reference to `_imp__waveInPrepareHeader@12'
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0xf5):C:\LibroBoulanger\: 

undefined reference to `_imp__waveOutOpen@24'
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x197):C:\LibroBoulanger\: 

undefined reference to `_imp__waveOutPrepareHeader@12'
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x3a):C:\LibroBoulanger\: 

undefined reference to `_imp__waveOutPause@4'
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x76):C:\LibroBoulanger\: 

undefined reference to `_imp__waveOutWrite@12'
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0xa1):C:\LibroBoulanger\: 

undefined reference to `_imp__waveOutRestart@4'
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x37):C:\LibroBoulanger\: 

undefined reference to `_imp__waveInAddBuffer@12'
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x65):C:\LibroBoulanger\: 

undefined reference to `_imp__waveInStart@4'
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_wiInfo: 

resolving __iob by linking to __imp___iob (auto-import)
n_wmme.obj)(.text+0x144):C:\LibroBoulanger\: undefined reference to
`_imp__waveInAddBuffer@12'
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x17c):C:\LibroBoulanger\: 

undefined reference to `_imp__waveOutWrite@12'
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x1a):C:\LibroBoulanger\: 

undefined reference to `_imp__waveInReset@4'
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x1b):C:\LibroBoulanger\: 

undefined reference to `_imp__waveOutReset@4'
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x40):C:\LibroBoulanger\: 

undefined reference to `_imp__waveOutUnprepareHeader@12'
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x80):C:\LibroBoulanger\: 

undefined reference to `_imp__waveOutClose@4'
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x9b):C:\LibroBoulanger\: 

undefined reference to `_imp__waveInUnprepareHeader@12'
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0xd9):C:\LibroBoulanger\: 

undefined reference to `_imp__waveInClose@4'
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x21):C:\LibroBoulanger\: 

undefined reference to `_imp__waveOutGetPosition@12'
../../Libraries/tinyAudioLib/Release\tinyAudioLib.lib(./pablioLIB_mme___Win32_Release/pa_win_wmme.obj)(.text+0x31):C:\LibroBoulanger\: 

undefined reference to `_imp__waveInGetPosition@12'

make.exe: *** [devcpp/hellotableRT.exe] Error 1

Execution terminated
=================================================


I have to say that the project compiles OK under MSVC. Under MSVC I've
set the runtime library as 'multithreaded DLL'. Notice that I'm
attempting to link libraries compiled by myself with MSVC with the same
'multithreaded DLL' runtime lib compilation (the libraries are
tinyAudioLib and pablioLIB_mme that use winmm and dsound calls).

Is it possible to link libraries pre-compiled with MSVC in devcpp? Do I
have to re-compile such libraries with devcpp? (I hope I don't have). 
However I recompiled the two libraries 'tinyAudioLib' and 
'pablioLIB_mme' with devcpp, but when I linked my program with them 
(precisely  with their new devcpp builds) I got the following errors:

===========================
Compiler: Default compiler
Building Makefile: 
"C:\LibroBoulanger\maldonado\codeDEV++\applications\hellotableRT\Makefile.win"
Executing  make clean
rm -f devcpp/hellotable.o  devcpp/hellotableRT.exe

gcc.exe -c ../hellotable/hellotable.c -o devcpp/hellotable.o 
-I"C:/Dev-Cpp/include" 
-I"c:/MY_DOCS/VISUAL_C/OPENGL/GLUT-3.7.2/INCLUDE" 
-I"C:/MY_DOCS/VISUAL_C/FLTK/FLTK-1.1.4RC1" 
-I"C:/My_Docs/Visual_C/paintlib/otherlib/libjpeg" 
-I"C:/My_Docs/Visual_C/paintlib/otherlib/libpng" 
-I"C:/My_Docs/Visual_C/paintlib/otherlib/zlib" 
-I"C:/My_Docs/Visual_C/paintlib/src/common" 
-I"C:/MY_DOCS/VISUAL_C/OPENGL/GLE-3.0.7/SRC" 
-I"C:/My_Docs/Visual_C/Python-2.2.1c2/Include" 
-I"c:/MY_DOCS/VISUAL_C/OTHERLIBS/INCLUDE" 
-I"C:/Dev-Cpp/include/c++/backward"  -I"../../Libraries/tinyAudioLib" 
-D__GNUWIN32__ -W -DWIN32 -DNDEBUG -D_CONSOLE -D_MBCS -DREALTIME

../hellotable/hellotable.c: In function `main':
../hellotable/hellotable.c:115: warning: return type of `main' is not `int'

g++.exe devcpp/hellotable.o  -o "devcpp\hellotableRT.exe" 
-L"C:/Dev-Cpp/lib" -L"../../Libraries/tinyAudioLib/devcpp" 
-L"../../Libraries/PortaudioMSVC/devcpp" -lkernel32 -luser32 -lgdi32 
-lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -luuid 
-lodbc32 -lodbccp32 -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 
-ladvapi32 -lshell32 -lole32 -loleaut32 -luuid -lodbc32 -lodbccp32 
-lwinmm -ldsound -lpablioLIB_mme -ltinyAudioLib

../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0x52):tinyAudioLib.c: 
undefined reference to `CloseAudioStream'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0x90):tinyAudioLib.c: 
undefined reference to `Pa_GetErrorText'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0x187):tinyAudioLib.c: 
undefined reference to `Pa_GetErrorText'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0x327):tinyAudioLib.c: 
undefined reference to `ReadAudioStream'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0x3ec):tinyAudioLib.c: 
undefined reference to `WriteAudioStream'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0x41e):tinyAudioLib.c: 
undefined reference to `ReadAudioStream'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0x4ff):tinyAudioLib.c: 
undefined reference to `WriteAudioStream'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0x52c):tinyAudioLib.c: 
undefined reference to `WriteAudioStream'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0x55a):tinyAudioLib.c: 
undefined reference to `ReadAudioStream'

../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0x5a4):tinyAudioLib.c: 
undefined reference to `WriteAudioStream'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0x5d2):tinyAudioLib.c: 
undefined reference to `ReadAudioStream'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0x612):tinyAudioLib.c: 
undefined reference to `WriteAudioStream'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0x765):tinyAudioLib.c: 
undefined reference to `Pa_GetDeviceInfo'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0x8a2):tinyAudioLib.c: 
undefined reference to `Pa_CountDevices'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0x8bd):tinyAudioLib.c: 
undefined reference to `Pa_GetDeviceInfo'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0x9fc):tinyAudioLib.c: 
undefined reference to `Pa_GetDeviceInfo'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0xa35):tinyAudioLib.c: 
undefined reference to `Pa_GetDefaultOutputDeviceID'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0xadb):tinyAudioLib.c: 
undefined reference to `Pa_GetDeviceInfo'

../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0xc18):tinyAudioLib.c: 
undefined reference to `Pa_CountDevices'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0xc33):tinyAudioLib.c: 
undefined reference to `Pa_GetDeviceInfo'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0xd72):tinyAudioLib.c: 
undefined reference to `Pa_GetDeviceInfo'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0xdab):tinyAudioLib.c: 
undefined reference to `Pa_GetDefaultInputDeviceID'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0xe38):tinyAudioLib.c: 
undefined reference to `RingBuffer_Write'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0xe56):tinyAudioLib.c: 
undefined reference to `RingBuffer_Read'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0xf1e):tinyAudioLib.c: 
undefined reference to `RingBuffer_Init'

../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0xf89):tinyAudioLib.c: 
undefined reference to `Pa_GetSampleSize'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0xfde):tinyAudioLib.c: 
undefined reference to `Pa_Initialize'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0xfff):tinyAudioLib.c: 
undefined reference to `Pa_GetMinNumBuffers'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0x10d2):tinyAudioLib.c: 
undefined reference to `RingBuffer_GetWriteAvailable'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0x10ea):tinyAudioLib.c: 
undefined reference to `RingBuffer_AdvanceWriteIndex'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0x1186):tinyAudioLib.c: 
undefined reference to `Pa_OpenStream'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0x11a2):tinyAudioLib.c: 
undefined reference to `Pa_StartStream'
../../Libraries/tinyAudioLib/devcpp\tinyAudioLib.lib(tinyAudioLib.o.b)(.text+0x11cc):tinyAudioLib.c: 
undefined reference to `CloseAudioStream'

make.exe: *** [devcpp/hellotableRT.exe] Error 1

Execution terminated
===========================

All the functions that the linker says to be 'undefined reference', are 
actually defined in the 'pablioLIB_mme' library that is included in the 
project. I'm asking why they result undefined.

Thanks in advance

-- 
Gabriel Maldonado
http://csounds.com/maldonado/home2.htm
--

[Dev-C++] new is a wrapper around malloc so...

[Daniel G. <sp...@ho...>]

Hi guys,
I'm writing some code for 16 bit and have code split into segments. This 
means I need to create a Far version of new, but I don't know much about 
malloc - can anyone show me what operator new looks like?

Thanks

_________________________________________________________________
Find a cheaper internet access deal - choose one to suit you. 
http://www.msn.co.uk/internetaccess

RE: [Dev-C++] STL Map question

[Ioannis V. <iv...@em...>]

> -----Original Message-----
> From: Ioannis Vranos [mailto:iv...@em...] 
> Sent: Tuesday, July 15, 2003 3:44 AM
> To: Dev-C++ Mailing List (dev...@li...)
> Subject: RE: [Dev-C++] STL Map question
> 
> Regarding C99 I have read in Usenet (but was too bored to 
> check the standard) that char can have padding bits because 
> they believed that C90 allowed that, while C++ inherited from 
> C90 the fact that a char cannot have padding bits.



And that's indeed true, I just checked C99.






Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

Re: [Dev-C++] String << operator overloaded (using template)

[David M. <ci...@ya...>]

I am curious. Does the same code work if you try to use
more than one "<<"
in a statement?

e.g.
someString << someInt << someFloat;

the line of code that is not doing what it is supposed to
do is as follows.
(temp is a string, ROOT_DIR = const char == "..", dir_names
= map of
strings, DIR_SEP = const char == "\\" under windows, "/"
under *NIX)

temp << ROOT_DIR << DIR_SEP << dir_names[dir] << DIR_SEP <<
filename;

----- Original Message ----- 
From: "Jaap de Wolff" <wo...@ne...>
To: <ci...@ya...>; "Dev-Cpp Mailing List"
<dev...@li...>
Sent: Monday, July 14, 2003 8:25 AM
Subject: RE: [Dev-C++] String << operator overloaded (using
template)


> At my place it works.
> I made a class myclass to test, see below.
>
>
> -----Original Message-----
> >From: David McKen [mailto:ci...@ya...]
> >Sent: Sunday, July 13, 2003 8:02 PM
> >To: Dev-Cpp Mailing List
> >Subject: [Dev-C++] String << operator overloaded (using
template)
> >
> ..
>
> #include <string>
> #include <sstream>
> #include <iostream>
>
>
> class myclass {
> public:
> myclass (int n) { member = n; }
> private:
> int member;
> friend std::iostream& operator<< (std::iostream& str,
class myclass
> &val);
> };
>
> std::iostream& operator<< (std::iostream& str, class
myclass &val){str <<
> val.member;return str;}
>
>
> template <class in_type>
> std::string& operator<< (std::string& output, in_type&
data)
> {
>   std::stringstream ss;
>   ss << data;
>   ss >> output;
>   return output;
> }
>
>
> void main()
> {
> std::stringstream ss;
> std::string sout;
> myclass hulp (15);
> sout << hulp;
> std::cout << sout;
> }
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE:
http://www23.brinkster.com/noicys/devcpp/ub.htm
>
https://lists.sourceforge.net/lists/listinfo/dev-cpp-users


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

RE: [Dev-C++] STL Map question

[Ioannis V. <iv...@em...>]

> -----Original Message-----
> From: dev...@li... 
> [mailto:dev...@li...] On Behalf 
> Of Per Westermark
> Sent: Tuesday, July 15, 2003 2:47 AM
> To: Shane Bryldt
> Cc: Jaap de Wolff; C++
> Subject: Re: [Dev-C++] STL Map question
> 
> 
> In your text you mentioned something about the original code zeroing
> arrays on erase and performing reallocation.
> 
> Just a note about a very important difference between C and 
> C++. In C it
> is always safe to use memset() or ZeroMemory etc to clear a struct


You are in general right with an exception. 0 value is not necessarily in
all types all bits zero (which is the 0 of a char/byte). Also a struct or a
type may have padding bits and 0ing all its bytes calls for trouble.


Regarding C99 I have read in Usenet (but was too bored to check the
standard) that char can have padding bits because they believed that C90
allowed that, while C++ inherited from C90 the fact that a char cannot have
padding bits.


That's funny eh?






Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

Re: [Dev-C++] STL Map question

[Per W. <pw...@ia...>]

In your text you mentioned something about the original code zeroing
arrays on erase and performing reallocation.

Just a note about a very important difference between C and C++. In C it
is always safe to use memset() or ZeroMemory etc to clear a struct
directly after allocation. You might also do it at any other time during
the life of the struct with one little caveat. If the struct contained
pointers to other data you might introduce a memory leak.

However, in C++ it is not generally safe to perform memset() of a struct.
If the object in question either is part of a multiple-inherritance
hierarchy, has virtual methods, supports dynamic typecast etc, memset()
might erase hidden data fields that are initialized by the object
constructor.

This kind of problem is very easily introduced in source code that
originated as C, and then gradually transformed into C++. The result of
overwriting a VMT - Virtual Method Table - field of an object is fatal and
is guaranteed to bite hard.

One other thing is that the STL code assumes that it controls the memory,
and does not like someone else to try and reallocate items. The actual
containers may not be reallocated, and if individual elements of the
containsers needs to be reallocated, they should first be removed from the
container, then reallocated and inserted again.

/Per W

On Mon, 14 Jul 2003, Shane Bryldt wrote:

> The original implementation used some very obscure direct
> manipulation of array's, such that it would zero out array's when they
> weren't used, yet left them allocated. And in some other cases, would
> actually call realloc to reallocate the memory.

Re[2]: [Dev-C++] new mail

[Zodiaq <zo...@ac...>]

Hello Nathan and all Dev-C++ users,

Tuesday, July 15, 2003, 1:01:50 AM, Nathan wrote as follows:

NS> And those 75 lines of text painfully destroyed 1 second of your life.

You have no mercy for any modem users! Shame on you!
;-]

btw. when reply-to: will be changed?

-- 
regards, Zodiaq

Re: [Dev-C++] new mail

[Nathan S. <cat...@do...>]

And those 75 lines of text painfully destroyed 1 second of your life.

----- Original Message ----- 
From: "Zodiaq" <zo...@ac...>
To: <Dev...@li...>
Sent: Tuesday, July 15, 2003 1:47 AM
Subject: Re: [Dev-C++] new mail


> Hello Nathan and all Dev-C++ users,
> 
> Monday, July 14, 2003, 5:04:35 PM, Nathan wrote as follows:
> 
> NS> This spammer has also been spamming my normal email address.
> 
> And do you think you are any better than he is?! He is doing this for
> profit, you out of (excuse me next word, but I can't find any more
> suitable) stupidy! You cited over 65 lines of useless text to add just
> one! Thanx to you now that spam was 75 lines long - could please START
> thniking?! Ehhh...
> 
> -- 
> regards, Zodiaq
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> 

RE: [Dev-C++] STL Map question

[Ioannis V. <iv...@em...>]

> -----Original Message-----
> From: dev...@li... 
> [mailto:dev...@li...] On Behalf 
> Of Shane Bryldt
> Sent: Monday, July 14, 2003 11:04 PM
> To: Jaap de Wolff
> Cc: C++
> Subject: Re: [Dev-C++] STL Map question
> 
> 
> After speaking with a few people, it appears to me that the 
> problem is not
> at all with STL, at least not the fault of STL, but rather of original
> implementation. 

[...]


It appears that you are an OK C programmer but missing the key concepts of
C++. I suggest you read "The C++ Programming Language" 3rd Edition or
Special Edition by Bjarne Stroustrup (the creator of C++), cover to cover.
It will take years, it will have pain but that's how knowledge is aquired.


 
> A last note, just to get a couple opinions.  The original 
> code that worked,
> would delete users as they were disconnected. The newer code, 
> using the same
> concept for UserList, crashes.  What I have done (but not yet 
> tested) is
> changed the code where it delete's the User, instead of 
> deleting them, it
> sets a flag indicating they are ready to be processed for 
> deletion. At the
> top of every loop iteration, it generates a vector of Killed 
> connections,
> then steps through the vector and deletes them from the user 
> list map.  The
> change in implementation of how the User is deleted may lend itself to
> fixing the problem in certain very strange conditions.  Does 
> anyone see a
> flaw with how I changed the code? I haven't tested it yet, beyond a
> controlled environment where the crash wouldn't occur 
> anyways


Flags? See what I wrote above.


>.  I'm hoping
> with little hope that it may simply be a matter of iterator 
> invalidation,
> and by not deleting the User and removing it right away, it 
> might (??? I'm
> really running out of ideas) fix the problem.


I have already told you what to do. Use the containers with *objects*, not
pointers.

E.g. map<string, User>Users;


map<string, User>::iterator p=Users.find("Zefxes");


if(p!=Users.end())
{
 // ...


// Zefxes is erased
 Users,erase(p));


// Users["Zefxes"] now returns User(0)
// Users.find("Zefxes") now returns Users.end()
}






Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

RE: [Dev-C++] STL Map question

[Ioannis V. <iv...@em...>]

> -----Original Message-----
> From: dev...@li...=20
> [mailto:dev...@li...] On Behalf=20
> Of Shane Bryldt
> Sent: Monday, July 14, 2003 11:14 PM
> To: Hossein Haeri
> Cc: C++
> Subject: Re: [Dev-C++] STL Map question
>=20
> When it breaks out into GDB in the crash,=20
> it leaves me at
> a "map::find" statement, which, when I step into it, I find=20
> that the key (an
> std::string) is valid, but the data portion, a pointer to an=20
> allocated User,
> is somehow fubar'd, because if I try to print (no different=20
> than getting the
> value of a variable in VC++ debugger) the pointer, GDB itself=20
> will indicate
> that the program crashed while attempting to execute=20
> something by GDB.  This
> means that 1) the code crashes and drops me into the=20
> debugger, and 2) it is
> in fact crashing because of the variable value, as executing=20
> the single
> operation of printing the value causes an internal crash that=20
> GDB recovers
> from, but ends execution of the program.


This is happening because you use the library in an improper C style =
way.
Had the map contained objects instead of pointers you would find no =
record
when you used the find() and would get User(0) when accessed the key =
using
operator[]. Better use C++ as C++ and not as C.


Quiz of the day: How do you write generic functions in C and how in C++? =
:-)



=20
> The problem I am seeing, I have never seen in all my time=20
> programming, and I
> have a good 8 years background with C.  Further issues with=20
> this, may result
> in me reverting UserList to a true linked list=20
> implementation, instead of
> STL, which could be the culprit even though I don't want to=20
> blame it.=20


!!!  The problem is your programming approach, not the standard library!



> Even
> reverting temporarily to a C linked list may help me in=20
> travelling the list
> in the debugger to find out where the problem is (like if=20
> it's the last or
> first element, etc)...  Short of testing my new changes, this=20
> will be the
> next step, to revert to a very slow and simple linked list=20
> until I can track
> down the problem.  At least I have some direction, I=20
> appreciate the help
> everyone has offered.


The standard library provides a double linked list implementation,
std::list. But your problem is that you code in C with classes, not C++!






Ioannis Vranos
=20
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

Re: [Dev-C++] STL Map question

[Shane B. <ast...@te...>]

GCC is the GNU compiler collection, it includes front ends for C, C++, ADA,
Fortran and some others as I recall. GDB, is the GNU debugger.  It is a
commandline debugging utility, commonly used on unix based systems.  If
you've ever added -g (or -ggdb), you're adding debugging code that GDB uses
for debugging.  Comparative to Win32 DEBUG versus RELEASE compilations on
VC++.  GDB itself, I used mostly for tracing crash's and viewing memory.
This is how I've determined that the crash occurs when trying to access an
invalid pointer.  When it breaks out into GDB in the crash, it leaves me at
a "map::find" statement, which, when I step into it, I find that the key (an
std::string) is valid, but the data portion, a pointer to an allocated User,
is somehow fubar'd, because if I try to print (no different than getting the
value of a variable in VC++ debugger) the pointer, GDB itself will indicate
that the program crashed while attempting to execute something by GDB.  This
means that 1) the code crashes and drops me into the debugger, and 2) it is
in fact crashing because of the variable value, as executing the single
operation of printing the value causes an internal crash that GDB recovers
from, but ends execution of the program.

The problem I am seeing, I have never seen in all my time programming, and I
have a good 8 years background with C.  Further issues with this, may result
in me reverting UserList to a true linked list implementation, instead of
STL, which could be the culprit even though I don't want to blame it.  Even
reverting temporarily to a C linked list may help me in travelling the list
in the debugger to find out where the problem is (like if it's the last or
first element, etc)...  Short of testing my new changes, this will be the
next step, to revert to a very slow and simple linked list until I can track
down the problem.  At least I have some direction, I appreciate the help
everyone has offered.

Sincerely,
    -Shane
p.s. http://www.gnu.org/software/gdb, for all the information you want on
GDB.

----- Original Message ----- 
From: "Hossein Haeri" <ult...@em...>
To: <dev...@li...>
Sent: Monday, July 14, 2003 10:39 AM
Subject: RE: [Dev-C++] STL Map question


> Dear Ioannis,
>
> > Keep in mind that there is the mailing list archive on line (which is
> > unfortunately 12/24h behind but anyway):
> >
> > http://sourceforge.net/mailarchive/forum.php?forum=dev-cpp-users
>
> Thanks! It was quite useful. Furthermore, I didn't know the address of
> the page. Thank you very much indeed.
>
> And about the compiler: I found out that you had mentioned its name as
> "GDB". And that's what I haven't ever heard about, and not GCC. Now,
> may I ask what it stands for?
>
> Thanks,
> --Hossein
>
> -- 
> __________________________________________________________
> Sign-up for your own FREE Personalized E-mail at Mail.com
> http://www.mail.com/?sr=signup
>
> CareerBuilder.com has over 400,000 jobs. Be smarter about your job search
> http://corp.mail.com/careers
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users

Re: [Dev-C++] STL Map question

[Shane B. <ast...@te...>]

Actually, the program is making use of threads now, but all the memory each
thread is accessing, is independant of the memory the main thread is
accessing.  To be painfully clear, the threads are used only to offload the
intensive process of dumping 60,000 records to a MySQL database.  What
happens, is the database is dumped to a text file within a couple seconds,
then a thread is created to open each of the sql dump files made, and
read/import into the MySQL database.  Functionally, it works perfectly and
the database has never had a problem dumping.  The ONLY thing shared between
the threads, is a call to a function "Log" which is used once per thread, to
output to the logs that it's finished.  Realizing the potential, a mutex
should be used on the Log class to prevent any accidental access at the same
time, but in the future I intend on pulling out the calls to "Log" and at
such a time there will be no use of shared memory, and thus no reason for
threads to be of concern.

    As is stands now, I am not willing to believe that the shared call to
Log is the culprit, as it would be a more random occurance of crashes, not
always at the exact same point in the code.  In fact, the point it's
crashing at, the threads never use.  The threads don't even iterate the
map's, they simply open an already closed file after it's been dumped, and
then reads the file, imports to the database, and delete's the sql dump
files to indicate it is done (rather than using shared memory, the file not
existing is just as well).

After speaking with a few people, it appears to me that the problem is not
at all with STL, at least not the fault of STL, but rather of original
implementation. The original implementation used some very obscure direct
manipulation of array's, such that it would zero out array's when they
weren't used, yet left them allocated. And in some other cases, would
actually call realloc to reallocate the memory.  This caused a little
confusion in the conversion to STL, with regards to performing the identical
operation with STL, and not changing the code calling on STL too
significantly.  The truely strange problem is that between the two changes
of the code, the UserList code was not changed, other code that calls it
was, and so therein lies the problem. However, I am not skilled enough to
know of any good tools that can help me determine why the pointer being
accessed is invalid.  More particularily, if there was a debugging tool for
checking memory, like the last time it was used before the crash occured, if
it could show me where it was free'd, or overwritten or whatever is
happening, I could most likely determine the cause, given a location as
general as a function it's occuring in.  Unfortunately, I have scanned over
the code numerous times and can only find 1 location where a User class is
delete'd.  And calls to that function appear to be called appropriately with
consideration for STL.

I am truely baffled, but I have given up blaming STL for the issue, there
has to be an overrun of memory writing, or somehow, something has
invalidated the memory that an STL map is still using.  There is no reason
for this, and another very seasoned programmer has looked at the code with
no immediate noticable problems.  If I wasn't in a position of
non-disclosure (actually, it's more like on my word that I won't release the
code, I can discuss the problems as I need to with other programmers), I
would tarball the code in question.  However, with as complicated as the
code is, even a vetran programmer wouldn't want to dig into it without a lot
of patience and time, of which I could not ask of anyone anyways.

I thank everyone for exhausting their ideas, even if this thread ended up
more of a flame war about who thinks what the best book is.  Unfortunately,
this problem is not resolved by any amount of books, regardless of how good
they are.  The problem is in implementation, not lack of understanding.  I
am almost certain that the map iterator has become invalid, and that's
causing the problem. But why, is the question regarding implementation.

A last note, just to get a couple opinions.  The original code that worked,
would delete users as they were disconnected. The newer code, using the same
concept for UserList, crashes.  What I have done (but not yet tested) is
changed the code where it delete's the User, instead of deleting them, it
sets a flag indicating they are ready to be processed for deletion. At the
top of every loop iteration, it generates a vector of Killed connections,
then steps through the vector and deletes them from the user list map.  The
change in implementation of how the User is deleted may lend itself to
fixing the problem in certain very strange conditions.  Does anyone see a
flaw with how I changed the code? I haven't tested it yet, beyond a
controlled environment where the crash wouldn't occur anyways.  I'm hoping
with little hope that it may simply be a matter of iterator invalidation,
and by not deleting the User and removing it right away, it might (??? I'm
really running out of ideas) fix the problem.

Sincerely,
    -Shane

----- Original Message ----- 
From: "Jaap de Wolff" <wo...@ne...>
To: "'Shane Bryldt'" <ast...@te...>; "Hossein Haeri"
<ult...@em...>
Cc: "C++" <dev...@li...>
Sent: Monday, July 14, 2003 6:36 AM
Subject: RE: [Dev-C++] STL Map question


> Hmm, I had problems like this also.
> Are you using a multithreaded environment?
> Is it possible that sometimes two threads at the same time are accessing
the
> map,
> one for removing a key, and one for finding a key?
>
> Jaap
>
> > -----Original Message-----
> > From: Shane Bryldt [mailto:ast...@te...]
> > Sent: Friday, July 11, 2003 10:53 PM
> > To: Hossein Haeri
> > Cc: C++
> > Subject: Re: [Dev-C++] STL Map question
> >
> ...
> >
> > Now, the effect of the issue, is as follows. A network of 6,000-10,000
> > active users at any given time is regulated by a security
> > service.  This
> > service runs and connects like a user, with special
> > priviledges.  Anytime a
> > user connects to the network, the services is informed, and
> > the User is
> > added to a global UserList.  The network also has smaller
> > units, known as
> > Channels.  Each Channel contains 3 UserList's as well.
> > First, depicts all
> > users in the Channel, the second depicts all the operators of
> > the channel,
> > and the third depicts the priviledged users who are not
> > operators.  99% of
> > the time, the code work fine.  Users constantly added and
> > removed from the
> > list.  Periodically, what seems like an issue without a
> > pattern, the code
> > will crash with a segmentation fault while trying to call
> > "std::map<>::find()", with a valid key.  Whether the key is
> > in the map, is
> > not definate, but the key passed in valid and should not have
> > a problem
> > being searched.
> >
> > This said, I have narrowed the issue down to one of 2 causes.
> > 1) Either
> > User's are being added to lists, and not being removed, and
> > the UserLists
> > are eventually gathering enough garbage that out of memory is being
> > encountered. The application has a signal hook for out of
> > memory, and it is
> > not being raised.  So I am leaning more towards option 2) The
> > User class is
> > being deleted, without being removed from the UserList.
> > However, I can find
> > no indication of this in the code.  The code is many
> > thousands of lines, it
> > is not a small project by any means.  Providing the source
> > for the issue,
> > would require the entire project as the issue is not
> > specifically a syntax
> > issue, but rather a situational issue.  I do believe something has
> > invalidated a User class, which a UserList has a pointer to,
> > and when trying
> > to use it, is causing a segmentation fault.  I'm sure most of
> > the experts
> > here will agree with my conclusion and realize tracing this
> > problem is no
> > easy task.
> >
> >
> ...
>

Re: [Dev-C++] Creating a Win32 Application.

[<or...@vp...>]

Rackley, Nathanael Pratt wrote:

> Hello.  I'm new to Dev-CPP, and I was wondering if it is possible to 
> find a good tutorial explaining how to create and modify Windows 
> applications.
> 
> I just want to learn how to perform basic functions, such as create 
> controls like text boxes and command buttons.  Is there a tutorial where 
> I can learn any of this?

Yes, I think the best tutorial comes from the original author of the 
Win32 API for MinGW (or simply MinGW itself), Colin Peters.

Here is the link:
http://webclub.kcom.ne.jp/ma/colinp/win32/index.html

And his homepage:
http://webclub.kcom.ne.jp/ma/colinp/

Good luck!
--
Greetings,
   Balázs

RE: [Dev-C++] STL Map question

[Ioannis V. <iv...@em...>]

> -----Original Message-----
> From: dev...@li... 
> [mailto:dev...@li...] On Behalf 
> Of Hossein Haeri
> Sent: Monday, July 14, 2003 8:51 PM
> To: dev...@li...
> Subject: RE: [Dev-C++] STL Map question
> 
> > :-)
> 
> Sorry, but I can't view these cute faces because my mail server
> provides text only.



Man you are very new to the Net. :-)



> > Also  bool empty() const {  return size()==0; } takes constant time.
> 
> Hmmm.... The only operation you have neglected is operator[]. 


Yes you are right.


> But there
> is another fine point. That is, when you are going to insert or erase
> only one element, it is extremely easy to update size, but 
> when dealing
> with range counterparts, the story is not that easy.


I do not think that it would be so difficult (e.g. --size; for every item
erased, where size the internal representation of size, and without any
checks if size>0).

In any case, map<>::empty() is a right solution to check whether the map is
empty, so in reality we have been quibbling the details here.






Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

RE: [Dev-C++] STL Map question

[Ioannis V. <iv...@em...>]

> -----Original Message-----
> From: dev...@li... 
> [mailto:dev...@li...] On Behalf 
> Of Hossein Haeri
> Sent: Monday, July 14, 2003 7:40 PM
> To: dev...@li...
> Subject: RE: [Dev-C++] STL Map question
> 
> And about the compiler: I found out that you had mentioned its name as
> "GDB". And that's what I haven't ever heard about, and not GCC. Now,
> may I ask what it stands for?



GDB is the debugger, but I have never used it. The original poster had
provided us with the output of GDB.






Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

RE: [Dev-C++] STL Map question

[Hossein H. <ult...@em...>]

Ioannis,

> > Had you read "Effective STL," this has't been your answer. 
> 
> 
> :-)

Sorry, but I can't view these cute faces because my mail server
provides text only.

> > Sometimes,
> > there are policies such as willing to have a constant-time operation
> > on the map that have higher proiority for the implementer (for any
> > reason they know). And achieving that runtime needs you to cut down
> > the use of size update after any operation of the map.
> 
> 
> Not any operation, size() has to be updated during insert() or erase() only.
> 
> Also  bool empty() const {  return size()==0; } takes constant time.

Hmmm.... The only operation you have neglected is operator[]. But there
is another fine point. That is, when you are going to insert or erase
only one element, it is extremely easy to update size, but when dealing
with range counterparts, the story is not that easy.

> > I think the existance of nasty C++ implementations such as VC++6,
> > reveals that this is not just a fiction, and there even are wellknown
> > implementations who may have chosen that way.
> 
> 
> Anyway we are talking without any basis here, ...

Maybe! I don't have any problem if you don't want to continue it.

> ... the implementor can choose
> whatever method he likes to implement size() but if he calculated size()
> everytime it was called (or only the first time if no other change has been
> made) would be unwise since our code would wait for the internal loop of our
> thousands record counting to complete.
> 
> In any case one would expect that the perofmrmance of size() in a if()
> statement wouldn't take 10 seconds. TC++PL provides the above check as a
> reasonable implementation I agree with it.

There may be some trade-off as I told. Anyway...

> > You'r right. But max-performance of what? I mean, if there is an
> > operation, say O, that has higher priority from your point of view (as
> > the implementer, or disigner, etc.), and you want O to be done in a
> > constant time, and that forces you to forget updating size after O,
> > will you still think that max-performance obliges you to have size as
> > an internal member? 
> 
> 
> There is not any Big-Oh requirement of the standard both regarding size() or
> empty(). In theory empty() could be slower than size() (since there is not
> any kind of restriction), but I said let's try to be realists.

Theoritically, yes.

> I used VC++ 6 only to what it is best for. To learn C90. :-) Regarding ISO
> C++ it is crap. VC++ .NET 2002/2003 on the other hand are very good
> regarding C++ compliance.

I haven't still heard anything opposing that. But it takes time to see
what botchs it has, if any. (Generally, nothing in Software-houses such
as Microsoft is reliable.) So far, I agree with you.

> > I have just
> > realised that the compiler we were talking about was GCC, and I 
> > hartapologise for the suspection I have had to his majesty. But
> > remember that I didn't know that's GCC. Knowing that, don't you still
> > preserve me the right of suspecting the implementation?
> 
> 
> Well I would start suspecting if the code was crawling.

Right!

> Does VC++ 6 crawl whem map::size() is used?

I'm not sure in this specific case, but I have encountered several
similar situations. Please don't ask me to enumerated them, because I
haven't documented them. But you can make search on interenet.

Wishes,
--Hossein
-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

CareerBuilder.com has over 400,000 jobs. Be smarter about your job search
http://corp.mail.com/careers

RE: [Dev-C++] need help!

[<Tod...@De...>]

Adam,

Thank you very much....I think I found the function that i need to use now..
these 2 site helped me alot...

:-)

todd c.

-----Original Message-----
From: Adam Malinowski [mailto:up...@in...]
Sent: Monday, July 14, 2003 11:25 AM
To: dev...@li...
Subject: Fw: [Dev-C++] need help!


 >Anyway, I am still looking for those function but still can not find it..
I
 >will looking for a book for these. thanks you all your help. :-)

 I'm not sure what kind of system do you use.
 If it is windows check this site:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base
 /findfirstfile.asp

If you don't want to use Win32 Api check this one:
http://www.delorie.com/djgpp/doc/libc/libc_11.html#SEC11

 Adam.





-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
_______________________________________________
Dev-cpp-users mailing list
Dev...@li...
TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
https://lists.sourceforge.net/lists/listinfo/dev-cpp-users

RE: [Dev-C++] STL Map question

[Hossein H. <ult...@em...>]

Dear Ioannis,

> Keep in mind that there is the mailing list archive on line (which is
> unfortunately 12/24h behind but anyway):
> 
> http://sourceforge.net/mailarchive/forum.php?forum=dev-cpp-users

Thanks! It was quite useful. Furthermore, I didn't know the address of
the page. Thank you very much indeed.

And about the compiler: I found out that you had mentioned its name as
"GDB". And that's what I haven't ever heard about, and not GCC. Now,
may I ask what it stands for?

Thanks,
--Hossein

-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

CareerBuilder.com has over 400,000 jobs. Be smarter about your job search
http://corp.mail.com/careers

Fw: [Dev-C++] need help!

[Adam M. <up...@in...>]

 >Anyway, I am still looking for those function but still can not find it..
I
 >will looking for a book for these. thanks you all your help. :-)

 I'm not sure what kind of system do you use.
 If it is windows check this site:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base
 /findfirstfile.asp

If you don't want to use Win32 Api check this one:
http://www.delorie.com/djgpp/doc/libc/libc_11.html#SEC11

 Adam.

RE: [Dev-C++] STL Map question

[Ioannis V. <iv...@em...>]

> -----Original Message-----
> From: dev...@li...=20
> [mailto:dev...@li...] On Behalf=20
> Of Hossein Haeri
> Sent: Monday, July 14, 2003 3:19 PM
> To: dev...@li...
> Subject: RE: [Dev-C++] STL Map question
>=20
>=20
> Had you read "Effective STL," this has't been your answer.=20


:-)


> Sometimes,
> there are policies such as willing to have a constant-time operation
> on the map that have higher proiority for the implementer (for any
> reason they know). And achieving that runtime needs you to cut down
> the use of size update after any operation of the map.


Not any operation, size() has to be updated during insert() or erase() =
only.

Also  bool empty() const {  return size()=3D=3D0; } takes constant time.


=20
> I think the existance of nasty C++ implementations such as VC++6,
> reveals that this is not just a fiction, and there even are wellknown
> implementations who may have chosen that way.


Anyway we are talking without any basis here, the implementor can choose
whatever method he likes to implement size() but if he calculated size()
everytime it was called (or only the first time if no other change has =
been
made) would be unwise since our code would wait for the internal loop of =
our
thousands record counting to complete.

In any case one would expect that the perofmrmance of size() in a if()
statement wouldn't take 10 seconds. TC++PL provides the above check as a
reasonable implementation I agree with it.



> You'r right. But max-performance of what? I mean, if there is an
> operation, say O, that has higher priority from your point of view (as
> the implementer, or disigner, etc.), and you want O to be done in a
> constant time, and that forces you to forget updating size after O,
> will you still think that max-performance obliges you to have size as
> an internal member?=20


There is not any Big-Oh requirement of the standard both regarding =
size() or
empty(). In theory empty() could be slower than size() (since there is =
not
any kind of restriction), but I said let's try to be realists.


> Haven't you ever encountered nasty
> implementations such as VC++6 that often have such higher priority
> operations that don't seem to be reasonable at all?



I used VC++ 6 only to what it is best for. To learn C90. :-) Regarding =
ISO
C++ it is crap. VC++ .NET 2002/2003 on the other hand are very good
regarding C++ compliance.



> I have just
> realised that the compiler we were talking about was GCC, and I=20
> hartapologise for the suspection I have had to his majesty. But
> remember that I didn't know that's GCC. Knowing that, don't you still
> preserve me the right of suspecting the implementation?


Well I would start suspecting if the code was crawling.

=20
> I agree with you in the sense of efficiency, but remember the problem
> with (sometimes unwanted) priorities.
>=20
> Furthermore, sometimes, the dicision of throwing a platform away is
> not whithin our duty. Nor can we complain on it. E.g., the project may
> be in a platform that is used for years and years, and changing it
> imposes more cost to the wendors. As an other example, you may be one
> of the ordinary programmers in more than 1000, in a software-house
> that wants its products to have good GUIs, and so have chosen VC++6 as
> they don't want to waste time for reinvnting the wheel! They may well
> know about the vast erea of VC++6's bugs, but they have to tollerate
> against it. So they are not going to change the platform. What would
> you do then?


Does VC++ 6 crawl whem map::size() is used?






Ioannis Vranos
=20
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

RE: [Dev-C++] STL Map question

[Ioannis V. <iv...@em...>]

 -----Original Message-----
> From: dev...@li... 
> [mailto:dev...@li...] On Behalf 
> Of Hossein Haeri
> Sent: Monday, July 14, 2003 2:22 PM
> To: dev...@li...
> Subject: Re: [Dev-C++] STL Map question
> 
> but as I remember, the name of the implementation you had
> mentioned contained a 'D' letter, didn't it? (I have deleted that
> message so I can't check it anymore.)


Keep in mind that there is the mailing list archive on line (which is
unfortunately 12/24h behind but anyway):

http://sourceforge.net/mailarchive/forum.php?forum=dev-cpp-users






Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

Re: [Dev-C++] new mail

[Zodiaq <zo...@ac...>]

Hello Nathan and all Dev-C++ users,

Monday, July 14, 2003, 5:04:35 PM, Nathan wrote as follows:

NS> This spammer has also been spamming my normal email address.

And do you think you are any better than he is?! He is doing this for
profit, you out of (excuse me next word, but I can't find any more
suitable) stupidy! You cited over 65 lines of useless text to add just
one! Thanx to you now that spam was 75 lines long - could please START
thniking?! Ehhh...

-- 
regards, Zodiaq

[Dev-C++] Creating a Win32 Application.

[Rackley, N. P. <np...@sa...>]

Hello.  I'm new to Dev-CPP, and I was wondering if it is possible to find a
good tutorial explaining how to create and modify Windows applications.

I just want to learn how to perform basic functions, such as create controls
like text boxes and command buttons.  Is there a tutorial where I can learn
any of this?

Thanks for the help!

-DK

Re: [Dev-C++] new mail tVymMViB

[Nathan S. <cat...@do...>]

VGhpcyBzcGFtbWVyIGhhcyBhbHNvIGJlZW4gc3BhbW1pbmcgbXkgbm9ybWFsIGVtYWlsIGFk
ZHJlc3MuDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIlNtdXJm
LCBQYXBhIiA8c211cmZfd3d3QHhzNGFsbC5ubD4NClRvOiAiRGV2LWNwcC11c2VycyIgPGRl
di1jcHAtdXNlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0Pg0KU2VudDogTW9uZGF5LCBKdWx5
IDE0LCAyMDAzIDEwOjMwIFBNDQpTdWJqZWN0OiBSRTogW0Rldi1DKytdIG5ldyBtYWlsIHRW
eW1NVmlCDQoNCg0KPiBDYW4gc29tZW9uZSBwbGVhc2UgYmxvY2sgdGhpcyBzcGFtbWVyPw0K
Pg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkZXYtY3BwLXVzZXJz
LWFkbWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KPiBbbWFpbHRvOmRldi1jcHAtdXNlcnMt
YWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0XU9uIEJlaGFsZiBPZg0KPiBnZXJnQHVuaXNv
bHZlLmNvbS5hdQ0KPiBTZW50OiBtYWFuZGFnIDE0IGp1bGkgMjAwMyAxNDoxNg0KPiBUbzog
RGV2LWNwcC11c2Vycw0KPiBTdWJqZWN0OiBbRGV2LUMrK10gbmV3IG1haWwgdFZ5bU1WaUIN
Cj4NCj4NCj4gRW5nbGlzaCB2ZXJzaW9uICB8ICDQ8/Hx6ujpIOLg8Ojg7fINCj4NCj4gzPsg
8ODk+yDv8OXk6+7m6PL8IOLg7CDt7uL76SDh5fHv6+Dy7fvpIO/u9/Lu4vvpIPHl8OLo8Q0K
PiBodHRwOi8vd3d3Lm1haWwxNS5jb20uIMXj7iDu8uvo9+jy5ev87fvlIO7x7uHl7e3u8fLo
Og0KPiAxKSDw4Ofs5fAg//no6uAgMTUg7OE7DQo+IDIpIOfg+ej55e3t7vHy/CDoIO3g5OXm
7e7x8vw7DQo+IDMpIOLu5+zu5u3u8fL8IOjx7+7r/Ofu4uDt6P8g6/7h+/Ug7+738u7i+/Ug
7/Du4/Dg7OwoUE9QLElNQVAsU01UUCk7DQo+IDQpIOTu8fLz7yDo5yDr/uHu4+4g7OXx8uAg
4iDr/uHu5SDi8OXs/zsNCj4gNSkg7/Du8fLu6SDoIOTu8fLz7+376SDi5eHo7fLl8PTl6fEg
8SDPzsvN28wgztLR09LR0sLIxcwg0MXKy8DM2zsNCj4gNikg4O3y6OLo8PPx7fvpIOgg4O3y
6PHv4Ozu4vvpIOru7fLw7uv8Ow0KPiA3KSDs4+3u4uXt7eD/IO/l8OXx++vq4CDv7vfy+y4N
Cj4NCj4gxfHr6CDi+yDt5SD17vLo8uUg7+7r8/fg8vwg4e7r5eUg5ODt7fP+IPDg8fH76+rz
LCDv6Pjo8uUNCj4gbWFpbHRvOnVuc3Vic2NyaWJlQG1haWwxNS5jb20/c3ViamVjdD11bnN1
YnNjcmliZQ0KPg0KPiAqKioqKioqKioqKioqDQo+DQo+ICBXZSBhcmUgZ2xhZCB0byBpbnZp
dGUgeW91IGF0IG5ldyBmcmVlIG1haWwgc2VydmljZSBodHRwOi8vd3d3Lm1haWwxNS5jb20u
DQo+IFRoZSBhZHZhbnRhZ2VzIG9mIHRoaXMgc2VydmljZSBhcmU6DQo+ICAxKSBtYWlsYm94
LCB1cCB0byAxNSBNYjsNCj4gIDIpIGFic29sdXRlIHByaXZhY3kgYW5kIGhpZ2ggcmVsaWFi
aWxpdHk7DQo+ICAzKSBhYmlsaXR5IHRvIHVzZSBtYWlsIGNsaWVudHMgKFBPUDMsIElNQVA0
LCBTTVRQKTsNCj4gIDQpIGFjY2VzcyBmcm9tIGFueXdoZXJlLCBhbnl0aW1lOw0KPiAgNSkg
ZmxleGlibGUgbGlnaHQtd2VpZ2h0IHdlYiBpbnRlcmZhY2Ugd2l0aG91dCBhZHZlcnRpc2lu
ZyBiYW5uZXJzOw0KPiAgNikgYW50aXZpcnVzIGFuZCBhbnRpc3BhbSBjb250cm9sOw0KPiAg
NykgZmFzdCBtYWlsIHRyYW5zZmVyOw0KPiAgOCkgaGlnaCBzcGVlZCBuZXR3b3JrIGNoYW5u
ZWw7DQo+ICA5KSBmbGV4aWJsZSBsaWdodC13ZWlnaHQgd2ViIGludGVyZmFjZTsNCj4gIDEw
KSB3aWRlIHNwcmVhZCBhYmlsaXR5IG9mIG1haWwgZmlsdGVyaW5nIGFuZCBmb3J3YXJkaW5n
IG1haWw7DQo+ICAxMSkgY2xvY2sgYXJvdW5kIHN1cHBvcnQ7DQo+DQo+ICBJZiB5b3Ugd2lz
aCB0byBiZSByZW1vdmVkOg0KPiBtYWlsdG86dW5zdWJzY3JpYmVAbWFpbDE1LmNvbT9zdWJq
ZWN0PXVuc3Vic2NyaWINCj4NCj4gdFVxZTVCeW5kVA0KPg0KPg0KPg0KPiAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFRoaXMg
U0YuTmV0IGVtYWlsIHNwb25zb3JlZCBieTogUGFyYXNvZnQNCj4gRXJyb3IgcHJvb2YgV2Vi
IGFwcHMsIGF1dG9tYXRlIHRlc3RpbmcgJiBtb3JlLg0KPiBEb3dubG9hZCAmIGV2YWwgV2Vi
S2luZyBhbmQgZ2V0IGEgZnJlZSBib29rLg0KPiB3d3cucGFyYXNvZnQuY29tL2J1bGxldHBy
b29mYXBwczENCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj4gRGV2LWNwcC11c2VycyBtYWlsaW5nIGxpc3QNCj4gRGV2LWNwcC11c2Vyc0Bs
aXN0cy5zb3VyY2Vmb3JnZS5uZXQNCj4gVE8gVU5TVUJTQ1JJQkU6IGh0dHA6Ly93d3cyMy5i
cmlua3N0ZXIuY29tL25vaWN5cy9kZXZjcHAvdWIuaHRtDQo+IGh0dHBzOi8vbGlzdHMuc291
cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL2Rldi1jcHAtdXNlcnMNCj4NCj4gThhIU7Xp
iluie63nyPZqyrRKorqih3m2psa2ibXrstiCang6nlp165VnKilqd3rWreeiicMNCj4grat+
15v2llemun2qs1C9yrrHsmaWKZYr66aberuKy7KLceeuB3rUUNQFICARttr/DQrbdop5teqi
b6Ins/e9yv7mtmi2m/5Ytsu6t36Kenf+WLbPisud+nXrppsNCg0K

RE: [Dev-C++] STL Map question

[Jaap de W. <wo...@ne...>]

Hmm, I had problems like this also.
Are you using a multithreaded environment?
Is it possible that sometimes two threads at the same time are accessing the
map, 
one for removing a key, and one for finding a key?

Jaap

> -----Original Message-----
> From: Shane Bryldt [mailto:ast...@te...]
> Sent: Friday, July 11, 2003 10:53 PM
> To: Hossein Haeri
> Cc: C++
> Subject: Re: [Dev-C++] STL Map question
> 
...
> 
> Now, the effect of the issue, is as follows. A network of 6,000-10,000
> active users at any given time is regulated by a security 
> service.  This
> service runs and connects like a user, with special 
> priviledges.  Anytime a
> user connects to the network, the services is informed, and 
> the User is
> added to a global UserList.  The network also has smaller 
> units, known as
> Channels.  Each Channel contains 3 UserList's as well.  
> First, depicts all
> users in the Channel, the second depicts all the operators of 
> the channel,
> and the third depicts the priviledged users who are not 
> operators.  99% of
> the time, the code work fine.  Users constantly added and 
> removed from the
> list.  Periodically, what seems like an issue without a 
> pattern, the code
> will crash with a segmentation fault while trying to call
> "std::map<>::find()", with a valid key.  Whether the key is 
> in the map, is
> not definate, but the key passed in valid and should not have 
> a problem
> being searched.
> 
> This said, I have narrowed the issue down to one of 2 causes. 
> 1) Either
> User's are being added to lists, and not being removed, and 
> the UserLists
> are eventually gathering enough garbage that out of memory is being
> encountered. The application has a signal hook for out of 
> memory, and it is
> not being raised.  So I am leaning more towards option 2) The 
> User class is
> being deleted, without being removed from the UserList.  
> However, I can find
> no indication of this in the code.  The code is many 
> thousands of lines, it
> is not a small project by any means.  Providing the source 
> for the issue,
> would require the entire project as the issue is not 
> specifically a syntax
> issue, but rather a situational issue.  I do believe something has
> invalidated a User class, which a UserList has a pointer to, 
> and when trying
> to use it, is causing a segmentation fault.  I'm sure most of 
> the experts
> here will agree with my conclusion and realize tracing this 
> problem is no
> easy task.
> 
> 
...