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

Re: [Dev-C++] need some explanation

[<ri...@te...>]

Vlada Djurovic escribió:

>Hi, everybody
>I hope someone can explain this to me. When I write this:
>
>#include <iostream>
>#include <stdlib>
>
>using namespace std;
>
>I get error like "stdlib: No such file or directory".
>When I write  like this:
>#include <iostream>
>#include <stdlib.h>
>
>using namespace std;
>
>everything is fine. I thought that with "using namespace" you don't have
>specify file extension. Why does the compiler complain only about stdlib
>without .h? Can somebody please explain this?
>------------
>Vlada
>
>  
>
The namespaces are used for STL (Standard Template Library) but stdlib.h 
it´s a header for C library:
In a nut shell:
    If you use the standard C  library you must put .h for including headers
    If you use STL you must not use .h and also type 'using namespace stl'

Cheers

[Dev-C++] Errors when compiling with STL linked

[Faust, M. <Mar...@as...>]

 Hi,

When compling the file

 #include <iostream>
 #include <stdlib.h>
 #include <list>

 using namespace std;

  void f()
  {
     list<double> l;
     for (int i=3D0; i<1000000;i++) l.push_back(i);
  }

  int main()
  {
    f();
    system("PAUSE");
    return 0;
  }

with Dev-C++ 4.9.7.0 I get the following strange errors

    std::_STL_mutex_lock::_M_acquire_lock()':
C:/Dev-Cpp/include/c++/bits/stl_threads.h:192: `_M_lock' undeclared (first
use 
   this function) In file included from C:/Dev-Cpp/include/c++/memory:55,
                 from C:/Dev-Cpp/include/c++/string:48,
                 from C:/Dev-Cpp/include/c++/bits/localefwd.h:49,
                 from C:/Dev-Cpp/include/c++/ios:48,
                 from C:/Dev-Cpp/include/c++/ostream:45,
                 from C:/Dev-Cpp/include/c++/iostream:45,
from test.cpp:1:
C:/Dev-Cpp/include/c++/bits/stl_alloc.h: At global scope:
C:/Dev-Cpp/include/c++/bits/stl_alloc.h:575: syntax error before `;' token
C:/Dev-Cpp/include/c++/bits/stl_alloc.h:575: confused by earlier errors,
bailing out make.exe: *** [test.o] Error 1 Execution terminated

What could be wrong with my settings?

M. Faust

Re: [Dev-C++] Backround Color?

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

You can call SetDialogBKColor() in your code (well it's an MFC CWinApp 
member function, so I don't know if you can use it or not).

SetDialogBKColor(255,0,0);  may be an alpha parameter as a fourth parameter, 
I'm not sure.

Daniel






>From: Johan Hörnell <hor...@te...>
>To: <Dev...@li...>
>Subject: [Dev-C++] Backround Color?
>Date: Tue, 25 Feb 2003 12:30:29 +0100
>
>Hi,
>
>Does anyone here ont the list no how to set the background color of a 
>dilogbox declared and described in a resource file? Is it possible to 
>change the color on it?
>
>Thanks in advance!
>//Johan Hörnell


_________________________________________________________________
MSN Messenger - fast, easy and FREE! http://messenger.msn.co.uk

[Dev-C++] Backround Color?

[<hor...@te...>]

Hi,=20

Does anyone here ont the list no how to set the background color of a =
dilogbox declared and described in a resource file? Is it possible to =
change the color on it?

Thanks in advance!
//Johan H=F6rnell

Re: [Dev-C++] need some explanation

[Teodorescu C. <te...@xt...>]

Vlada Djurovic wrote:

>Hi, everybody
>I hope someone can explain this to me. When I write this:
>
>#include <iostream>
>#include <stdlib>
>
>using namespace std;
>
>I get error like "stdlib: No such file or directory".
>When I write  like this:
>#include <iostream>
>#include <stdlib.h>
>
>using namespace std;
>
>everything is fine. I thought that with "using namespace" you don't have
>specify file extension. Why does the compiler complain only about stdlib
>without .h? Can somebody please explain this?
>  
>
In c++ you have libraries like <iostream> old name was <iostream.h> and 
in C++ 98 standard was renamed.
on the other hand stdlib.h is not a c++ standard library is a C standard 
so his name remains the same because C standard has .h names
In other words :
    iostream is a C++ stadard library
    stdlib.h is a C standard library
becarefull at string
    <string> contains class string
    <string.h> contains C like functions for manipulating strings
My sugestions:
    1:Use only one set of libreries like either from C++ or from C never 
mixed up especialy when you use pointers.
    2:Take a look at a C++ standard and the diff betwen C and C++

[Dev-C++] need some explanation

[Vlada D. <dj...@im...>]

Hi, everybody
I hope someone can explain this to me. When I write this:

#include <iostream>
#include <stdlib>

using namespace std;

I get error like "stdlib: No such file or directory".
When I write  like this:
#include <iostream>
#include <stdlib.h>

using namespace std;

everything is fine. I thought that with "using namespace" you don't have
specify file extension. Why does the compiler complain only about stdlib
without .h? Can somebody please explain this?
------------
Vlada

[Dev-C++] Filename case shouldn't matter (overcoming '__gxx_personality_v0')

[Asko K. <ask...@sc...>]

Hi, all!

I moved a project over from VC++ to DevCpp recently and it seems I'm 
hooked! DevCpp is simpler to use than VC++ and since it's free.. Great! 
:)

