dev-cpp-users

[Dev-C++] wxWindows

[Jared E. <ja...@vo...>]

Hello,
  I am trying to compile minimal.cpp that comes with the wxWindows
  package --- C:\Program Files\wx2\samples\minimal

  I keep getting these errors:
  wx\wxprec.h No such file or directory
  wx\wx.h No such file or directory

  Can you please tell me how to fix this

  - Jared

[Dev-C++] wxWindows

[Bob W. <bo...@ph...>]

I am not sure this is the place to seek this information, but I can not =
find a specific site for Bloodshed.=20

I have down loaded the wxWindows programs and source files, but I am =
getting an consistant error in compilation which I assume is either =
related to the Bloodsheed compiler which is:
  Bloodsheed Deve=3DC++ Ver 4.01

  mingw complier 2.95-1 MSVCRT + updated headers & libraries
The compiler finds all of the various include files that are either =
source or library, but during the preprocessor or precompile phase it =
produces three fatal errors. They are:
  In file included from =
F:\DEV-C++\Downloads\wxWindows\wx2\include\wx\debug.h:17,
                   from =
F:\DEV-C++\Downloads\wxWindows\wx2\include\wx\defs.h:468,
                   from =
F:\DEV-C++\Downloads\wxWindows\wx2\include\wx\wxprec.h:13,
                   from =
f:\dev-c_~1\downlo~1\wxwind~1\wx2\demos\life\life.cpp:21:
  F:\DEV-C++\Downloads\wxWindows\wx2\include\wx\wxchar.h:429: #error =
"Please define string case-insensitive compare for your OS/compiler"

  In file included from =
F:\DEV-C++\Downloads\wxWindows\wx2\include\wx\memory.h:20,
                   from =
F:\DEV-C++\Downloads\wxWindows\wx2\include\wx\object.h:20,
                   from =
F:\DEV-C++\Downloads\wxWindows\wx2\include\wx\wx.h:16,
                   from =
f:\dev-c_~1\downlo~1\wxwind~1\wx2\demos\life\life.cpp:28:
  F:\DEV-C++\Downloads\wxWindows\wx2\include\wx\string.h:170: #error =
"Please define string case-insensitive compare for your OS/compiler"

  In file included from =
F:\DEV-C++\Downloads\wxWindows\wx2\include\wx\cmndata.h:21,
                   from =
F:\DEV-C++\Downloads\wxWindows\wx2\include\wx\wx.h:48,
                   from =
f:\dev-c_~1\downlo~1\wxwind~1\wx2\demos\life\life.cpp:28:
  F:\DEV-C++\Downloads\wxWindows\wx2\include\wx\fontutil.h:65: #error =
"Unsupported toolkit"
It appears that either the compiler is not providing the proper =
identification, is a mismatch despite of its mingw roots, or that I need =
to modify the source code to specify the proper option for each of the =
three unidentified definitions during the
  #if ( . . . )
  #endif

  #ifdef . . .=20
  #endif
option identification phases. I could flail around and eventually either =
figures it out or arrive at a serendipitous solution (more likely), but =
I am sure I am not the first to run into this problem. FYI operating =
system is stock Windows98.=20

I love learning and becoming proficient in a new language. It always =
makes you feel like a real mental midget.=20

Regards,

Bob

Re: [Dev-C++] wxWindows

[Laurence <lau...@ip...>]

Hi Bob.
You sound like someone who knows more about compilers & building =
libraries than me, so I hope I can be of assistance to you.=20

I downloaded the full wxWindows distribution from  www.wxWindows.org, =
and found I could not build the libraries with Dev-C++ - many errors, =
mainly of the kind that appear to me to result from headers not being =
included, macros not being defined. I didn't know really what to do with =
them all.