However, there was one big problem trying to get my source compiling on 
DevCpp. Or rather, once solved, it was minor.

The case of the filenames had changed during transportation so I had 
'MYFILE.C' instead of 'myfile.c' (on WinXP Home running under iMac 
Virtual PC if it matters). Normally, file case does _not_ matter in 
Windows so I didn't pay attention.

Compilation ok, but then I get these 'missing __gxx_personality_v0' 
linker errors. Why?!?

Turns out DevCpp (or rather, gcc) thinks my source is C++ since the 
extension is an uppercase '.C'.
This is utterly confusing to newcomers so my suggestion would be:

	- Always feed Windows filenames to gcc in lowercase. This will make 
DevCpp behave
	  as Windows people expect, and '.cpp' etc. can still be used for C++ 
source.

This way, gcc behaviour itself would not need to be modified, only your 
interfacing with it.

Any downsides to this suggestion?

-ak

Re: [Dev-C++] How to find and kill child windows..

[Danny R. <dro...@ho...>]

I will give it a shot..

thanks for your feedback.

Danny.



----- Original Message -----
From: "Per Westermark" <pw...@ia...>
To: "Danny Roelofs" <dro...@ho...>
Cc: <dev...@li...>
Sent: Monday, February 24, 2003 8:53 PM
Subject: Re: [Dev-C++] How to find and kill child windows..


> I haven't tried, so this might be an embarrasing suggestion but...
>
> Can't you just call GetDesktopWindow() and then iterate through all it's
> child windows. If you don't like a window, you might post a WM_QUIT or
> WM_CLOSE to it.
>
> You might call GetWindowText() - Normally, IE adds it's own text at the
> end of the title.
>
> You might also peek at the window class with GetClassName(), i.e. if the
> window class name is 'IEFrame'.
>
> /Per W
>
> On Mon, 24 Feb 2003, Danny Roelofs wrote:
>
> > Hi,
> >
> > I want to make a simple popup/down killer for the internet explorer, yes
i know that there a lot of programs on this mather
> > but i just want to write my own.. what do i have to know?
> >
> > I actualy need to know the function's.. do i have to find a process
first and then dig into its structure to get a handle
> > to the parant screen before i can kill the child screens?
> >
> >
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

Re: [Dev-C++] Re: malloc , extra bytes ! Not so urgent now .

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

The Win32 API have a long tradition of adding a cbSize (something) entry
to a lot of structures passed to or from the OS. The reason for this is
that the OS might later extend the size of the structures, and by looking
at the size member received from the application, it can differentiate
between an old or new application, i.e. if the application was compiled
with old or new header files.

This allows easy addition of new member values in the structures without
extending or adding new Win32 API functions. It isn't a way around any
malloc() problems, but a way to perform run-time type checking, or
actually a way to perform function overloading depending on what type of
buffer pointer was sent in. An example is GetMonitorInfo() which takes a
MONITORINFO* parameter, or GetOutlineTextMetrics which takes a
OUTLINETEXTMETRIC*, GetOutputFormats with DDPIXELFORMAT*...

One side effect of this is that a lot of GetXX() calls normally fails if
you just do a ZeroMemory() on the structure before the request, and
forgets to set xx.cbSize =3D sizeof(xx).

/Per W

On Tue, 25 Feb 2003, veenurs wrote:

> Enlightening , man !
>
> I don't know much abt . compilers , so tell me -
> When is the decision to allocate ( how much of ) the memory made - at
> compilation or runtime .  If  at runtime , then why did I always got
>  "snug fit" with other compilers ?
> The windows API tutorials are replete  with things like dwFileSize etc,
> which do give you sizes without much fuss ( That data comes from some
> behind the scene  struct members, I guess ) .That's how I was fooled
> into relying on such  tactics with  my own pointers :-0 .Nice timely
> jolt , though  .
> -Rahul .
>
> Per Westermark wrote:
>
> >The main reasons for allicating larger memory blocks than requested are:
> >- Make sure the hidden header before any allocated data are always
> >aligned. Aligned data is faster to access. Also, most processors
> >doesn't support unaligned memory. The x86 series processors are just
> >very-very nice.
> >- Make sure that the returned pointer get a very high alignment -
> >normally at least align 8, to allow perfectly aligned 64-bit integers
> >and doubles. Remember that the runtime library doesn't know if you expec=
t
> >to store 1024 single bytes or 128 doubles in a 1kB request.
> >- Reduce memory fragmentation. By limiting number of allowed block sizes=
,
> >new requests have a higher probability of being able to reuse a previous=
ly
> >released memory block.
> >
> >The buddy system or a binary subdivision are the extremes, where you mig=
ht
> >get +50 - 100% extra memory even for large allocations. The advantages a=
re
> >that they are lightning-fast at locating available blocks or subdividing=
 a
> >too large block into a returnable chunk. When you return a block of
> >memory, they know exactly where the neighbours are, and can check if the
> >neighbour has also been released thereby directly combining multiple
> >released blocks into the next larger block size.
> >
> >/Per W
> >
> >On Mon, 24 Feb 2003, OROSZI Bal=E1zs wrote:
> >
> >
> >
> >>Hello!
> >>
> >>veenurs wrote:
> >>
> >>
> >>>if( (buffer =3D ( PBYTE )calloc( 1000 ,sizeof(BYTE) )) =3D=3D NULL ){
> >>>}
> >>>size =3D _msize( buffer );
> >>>The size I get it is not 1000 , but 1008  !Same for malloc.
> >>>
> >>>
> >> From the C Runtime Library Reference:
> >>
> >>----
> >>Syntax
> >>
> >>#include <malloc.h>
> >>size_t _msize(void *block);
> >>
> >>Description
> >>
> >>Returns the size of a heap block.
> >>
> >>_msize returns the size of the allocated heap block whose address is
> >>block. The block must have been allocated with malloc, calloc, or
> >>realloc. The returned size can be larger than the number of bytes
> >>originally requested when the block was allocated.
> >>
> >>Return Value
> >>
> >>_msize returns the size of the block in bytes.
> >>----
> >>
> >>Especially take care of this sentence:
> >>The returned size can be larger than the number of bytes originally
> >>requested when the block was allocated.
> >>
> >>I suppose the reason for this is because it would take longer to give
> >>you the EXACT amount of memory, so it gives the amount that is nearly
> >>(and at least) what you need, but what can be given the fastest - only
> >>what I think.
> >>
> >>But you should always use the REQUESTED amount, not the actually
> >>RECIEVED amount. If calloc doesn't return NULL, then the requested
> >>amount is at your hand for sure.
> >>
> >>Anyway, why is it a problem if you have more memory? If I get more mone=
y
> >>for example, I would rather keep it, than complaining about it :)
> >>--
> >>Greetings,
> >>   Bal=E1zs
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This sf.net email is sponsored by:ThinkGeek
> >>Welcome to geek heaven.
> >>http://thinkgeek.com/sf
> >>_______________________________________________
> >>Dev-cpp-users mailing list
> >>Dev...@li...
> >>TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> >>https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> >>
> >>
> >>
> >
> >
> >
> >-------------------------------------------------------
> >This sf.net email is sponsored by:ThinkGeek
> >Welcome to geek heaven.
> >http://thinkgeek.com/sf
> >_______________________________________________
> >Dev-cpp-users mailing list
> >Dev...@li...
> >TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> >https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> >
> >
> >
>
>

Re: [Dev-C++] Re: malloc , extra bytes ! Not so urgent now .

[veenurs <ve...@ma...>]

Enlightening , man !

I don't know much abt . compilers , so tell me -
When is the decision to allocate ( how much of ) the memory made - at 
compilation or runtime .  If  at runtime , then why did I always got 
 "snug fit" with other compilers ?
The windows API tutorials are replete  with things like dwFileSize etc, 
which do give you sizes without much fuss ( That data comes from some 
behind the scene  struct members, I guess ) .That's how I was fooled 
into relying on such  tactics with  my own pointers :-0 .Nice timely  
jolt , though  .
-Rahul .