So, I downloaded (again) the full Mingw compiler suite from =
www.mingw.org , and used the relevant wxWindows makefiles, following all =
the wxWindows build instructions. It worked perfectly.
=20
Still, I could not use it with Dev-C++. This may well have been because =
I did not properly understand the required library and include paths to =
add to the Dev-C++ environment/project options. I don't know - maybe =
you've got to build it all a certain kind of way. I don't know enough =
about it, and I was in a hurry.

Finally, I found this page:
    http://steveperkins.net/development/platforms/cpp.php

where you will find a Dev-C++ package for wxWindows (just 2.64MB, as =
against 8+MB unbuilt)  (wxWindows samples not included). Just install =
into your Dev-C++ directory. It includes a template for GUI =
applications, available from Dev's New Project menu, which has project =
options preset with correct paths for wx2 includes and libraries, and =
correct compiler command options.

An official Dev-C++ packages page has a link for a wxWindows package, =
but, as explained on that page, some problem caused it to be =
unavailable. However, the wxWindows samples (without the rest of =
wxWindows) are available from this page:
    http://devcpp.everfloyd.com/old/wxwindows.html

The samples are useful for quick entry into the wxwindows world.

In addition, I have got the wxWindows WinHelp, from www.wxwindows.org, =
which I have added to the Dev-C++ tools menu with the tools =
configuration option. I find this indispensibly useful.

Cheers,
Laurence.=20
  ----- Original Message -----=20
  From: Bob Wilson=20
  To: dev...@li...=20
  Sent: Tuesday, April 02, 2002 5:48 AM
  Subject: [Dev-C++] wxWindows


  I am not sure this is the place to seek this information, but I can =
not find a specific site for Bloodshed.=20
  =20
  I have down loaded the wxWindows programs and source files, but I am =
getting an consistant error in compilation which I assume is either =
related to the Bloodsheed compiler which is:
    Bloodsheed Deve=3DC++ Ver 4.01
    =20
    mingw complier 2.95-1 MSVCRT + updated headers & libraries
  The compiler finds all of the various include files that are either =
source or library, but during the preprocessor or precompile phase it =
produces three fatal errors. They are:
    In file included from =
F:\DEV-C++\Downloads\wxWindows\wx2\include\wx\debug.h:17,
                     from =
F:\DEV-C++\Downloads\wxWindows\wx2\include\wx\defs.h:468,
                     from =
F:\DEV-C++\Downloads\wxWindows\wx2\include\wx\wxprec.h:13,
                     from =
f:\dev-c_~1\downlo~1\wxwind~1\wx2\demos\life\life.cpp:21:
    F:\DEV-C++\Downloads\wxWindows\wx2\include\wx\wxchar.h:429: #error =
"Please define string case-insensitive compare for your OS/compiler"

    In file included from =
F:\DEV-C++\Downloads\wxWindows\wx2\include\wx\memory.h:20,
                     from =
F:\DEV-C++\Downloads\wxWindows\wx2\include\wx\object.h:20,
                     from =
F:\DEV-C++\Downloads\wxWindows\wx2\include\wx\wx.h:16,
                     from =
f:\dev-c_~1\downlo~1\wxwind~1\wx2\demos\life\life.cpp:28:
    F:\DEV-C++\Downloads\wxWindows\wx2\include\wx\string.h:170: #error =
"Please define string case-insensitive compare for your OS/compiler"

    In file included from =
F:\DEV-C++\Downloads\wxWindows\wx2\include\wx\cmndata.h:21,
                     from =
F:\DEV-C++\Downloads\wxWindows\wx2\include\wx\wx.h:48,
                     from =
f:\dev-c_~1\downlo~1\wxwind~1\wx2\demos\life\life.cpp:28:
    F:\DEV-C++\Downloads\wxWindows\wx2\include\wx\fontutil.h:65: #error =
"Unsupported toolkit"
  It appears that either the compiler is not providing the proper =
identification, is a mismatch despite of its mingw roots, or that I need =
to modify the source code to specify the proper option for each of the =
three unidentified definitions during the
    #if ( . . . )
    #endif
    =20
    #ifdef . . .=20
    #endif
  option identification phases. I could flail around and eventually =
either figures it out or arrive at a serendipitous solution (more =
likely), but I am sure I am not the first to run into this problem. FYI =
operating system is stock Windows98.=20

  I love learning and becoming proficient in a new language. It always =
makes you feel like a real mental midget.=20

  Regards,

  Bob

[Dev-C++] wxWindows

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

Hello!

I am using my externally self compiled wxWindows. How do I know, which 
include dirs, library dirs, and libraries do I need to add to the 
project, when I write a program which uses wxWindows, from Dev-C++?
I looked at the makefile, which comes with wxWindows and I digged and 
copy-pasted the dirs and libs from it.

Is this the normal way, or is there a more general one?

I am using Dev-C++ 4.9.7.6 (the latest).
--
Regards,
   Balázs

P.S.: Please don't forget my previous question.

Re: [Dev-C++] wxWindows

[Michel W. <mic...@fr...>]

OROSZI Balázs a écrit:

> Hello!
>
> I am using my externally self compiled wxWindows. How do I know, which 
> include dirs, library dirs, and libraries do I need to add to the 
> project, when I write a program which uses wxWindows, from Dev-C++? 

you should add the wxwindows library (.a) and use the right compilation 
options. You could also add <dev-cpp>/include in resource directory (if 
you have hand.cur file not find)

>
> I looked at the makefile, which comes with wxWindows and I digged and 
> copy-pasted the dirs and libs from it.
>
> Is this the normal way, or is there a more general one?

you could try my dev-packs at <<http://michel.weinachter.free.fr>> I 
need more tests.

>
> I am using Dev-C++ 4.9.7.6 (the latest).
> -- 
> Regards,
>   Balázs
>
> P.S.: Please don't forget my previous question.
>
>
>
> -------------------------------------------------------
> 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
>

[Dev-C++] wxWindows

[Josh S. <jd...@ya...>]

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?

Re: [Dev-C++] wxWindows

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

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

Re: [Dev-C++] wxWindows

[Josh S. <jd...@ya...>]

Thanks,

That led me to the right place, I just looked at the flags used to 
compile wxWindows.  I'm a newby at this and am clinbing the learning 
curve.  I got it compiled but now it has a fatal error that I compiled 
wxWindows with debug and my program with no debug...<SIGH>.  I get there 
one of these days.

Thanks again.
Josh.



OROSZI Balázs 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-use

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

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

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.

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

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

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=20
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 -----=20
  From: veenurs=20
  To: dev...@li... ; ra...@ww...=20
  Sent: Monday, February 24, 2003 1:16 AM
  Subject: [Dev-C++] Re: malloc , extra bytes ! Somewhat urgent !




  Hi !=20
  It seems too simple .But what is it !?=20
  if( (buffer =3D ( PBYTE )calloc( 1000 ,sizeof(BYTE) )) =3D=3D NULL ){=20
         ------=20
        -------=20
  }=20
    size =3D _msize( buffer );=20

  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  .=20

  [ Dev Cpp Version 4.9.7.0 ]=20
  What's happening ?=20
  BTW - "Generate debugging info" is OFF .=20
  Thanks in advance .=20

  -Rahul.=20

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

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

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.
>
>
>

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

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

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.
>>
>>
>>
>>    
>>
>
>
>  
>

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

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

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.
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
>

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++] 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
>

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 ! 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++] 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/

[Dev-C++] wxWindows

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

Hello!
Yesterday I had a greate idea on a new application.
But I thought the interface should be quite hard to make using just =
Win32 API, so I decided to use wxWindows.
I have no experiance using wxWindows and my try ended up the way it =
started, with nothing done.
I'm getting about 400 of liker errors and I just can't solve the =
problem.
You see, I'm quite used to those liker errors, Before i've just found =
the right library and cliked add... and boom everything have worked.
This time I can't find the right library, so maybe, that's not the =
fault.
However I need your help!
Can anybody out there help me solve this problem?
Thanks in advance!
//Johan H=F6rnell