Per Westermark wrote:

>The main reasons for allicating larger memory blocks than requested are:
>- Make sure the hidden header before any allocated data are always
>aligned. Aligned data is faster to access. Also, most processors
>doesn't support unaligned memory. The x86 series processors are just
>very-very nice.
>- Make sure that the returned pointer get a very high alignment -
>normally at least align 8, to allow perfectly aligned 64-bit integers
>and doubles. Remember that the runtime library doesn't know if you expect
>to store 1024 single bytes or 128 doubles in a 1kB request.
>- Reduce memory fragmentation. By limiting number of allowed block sizes,
>new requests have a higher probability of being able to reuse a previously
>released memory block.
>
>The buddy system or a binary subdivision are the extremes, where you might
>get +50 - 100% extra memory even for large allocations. The advantages are
>that they are lightning-fast at locating available blocks or subdividing a
>too large block into a returnable chunk. When you return a block of
>memory, they know exactly where the neighbours are, and can check if the
>neighbour has also been released thereby directly combining multiple
>released blocks into the next larger block size.
>
>/Per W
>
>On Mon, 24 Feb 2003, OROSZI Balázs wrote:
>
>  
>
>>Hello!
>>
>>veenurs wrote:
>>    
>>
>>>if( (buffer = ( PBYTE )calloc( 1000 ,sizeof(BYTE) )) == NULL ){
>>>}
>>>size = _msize( buffer );
>>>The size I get it is not 1000 , but 1008  !Same for malloc.
>>>      
>>>
>> From the C Runtime Library Reference:
>>
>>----
>>Syntax
>>
>>#include <malloc.h>
>>size_t _msize(void *block);
>>
>>Description
>>
>>Returns the size of a heap block.
>>
>>_msize returns the size of the allocated heap block whose address is
>>block. The block must have been allocated with malloc, calloc, or
>>realloc. The returned size can be larger than the number of bytes
>>originally requested when the block was allocated.
>>
>>Return Value
>>
>>_msize returns the size of the block in bytes.
>>----
>>
>>Especially take care of this sentence:
>>The returned size can be larger than the number of bytes originally
>>requested when the block was allocated.
>>
>>I suppose the reason for this is because it would take longer to give
>>you the EXACT amount of memory, so it gives the amount that is nearly
>>(and at least) what you need, but what can be given the fastest - only
>>what I think.
>>
>>But you should always use the REQUESTED amount, not the actually
>>RECIEVED amount. If calloc doesn't return NULL, then the requested
>>amount is at your hand for sure.
>>
>>Anyway, why is it a problem if you have more memory? If I get more money
>>for example, I would rather keep it, than complaining about it :)
>>--
>>Greetings,
>>   Balázs
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by:ThinkGeek
>>Welcome to geek heaven.
>>http://thinkgeek.com/sf
>>_______________________________________________
>>Dev-cpp-users mailing list
>>Dev...@li...
>>TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
>>https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>>
>>    
>>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Dev-cpp-users mailing list
>Dev...@li...
>TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
>https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>
>  
>

Re: [Dev-C++] Re: malloc , extra bytes ! Got even more urgent !

[veenurs <ve...@ma...>]

Hi !
Yeah Per , to quote you :

> If these limitations are bothersome, they still represents the hard
> reality.


True, I am waking up to the hard reality .Guess it's the fact that the 
first language I learnt was java .Niggles me to look for more 
One-Line-Solutions .

> YOU have to assign the size to a
> separate variable, in case you want to support dynamic resizing


Yup ! That's how it used to be at the institute .Pointers are  how I 
circumvented the problem.
It was valuable help ,all the same .Thanks !

Hi J.O. : > " Never use a strange thing (and nonportable) such _msize."
Really ? are you sure ?That's how I knew what was amiss :-).Thanks .

Hi Danny , thanks to you too . sizeof(BYTE) , or even 1 was fine there , 
I guess .

Hi Ioannis, Nice to have you coming to rescue again .Talknnig about K&R 
, can  you point
     me to a good link on Windows directory listing ( Apart from page 
2^^n on goole search, of      course - I'm already hitting the NEXT link 
furiously in the other window .)

BTW , Dev-CPP did give similar result with GlobalAlloc family of 
function too .

Thanks again .

-Rahul



Josu Onandia wrote:

> Per is absolutely right. If you need to know the number of actual data 
> bytes
> inside a buffer, you have to track it on a variable. Never use a strange
> thing (and nonportable) such _msize.
> Josu
>  
>

[Dev-C++] Re: won't compile

[Samuel K. <ib...@ly...>]

Something is wrong with your include settings because on my computer your code compiles fine. I would check what folders that dev looks in for includes and see if that folder exists and/or the correct files are in it.


_____________________________________________________________
Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year.
http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus

Re: [Dev-C++] Can Not Comple a Consile Applicaiton

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

First of all, you didn't give much information - a ton of include errors.

Second, I would assume that you haven't checked the last 2 or 3 days of
history for this list, since we get a couple of similar questions every
day.

Have you tried std::cout instead of just cout?

/Per W

On Mon, 24 Feb 2003, Mark Kashay wrote:

> I just began learning C++ so please excuse my ignorance in advance.
>
> I just installed 4.9.7.6 and can not compile a simple console
> application.  I am getting a ton of include errors.  I am using Win XP.
> The programs I am attempting to run worked perfectly on version 4.
>
> Program:
>
> #include <iostream>
> #include <stdlib.h>
>
> int main(int argc, char *argv[])
> {
>   cout << "Hello world";
>   system("PAUSE");
>   return 0;
> }
>
> Any ideas?
>

[Dev-C++] Can Not Comple a Consile Applicaiton

[Mark K. <mk...@so...>]

I just began learning C++ so please excuse my ignorance in advance.
 
I just installed 4.9.7.6 and can not compile a simple console
application.  I am getting a ton of include errors.  I am using Win XP.
The programs I am attempting to run worked perfectly on version 4.
 
Program:
 
#include <iostream>
#include <stdlib.h>
 
int main(int argc, char *argv[])
{
  cout << "Hello world";
  system("PAUSE"); 
  return 0;
}
 
Any ideas?

Re: [Dev-C++] How to find and kill child windows..

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

I haven't tried, so this might be an embarrasing suggestion but...

Can't you just call GetDesktopWindow() and then iterate through all it's
child windows. If you don't like a window, you might post a WM_QUIT or
WM_CLOSE to it.

You might call GetWindowText() - Normally, IE adds it's own text at the
end of the title.

You might also peek at the window class with GetClassName(), i.e. if the
window class name is 'IEFrame'.

/Per W

On Mon, 24 Feb 2003, Danny Roelofs wrote:

> Hi,
>
> I want to make a simple popup/down killer for the internet explorer, yes i know that there a lot of programs on this mather
> but i just want to write my own.. what do i have to know?
>
> I actualy need to know the function's.. do i have to find a process first and then dig into its structure to get a handle
> to the parant screen before i can kill the child screens?
>
>

Re: [Dev-C++] Re: malloc , extra bytes ! Somewhat urgent !

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

The main reasons for allicating larger memory blocks than requested are:
- Make sure the hidden header before any allocated data are always
aligned. Aligned data is faster to access. Also, most processors
doesn't support unaligned memory. The x86 series processors are just
very-very nice.
- Make sure that the returned pointer get a very high alignment -
normally at least align 8, to allow perfectly aligned 64-bit integers
and doubles. Remember that the runtime library doesn't know if you expect
to store 1024 single bytes or 128 doubles in a 1kB request.
- Reduce memory fragmentation. By limiting number of allowed block sizes,
new requests have a higher probability of being able to reuse a previously
released memory block.

The buddy system or a binary subdivision are the extremes, where you might
get +50 - 100% extra memory even for large allocations. The advantages are
that they are lightning-fast at locating available blocks or subdividing a
too large block into a returnable chunk. When you return a block of
memory, they know exactly where the neighbours are, and can check if the
neighbour has also been released thereby directly combining multiple
released blocks into the next larger block size.

/Per W

On Mon, 24 Feb 2003, OROSZI Bal=E1zs wrote:

> Hello!
>
> veenurs wrote:
> > if( (buffer =3D ( PBYTE )calloc( 1000 ,sizeof(BYTE) )) =3D=3D NULL ){
> > }
> > size =3D _msize( buffer );
> > The size I get it is not 1000 , but 1008  !Same for malloc.
>
>  From the C Runtime Library Reference:
>
> ----
> Syntax
>
> #include <malloc.h>
> size_t _msize(void *block);
>
> Description
>
> Returns the size of a heap block.
>
> _msize returns the size of the allocated heap block whose address is
> block. The block must have been allocated with malloc, calloc, or
> realloc. The returned size can be larger than the number of bytes
> originally requested when the block was allocated.
>
> Return Value
>
> _msize returns the size of the block in bytes.
> ----
>
> Especially take care of this sentence:
> The returned size can be larger than the number of bytes originally
> requested when the block was allocated.
>
> I suppose the reason for this is because it would take longer to give
> you the EXACT amount of memory, so it gives the amount that is nearly
> (and at least) what you need, but what can be given the fastest - only
> what I think.
>
> But you should always use the REQUESTED amount, not the actually
> RECIEVED amount. If calloc doesn't return NULL, then the requested
> amount is at your hand for sure.
>
> Anyway, why is it a problem if you have more memory? If I get more money
> for example, I would rather keep it, than complaining about it :)
> --
> Greetings,
>    Bal=E1zs
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