Re: [Dev-C++] wxWindows

[Mark L. <mli...@ip...>]

T24gRnJpLCAxNiBNYXkgMjAwMyAxODowNToyOCArMDIwMA0KSm9oYW4gSPZybmVsbCA8aG9ybmVs
bC5qb2hhbkB0ZWxpYS5jb20+IHdyb3RlOg0KDQo+IFllc3RlcmRheSBJIGhhZCBhIGdyZWF0ZSBp
ZGVhIG9uIGEgbmV3IGFwcGxpY2F0aW9uLg0KPiBCdXQgSSB0aG91Z2h0IHRoZSBpbnRlcmZhY2Ug
c2hvdWxkIGJlIHF1aXRlIGhhcmQgdG8gbWFrZSB1c2luZyBqdXN0DQo+IFdpbjMyIEFQSSwgc28g
SSBkZWNpZGVkIHRvIHVzZSB3eFdpbmRvd3MuIEkgaGF2ZSBubyBleHBlcmlhbmNlIHVzaW5nDQo+
IHd4V2luZG93cyBhbmQgbXkgdHJ5IGVuZGVkIHVwIHRoZSB3YXkgaXQgc3RhcnRlZCwgd2l0aCBu
b3RoaW5nIGRvbmUuDQo+IEknbSBnZXR0aW5nIGFib3V0IDQwMCBvZiBsaWtlciBlcnJvcnMgYW5k
IEkganVzdCBjYW4ndCBzb2x2ZSB0aGUNCg0KSSBhbSBhIHJhbmsgYW1hdGV1ciBhdCBDL0MrKyBz
byBmYXIgYXQgdGhpcyBidXQgSSBoYXZlIHNlZW4gYW5kDQpjb25xdWVyZWQgdGhpcyBpbiBib3Ro
IERldi1DKysgYW5kIFZDNisrIHJlY2VudGx5LiANCg0KVGhlIHd4d2luZG93cyBoZWFkZXJzIHVz
ZSByZWxhdGl2ZSBwYXRocyB0byBmaW5kIHdoYXQgdGhleSBuZWVkLiBJZiB5b3UNCmxvayBhdCB0
aGUgY29kZSwgdGhlcmUgYXJlIGxvdHMgb2YgI2luY2x1ZGVzIHRvICJ3eC8od2hhdGV2ZXIpIi4g
SWYgeW91DQpkbyBpbnN0YWxsIHRoaW5ncyBleGFjdGx5IHdoZXJlIHRoZXkgYXJlIGV4cGVjdGVk
LCB0aGUgbGlua2luZyB1cCBkb2VzbnQNCndvcmsuDQoNClRvIHByb3ZlIGlmIHRoaXMgaXMgdGhl
IHByb2JsZW0sIGRvdWJsZSBjbGljayBvbmUgb2YgdGhlIGxpbmtlciBlcnJvcg0KbGluZXMgYW5k
IGl0IHNob3VsZCB0YWtlIHlvdSB0byB0aGUgbGluZSBvZiBjb2RlIHdpdGggYSAjaW5jbHVkZS4g
Q2hhbmdlDQppdCB0byBhbiBhYnNvbHV0ZSBwYXRoIHJlZmVyZW5jZSBlLmcuICJEOlxEZXYtQ3Bw
XGluY2x1ZGVcd3gvc2l6ZXIuaCINCmFuZCByZWJ1aWxkLiBJZiB0aGlzIGlzIHRoZSBjYXNlLCB0
aGVyZSB3aWxsIGJlIG5vIG1vcmUgbGluayBlcnJvcnMgZm9yDQp0aGF0IGxpbmUgb2YgY29kZSB5
b3UganVzdCBmaXhlZC4gSWYgaXQgaXMsIHlvdSBjYW4gZ28gaW50byB0aGUgY29tcGlsZXINCm9w
dGlvbnMgYW5kIGluIHRoZSBDKysgaW5jbHVkZSBkaXJlY3RvcmllcywgcHV0IHRoZSByZXN0IG9m
IHRoZSByZWxhdGl2ZQ0KZGlyZWN0b3J5IHJlZmVyZW5jZSBzbyB0aGF0IGFsbCBvZiB0aGUgcmVz
dCBvZiB0aGUgd3gvIGxpbmVzIHdvcmsuDQoNCld4d2luZG93cyBqdXN0IHdvcmtzIHdpdGggc28g
bWFueSBjb21waWxlcnMgdGhhdCBKdWxpYW4gY2FuJ3QgcmVhbGx5DQp0ZWxsIHlvdSBpbiB0aGUg
ZG9jcyBob3cgdG8gc2V0dXAgeW91ciBwcm9ncmFtbWluZyBlbnZpcm9ubWVudC4gSGUgaGFzDQp0
byBhc3N1bWUgcHJvZ3JhbW1lcnMgaGF2ZSBzb21lIGZpbGUgc3lzdGVtIHNraWxscyB0aGF0IG9s
ZCBET1MNCnByb2dyYW1tZXJzIHdvdWxkIGhhdmUgYnV0IHRoYXQgbmV3Y29tZXJzIHRoYXQgaGF2
ZSBuZXZlciBiYXR0bGVkIGENCmNvbW1hbmQgbGluZSBPL1MgbWlnaHQgbm90LiBUaGVyZSdzIG9u
bHkgc28gbXVjaCBwb2ludCBhbmQgY2xpY2sgY2FuDQphY2hpZXZlIDxzbWlsZT4gSSBjdXQgbXkg
dGVldGggcHJvZ3JhbW1pbmcgb24gTVMgQmFzaWMgYmFjayB3aGVuIHlvdQ0KbGVhcm5lZCBjb21t
YW5kIGxpbmUgb3BlcmF0aW9uIG9yIHlvdSBmb3VuZCBhbm90aGVyIGpvYiA7LSkNCg0KSFRIDQo=