[Dev-C++] How to find and kill child windows..

[Danny R. <dro...@ho...>]

Hi,

I want to make a simple popup/down killer for the internet explorer, yes =
i know that there a lot of programs on this mather
but i just want to write my own.. what do i have to know?

I actualy need to know the function's.. do i have to find a process =
first and then dig into its structure to get a handle
to the parant screen before i can kill the child screens?

Re: [Dev-C++] Re: malloc , extra bytes ! Somewhat urgent !

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

Hello!

veenurs wrote:
> if( (buffer = ( PBYTE )calloc( 1000 ,sizeof(BYTE) )) == NULL ){
> }
> size = _msize( buffer );
> The size I get it is not 1000 , but 1008  !Same for malloc.

 From the C Runtime Library Reference:

----
Syntax

#include <malloc.h>
size_t _msize(void *block);

Description

Returns the size of a heap block.

_msize returns the size of the allocated heap block whose address is 
block. The block must have been allocated with malloc, calloc, or 
realloc. The returned size can be larger than the number of bytes 
originally requested when the block was allocated.

Return Value

_msize returns the size of the block in bytes.
----

Especially take care of this sentence:
The returned size can be larger than the number of bytes originally 
requested when the block was allocated.

I suppose the reason for this is because it would take longer to give 
you the EXACT amount of memory, so it gives the amount that is nearly 
(and at least) what you need, but what can be given the fastest - only 
what I think.

But you should always use the REQUESTED amount, not the actually 
RECIEVED amount. If calloc doesn't return NULL, then the requested 
amount is at your hand for sure.

Anyway, why is it a problem if you have more memory? If I get more money 
for example, I would rather keep it, than complaining about it :)
--
Greetings,
   Balázs

RE: [Dev-C++] string.h

[Ken B. <ke...@al...>]

I believe c_str() is what your looking for:

#include <iostream>
#include <string>
using namespace std;

void main()
#include <iostream>
#include <string>
using namespace std;

void main()
{
        string b = "String";
        const char* c;
        c= b.c_str();
        cout << c << endl;
}

btw, don't forget www.google.com, a simple search on:

C++ "string class" char

Ken Bradford
Alpha II Service, Inc.
(614)868-5033 

> -----Original Message-----
> From: dev...@li...
> [mailto:dev...@li...]On Behalf Of Jeeun Cho
> Sent: Friday, February 21, 2003 11:13 PM
> To: dev...@li...
> Subject: [Dev-C++] string.h
> 
> 
> hello...
> actually i jst got dev c++ and..made a simple string
> program to test..
> in the program, i used apstring.h, but it didnt work..
> and after that, i used string.h, but that didnt work
> either. 
> How can i make string work?
> 
> thanks
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> 

Re: [Dev-C++] wxWindows

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

If that does not work look for setup.h in your wx incude
directory. I am guessing that you need to set a flag there.

--- OROSZI_Balázs <or...@vp...> wrote:
> Josh Sharp wrote:
> > I am trying to compile a test wxWinodws app and keep
> getting:
> > 
> > c:\Dev-Cpp\include\wx\string.h:164    #error:  "Please
> define string
> > case-insensitive compare for your OS/compiler"
> > 
> > What does this mean and how can I fix it?
> First of all, it is always advisable to send the compiler
> command line, 
> what flags was the compiler called with, other error
> messages, etc., so 
> others can help you efficiently and quickly, without the
> need to ask for 
> this extra info.
> 
> I can only guess you didn't specify a few flags on the
> command line, 
> like -DWIN32 -D_WIN32 -D__WIN95__ -D__GNUWIN32 or others.
> 
> --
> Greetings,
>    Balázs
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop
> an edge.
> The most comprehensive and flexible code editor you can
> use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE
> 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
>
https://lists.sourceforge.net/lists/listinfo/dev-cpp-users


=====
Signed 
David Mcken

Life Sucks
Live with it

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Re: [Dev-C++] Return values from static LPVOID functions

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