[Dev-C++] wxWindows

[michel.weinachter <mic...@fr...>]

>
> Subject:
> [Dev-C++] wxWindows
> From:
> Johan Hörnell <hor...@te...>
> Date:
> Fri, 16 May 2003 18:05:28 +0200
> To:
> <Dev...@li...>
>
>
> Hello!
> Yesterday I had a greate idea on a new application.
> But I thought the interface should be quite hard to make using just 
> Win32 API, so I decided to use wxWindows.
> I have no experiance using wxWindows and my try ended up the way it 
> started, with nothing done.
> I'm getting about 400 of liker errors and I just can't solve the problem.
> You see, I'm quite used to those liker errors, Before i've just found 
> the right library and cliked add... and boom everything have worked.
> This time I can't find the right library, so maybe, that's not the fault.
> However I need your help!
> Can anybody out there help me solve this problem?

just change compiler by cppCompiler in the wxwindows template in the 
templates directory.

> Thanks in advance!
> //Johan Hörnell
>
I have released a new version of the wxwindows.devpak

corrections :
    - Compiler change in CppCompiler
    - No more crashes with windows XP SP1 with the lastest patches (I 
hate M$ patches !)

good wxindows programimng

[Dev-C++] wxWindows

[Brian A. <bri...@gm...>]

I've just compiled the latest wxWindows CVS build.  What must I do to 
'plug it in' to Dev-C++?  I've tried copying the lib and include 
directories under Dev-Cpp, but I'm getting errors building the minimal 
sample.

Thanks!

Brian

Re: [Dev-C++] wxWindows

[Brian A. <bri...@gm...>]

Ok, now I've made an attempt to 'plug-in' my new build to my Dev-Cpp 
install...and I get this...
=========================================
Executing  make clean
rm -f minimal.o  minimal.exe