LPVOID will normally just expand to void*, and any other pointer type will
be assignable to a void* pointer.

The LP is originally an inherritance from the 16-bit API of Windows 3.11
and below, where you had to differentiate between 16-bit and 32-bit
pointers. We MIGHT see that again in application programs, if someone
takes up the 48-bit far pointers supported by the 386 and higher
processors, but most probably the decision will be to only support > 4GB
for a single process on 64-bit processors. Most existing 32-bit solutions
for more than 4GB memory only lets the OS see all the memory, and limits
each process to less than 4GB.

/Per W


On Mon, 24 Feb 2003, Daniel Glenfield wrote:

>
> I'm looking through some code and I've found a function with the return type
> static LPVOID
>
> static LPVOID SomeFunction()
>
>
> and it has a return value that is an unsigned char*
>
> return MyVal;  // An unsigned char*
>
> How does this tally with LPVOID ? Can the return value by a pointer to
> anything if the return type is specified as LPVOID ?
>
>
>
>
> _________________________________________________________________
> Chat online in real time with MSN Messenger http://messenger.msn.co.uk
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

[Dev-C++] Return values from static LPVOID functions

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

I'm looking through some code and I've found a function with the return type 
static LPVOID

static LPVOID SomeFunction()


and it has a return value that is an unsigned char*

return MyVal;  // An unsigned char*

How does this tally with LPVOID ? Can the return value by a pointer to 
anything if the return type is specified as LPVOID ?




_________________________________________________________________
Chat online in real time with MSN Messenger http://messenger.msn.co.uk

Re: [Dev-C++] Question about function parameters

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

Thanks Per!



>From: Per Westermark <pw...@ia...>
>To: Daniel Glenfield <sp...@ho...>
>CC: dev...@li...
>Subject: Re: [Dev-C++] Question about function parameters
>Date: Mon, 24 Feb 2003 10:08:45 +0100 (CET)
>
>Commenting away unused parameters, is just a way of informing the compiler
>that you don't want any warnings about unused parameters.
>
>Some parameter types might be specific enough that you may always
>guess what they mean (such as a single HWND parameter), but say that
>the function takes four int as parameters. How would you then quess
>the meaning of (int,int,int,int)?.'
>
>In the end, you don't need them, but they might be seen as good
>craftmanship.
>
>/Per W
>
>On Mon, 24 Feb 2003, Daniel Glenfield wrote:
>
> >
> >
> > int MyFunction(int /* MyInt */, HWND /* Hwnd */ )
> > {
> > //... some code
> > }
> >
> > what is the significance of /* MyInt */ etc. ? Is it something to do 
>with
> > default values?
> >
> >
> >
> > _________________________________________________________________
> > Chat online in real time with MSN Messenger http://messenger.msn.co.uk
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Dev-cpp-users mailing list
> > Dev...@li...
> > TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> > https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> >
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Dev-cpp-users mailing list
>Dev...@li...
>TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
>https://lists.sourceforge.net/lists/listinfo/dev-cpp-users


_________________________________________________________________
MSN Messenger - fast, easy and FREE! http://messenger.msn.co.uk

RE: [Dev-C++] Re: malloc , extra bytes ! Got even more urgent !

[Josu O. <jon...@ao...>]

Per is absolutely right. If you need to know the number of actual data bytes
inside a buffer, you have to track it on a variable. Never use a strange
thing (and nonportable) such _msize.
Josu