g++.exe -c minimal.cpp -o minimal.o -I"C:/Dev-Cpp/include/c++"  
-I"C:/Dev-Cpp/include/c++/mingw32"  -I"C:/Dev-Cpp/include/c++/backward"  
-I"C:/Dev-Cpp/include" -fno-rtti -fno-exceptions -fno-pcc-struct-return 
-fstrict-aliasing -Wall -fvtable-thunks -D__WXMSW__ -D__GNUWIN32__ 
-DWINVER=0x400 -D__WIN95__ -DSTRICT -D__WXDEBUG__   
-fexpensive-optimizations -O1

cc1plus.exe: warning: -fvtable-thunks is no longer supported

g++.exe minimal.o  -o "minimal.exe" -L"C:/Dev-Cpp/lib" -mwindows 
-lwxmsw250d -lcomdlg32 -luser32 -lgdi32 -lole32 -lwsock32 -lcomctl32 
-lctl3d32 -lgcc -lstdc++ -lshell32 -loleaut32 -ladvapi32 -luuid -Lc:/wx/lib

Execution terminated
Compilation successful

=============================

It does generate an .exe, but when it runs, it immediately generates an 
unknown software exception at location 0x0040cd6d.

Does anybody have any experience with what causes this error?  It MUST 
NOT BE the lib, because when I made the sample from the makefile, 
everything was swimmy.  Its a configuration in Dev-Cpp, I'm sure of 
it...I just don't have enough knowledge to track this down...

Brian

Brian Ackermann wrote:

> I've just compiled the latest wxWindows CVS build.  What must I do to 
> 'plug it in' to Dev-C++?  I've tried copying the lib and include 
> directories under Dev-Cpp, but I'm getting errors building the minimal 
> sample.
>
> Thanks!
>
> Brian
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: eBay
> Great deals on office technology -- on eBay now! Click here:
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> 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

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

Brian Ackermann wrote:
> Ok, now I've made an attempt to 'plug-in' my new build to my Dev-Cpp 
> install...and I get this...
> =========================================
> Executing  make clean
> rm -f minimal.o  minimal.exe
> 
> g++.exe -c minimal.cpp -o minimal.o -I"C:/Dev-Cpp/include/c++"  
> -I"C:/Dev-Cpp/include/c++/mingw32"  -I"C:/Dev-Cpp/include/c++/backward"  
> -I"C:/Dev-Cpp/include" -fno-rtti -fno-exceptions -fno-pcc-struct-return 
> -fstrict-aliasing -Wall -fvtable-thunks -D__WXMSW__ -D__GNUWIN32__ 
> -DWINVER=0x400 -D__WIN95__ -DSTRICT -D__WXDEBUG__   
> -fexpensive-optimizations -O1
> 
> cc1plus.exe: warning: -fvtable-thunks is no longer supported

Remove "-fvtable-thunks" from compiler options.
Also, where did you get the -D flags? Did you dig it out from the 
makefiles of wxWindows? I did it once, and these are the flags, that I 
could obtain. I use them and it works:
-D_X86_ -DWIN32 -D_WIN32 -DWINVER=0x0400 -D__WIN95__ -D__GNUWIN32__ 
-D__WIN32__ -DSTRICT -DHAVE_W32API_H -D__WXMSW__ -D__WINDOWS__

Of course, use -D__WXDEBUG__ in your case, as you use the debug build.
Note, that I also experimented with -D flags, to don't have too much of 
them, but still compile: my result was the same as yours, a crash (I 
thought: if it compiles, it works). So I suggest you to specify all the 
flags above.

> g++.exe minimal.o  -o "minimal.exe" -L"C:/Dev-Cpp/lib" -mwindows 
> -lwxmsw250d -lcomdlg32 -luser32 -lgdi32 -lole32 -lwsock32 -lcomctl32 
> -lctl3d32 -lgcc -lstdc++ -lshell32 -loleaut32 -ladvapi32 -luuid -Lc:/wx/lib