> -----Mensaje original-----
> De:	Per Westermark [SMTP:pw...@ia...]
> Enviado el:	lunes 24 de febrero de 2003 10:04
> Para:	veenurs
> CC:	Danny Roelofs; dev...@li...; ra...@ww...
> Asunto:	Re: [Dev-C++] Re: malloc , extra bytes ! Got even more
> urgent !
> 
> The _msize() you are referring to is part of heap-walk code. They are not
> expected to be used for a normal application, but for debug code to verify
> memory leaks etc.
> 
> There are NO standard method of keeping track of the size of a block of
> memory. When you allocate the block, YOU have to assign the size to a
> separate variable, in case you want to support dynamic resizing.
> 
> However, your malloc() or calloc() call will return your 1000 bytes of
> available buffer space, to be used for whatever you want.
> 
> You may not assume anything about any extra bytes before the returned
> pointer, or after your 1000 bytes of requested data. You may also assume
> that - unless you have buffer overflow problems in the code - that you are
> the sole owner of these 1000 byte of data, i.e. what you put there will
> stay there until your RAM memory fails, or until you put something else
> there.
> 
> The only thing you might assume, is that p+1000 is a valid pointer value,
> even if you may not read/write at that location.
> 
> If these limitations are bothersome, they still represents the hard
> reality.
> 
> /Per W
> 
> 
> On Mon, 24 Feb 2003, veenurs wrote:
> 
> > Hi PW ,
> >  Well , I guessed  it had something to do with the AT Least qualifier
> > .But , I just can't help bothoring abt . the extra bytes !
> >  It's lioke this- the memory created is used to store bytes of formatted
> > data , which are then to be used by another part of application . So ,
> > the extra bytes are screwing up the formatting and making 6the data
> > useless !!
> > The data itself is comming from   decryption  routines , so I cannot be
> > sure of the exact size before decryption ( therefore , I NEED the
> > malloc- realloc thing , would hate to use arrays .)
> >
> > MoreOvere , There is no such problem In VC++ ( I have a learner ed.), or
> > LCC .
> >
> > Thanks , any other solution ?
> >
> > -Rahul.
> >
> > Per Westermark wrote:
> >
> > >Stop bothering about the size of the returned memory block.
> > >
> > >The allocation functions are only required to return AT LEAST the
> required
> > >amount of memory, or a NULL pointer.
> > >
> > >Internally, they normally add 8-16 byte of internal header for
> > >book-keeping on the heap, i.e. to allow the heap manager to walk free
> and
> > >used memory block.
> > >
> > >Besides, most heap managers performs one of the following:
> > >- rounds each block up to the nearest 8 or 16 byte increment.
> > >- allocates the nearest larger 2^n size.
> > >- uses the buddy system and allocates the nearest larger block size.
> > >
> > >As a result - for allocation of very small objects, it might often
> > >be better to allocate a bunch of objects at a time, and keep pool of
> > >evailable objects in a list.
> > >
> > >In the example below, the calloc call MUST use sizeof(BYTE). The
> > >statement calloc(1000,BYTE) doesn't make sense.
> > >
> > >/Per W
> > >
> > >On Mon, 24 Feb 2003, Danny Roelofs wrote:
> > >
> > >
> > >
> > >>Hi,
> > >>
> > >>Well i dont realy know what youre doing with it.. and i never used
> calloc but it seems your allocating memory for 1000 bytes
> > >>and a additional 8 bytes..  sizeof(byte) reserves 8 bytes in my
> opinion. is it perhaps that you have to do this:
> > >>
> > >>calloc(1000,BYTE) instead of calloc(1000,sizeof(BYTE))
> > >>
> > >>Well i actualy dont know.. i am just programming in C for just a month
> or so..
> > >>
> > >>
> > >>  ----- Original Message -----
> > >>  From: veenurs
> > >>  To: dev...@li... ; ra...@ww...
> > >>  Sent: Monday, February 24, 2003 1:16 AM
> > >>  Subject: [Dev-C++] Re: malloc , extra bytes ! Somewhat urgent !
> > >>
> > >>
> > >>
> > >>
> > >>  Hi !
> > >>  It seems too simple .But what is it !?
> > >>  if( (buffer = ( PBYTE )calloc( 1000 ,sizeof(BYTE) )) == NULL ){
> > >>         ------
> > >>        -------
> > >>  }
> > >>    size = _msize( buffer );
> > >>
> > >>  The size I get it is not 1000 , but 1008  !Same for malloc. Any
> subsequent call to realloc  does not add  the 8 bytes,though  .
> > >>
> > >>  [ Dev Cpp Version 4.9.7.0 ]
> > >>  What's happening ?
> > >>  BTW - "Generate debugging info" is OFF .
> > >>  Thanks in advance .
> > >>
> > >>  -Rahul.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> >
> >
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users

Re: [Dev-C++] Question about function parameters

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

Commenting away unused parameters, is just a way of informing the compiler
that you don't want any warnings about unused parameters.

Some parameter types might be specific enough that you may always
guess what they mean (such as a single HWND parameter), but say that
the function takes four int as parameters. How would you then quess
the meaning of (int,int,int,int)?.'

In the end, you don't need them, but they might be seen as good
craftmanship.

/Per W

On Mon, 24 Feb 2003, Daniel Glenfield wrote:

>
>
> int MyFunction(int /* MyInt */, HWND /* Hwnd */ )
> {
> //... some code
> }
>
> what is the significance of /* MyInt */ etc. ? Is it something to do with
> default values?
>
>
>
> _________________________________________________________________
> Chat online in real time with MSN Messenger http://messenger.msn.co.uk
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>