Hmmm... -lwxmsw250d
Is it a DLL build? Because in that case, you also need to add one more 
flag for the compiler:
-DWXUSINGDLL

Actually, try this first, and if the result is still a crash, then add 
all flags above.

I hope I could help. Tell me, if you succeed.
--
Greetings,
   Balázs

Re: [Dev-C++] wxWindows

[Brian A. <bri...@gm...>]

I don't think I have a dll build, I didn't want it, if I do, but, I 
tried it just in case...I got this ::
C:/Dev-Cpp/lib/libwxmsw250d.a(app.o)(.text+0x2874): In function `WinMain':
c:/wx/mswd/../src/msw/main.cpp:85: multiple definition of `WinMain@16'
main.o(.text+0xb4):main.cpp: first defined here
main.o(.text+0x24):main.cpp: undefined reference to 
`_imp___ZN9wxAppBase17CheckBuildOptionsERK14wxBuildOptions'
main.o(.text+0xac):main.cpp: undefined reference to `_imp__wxTheApp'

So I think that is not my problem...

I tried your other suggestions, and they yeilded the same results I was 
getting previously.  I'll keep playing with the compiler options and 
linker options, and see where I get.

Any other suggestions (and thank you very much, by the way...)

Brian

OROSZI Balázs wrote:

> Brian Ackermann wrote:
>
>> Ok, now I've made an attempt to 'plug-in' my new build to my Dev-Cpp 
>> install...and I get this...
>> =========================================
>> Executing  make clean
>> rm -f minimal.o  minimal.exe
>>
>> g++.exe -c minimal.cpp -o minimal.o -I"C:/Dev-Cpp/include/c++"  
>> -I"C:/Dev-Cpp/include/c++/mingw32"  
>> -I"C:/Dev-Cpp/include/c++/backward"  -I"C:/Dev-Cpp/include" -fno-rtti 
>> -fno-exceptions -fno-pcc-struct-return -fstrict-aliasing -Wall 
>> -fvtable-thunks -D__WXMSW__ -D__GNUWIN32__ -DWINVER=0x400 -D__WIN95__ 
>> -DSTRICT -D__WXDEBUG__   -fexpensive-optimizations -O1
>>
>> cc1plus.exe: warning: -fvtable-thunks is no longer supported
>
>
> Remove "-fvtable-thunks" from compiler options.
> Also, where did you get the -D flags? Did you dig it out from the 
> makefiles of wxWindows? I did it once, and these are the flags, that I 
> could obtain. I use them and it works:
> -D_X86_ -DWIN32 -D_WIN32 -DWINVER=0x0400 -D__WIN95__ -D__GNUWIN32__ 
> -D__WIN32__ -DSTRICT -DHAVE_W32API_H -D__WXMSW__ -D__WINDOWS__
>
> Of course, use -D__WXDEBUG__ in your case, as you use the debug build.
> Note, that I also experimented with -D flags, to don't have too much 
> of them, but still compile: my result was the same as yours, a crash 
> (I thought: if it compiles, it works). So I suggest you to specify all 
> the flags above.
>
>> g++.exe minimal.o  -o "minimal.exe" -L"C:/Dev-Cpp/lib" -mwindows 
>> -lwxmsw250d -lcomdlg32 -luser32 -lgdi32 -lole32 -lwsock32 -lcomctl32 
>> -lctl3d32 -lgcc -lstdc++ -lshell32 -loleaut32 -ladvapi32 -luuid 
>> -Lc:/wx/lib
>
>
> Hmmm... -lwxmsw250d
> Is it a DLL build? Because in that case, you also need to add one more 
> flag for the compiler:
> -DWXUSINGDLL
>
> Actually, try this first, and if the result is still a crash, then add 
> all flags above.
>
> I hope I could help. Tell me, if you succeed.
> -- 
> Greetings,
>   Balázs
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: eBay
> Great deals on office technology -- on eBay now! Click here:
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> 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
>
>