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

Re: [Dev-C++] Use of const qualifier

[Abhijit S. <mu...@gm...>]

> Yes. Also if you can make it easy to be inlined things will be more
> better.

Inlining a function is decided by the compiler. Functions with loops, etc.
are generally not inlined, so this won't be of much help. You can achieve
the same end by simply eliminating the function (moving all of the code into
the main routine). This will remove the overhead of function calls and
memory allocation (which should help a lot in this case). This should be a
case of code-elegance versus execution-speed. Also consider generating
look-up tables of sine and cos. There are a lot of articles on the web about
optimizing programs. I remember one that spoke in explicit detail about how
memory can be optimized... unfortunately, I don't remember saving it. Google
helps.

___________________________________________________________

Abhijit Shylanath

E-mail:   mu...@gm... || ibr...@bi...
Web-site: http://mudeth.tripod.com/

RE: [Dev-C++] Use of const qualifier

[Scott W. <se...@al...>]

Per,

Thanks for the reply and info--it's good to know.  I've learned a lot from
your responses .

Here are a couple more efficiency issues I'm curious about:

1) if(fabs(x) < num)  versus  if(x < num && x > -num)

2) sx = sin(x);
   cx = cos(x);
versus
   cx = cos(x);
   sx = (x<PI) ? sqrt(1.0 - cx*cx) : -sqrt(1.0 - cx*cx);

where in the latter case I know apriori that x lies within [0, TWOPI].

3) same as 2 but have to pre-condition x first:
   x  = fmod(x, TWOPI);
   cx = cos(x);
   sx = (x>-PI && x<PI) ? sqrt(1.0 - cx*cx) : -sqrt(1.0 - cx*cx);

I know these probably seem fairly inconsequential but over millions of
iterations, I'll take all the minor efficiency improvements i can get!

Thanks,
Scott

-----Original Message-----
From: Per Westermark [mailto:pw...@ia...]
Sent: Friday, November 01, 2002 3:56 PM
To: Scott Williams
Cc: Abhijit Shylanath; Dev-C++ Mailing List
Subject: RE: [Dev-C++] Use of const qualifier


Sorry, no correct answer on that one :-(

Depends on compiler, processor and what the calling function did. If only
targeted for a very specific machine, you have to time execution with the
two alternatives, else leave the function as it is.

Without relying on assembler - which is definitely CPU-specific - you
can't force static variables to be placed at an optimum alignment, and you
can't align the auto variables on the stack.

The auto is probably the best all-around alternative, since it allows the
compiler to use floating point registers. A static variable implies the
survival of the value to the next call, which will probably reduce the
effectivity of the compiler optimization step.

/Per W

On Fri, 1 Nov 2002, Scott Williams wrote:

> Thanks for the reply--very helpful.  You might know the answer to a
related
> question. . .
>
> I have a math-intensive subroutine that is called millions of times (yes,
> millions) by a numerical algorithm.  Currently, all of the variables in
this
> subroutine are of automatic extent.  Would there be any efficiency gained
by
> instead giving them static extent?  Each call to the subroutine is
> independent so retaining values across calls is not an issue.  Rather,
this
> is a question of how the memory access itself is handled.
>
> Thanks.
> Scott
>
>
> -----Original Message-----
> From: Abhijit Shylanath [mailto:mu...@gm...]
> Sent: Thursday, October 31, 2002 5:30 PM
> To: se...@al...; Dev-C++ Mailing List
> Subject: Re: [Dev-C++] Use of const qualifier
>
>
> > where myfunc uses the values of x and the array members of y but doesn't
> > change them.  Is there then an efficiency (speed) to be gained by
instead
> > declaring:
> >
> > double myfunc(const double x, const double *y)?
>
> More than speed, the const qualifier is for debugging. It prevents the
> programmer from inadvertently changing the values of certain variables.
Some
> new optimizing compilers also use it to align memory more efficiently.
>
> ___________________________________________________________
>
> Abhijit Shylanath
>
> E-mail:   mu...@gm... || ibr...@bi...
> Web-site: http://mudeth.tripod.com/
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> 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++] Use of const qualifier

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

Sorry, no correct answer on that one :-(

Depends on compiler, processor and what the calling function did. If only
targeted for a very specific machine, you have to time execution with the
two alternatives, else leave the function as it is.

Without relying on assembler - which is definitely CPU-specific - you
can't force static variables to be placed at an optimum alignment, and you
can't align the auto variables on the stack.

The auto is probably the best all-around alternative, since it allows the
compiler to use floating point registers. A static variable implies the
survival of the value to the next call, which will probably reduce the
effectivity of the compiler optimization step.

/Per W

On Fri, 1 Nov 2002, Scott Williams wrote:

> Thanks for the reply--very helpful.  You might know the answer to a related
> question. . .
> 
> I have a math-intensive subroutine that is called millions of times (yes,
> millions) by a numerical algorithm.  Currently, all of the variables in this
> subroutine are of automatic extent.  Would there be any efficiency gained by
> instead giving them static extent?  Each call to the subroutine is
> independent so retaining values across calls is not an issue.  Rather, this
> is a question of how the memory access itself is handled.
> 
> Thanks.
> Scott
> 
> 
> -----Original Message-----
> From: Abhijit Shylanath [mailto:mu...@gm...]
> Sent: Thursday, October 31, 2002 5:30 PM
> To: se...@al...; Dev-C++ Mailing List
> Subject: Re: [Dev-C++] Use of const qualifier
> 
> 
> > where myfunc uses the values of x and the array members of y but doesn't
> > change them.  Is there then an efficiency (speed) to be gained by instead
> > declaring:
> >
> > double myfunc(const double x, const double *y)?
> 
> More than speed, the const qualifier is for debugging. It prevents the
> programmer from inadvertently changing the values of certain variables. Some
> new optimizing compilers also use it to align memory more efficiently.
> 
> ___________________________________________________________
> 
> Abhijit Shylanath
> 
> E-mail:   mu...@gm... || ibr...@bi...
> Web-site: http://mudeth.tripod.com/
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm 
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> 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++] Use of const qualifier

[Ioannis V. <no...@ho...>]

> -----Original Message-----
> From: dev...@li... 
> [mailto:dev...@li...] On Behalf 
> Of Scott Williams
> Sent: Friday, November 01, 2002 8:38 PM
> To: Abhijit Shylanath; Dev-C++ Mailing List
> Subject: RE: [Dev-C++] Use of const qualifier
> 
> 
> Thanks for the reply--very helpful.  You might know the 
> answer to a related
> question. . .
> 
> I have a math-intensive subroutine that is called millions of 
> times (yes,
> millions) by a numerical algorithm.  Currently, all of the 
> variables in this
> subroutine are of automatic extent.  Would there be any 
> efficiency gained by
> instead giving them static extent?  Each call to the subroutine is
> independent so retaining values across calls is not an issue. 
>  Rather, this
> is a question of how the memory access itself is handled.


Yes. Also if you can make it easy to be inlined things will be more
better. Like:


// C++ code
inline int summary(const int &x, const int &y)
{
 return x+y; 
}


Ioannis

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

[Dev-C++] (no subject)

[Percy <pb...@te...>]

Hi there,

I need some examples on how to make a dll and use that under Visual Basic.
Please, I´m new with this stuff, so any help would be great.

Thanks,

Percy

RE: [Dev-C++] Use of const qualifier

[Scott W. <se...@al...>]

Thanks for the reply--very helpful.  You might know the answer to a related
question. . .

I have a math-intensive subroutine that is called millions of times (yes,
millions) by a numerical algorithm.  Currently, all of the variables in this
subroutine are of automatic extent.  Would there be any efficiency gained by
instead giving them static extent?  Each call to the subroutine is
independent so retaining values across calls is not an issue.  Rather, this
is a question of how the memory access itself is handled.

Thanks.
Scott


-----Original Message-----
From: Abhijit Shylanath [mailto:mu...@gm...]
Sent: Thursday, October 31, 2002 5:30 PM
To: se...@al...; Dev-C++ Mailing List
Subject: Re: [Dev-C++] Use of const qualifier


> where myfunc uses the values of x and the array members of y but doesn't
> change them.  Is there then an efficiency (speed) to be gained by instead
> declaring:
>
> double myfunc(const double x, const double *y)?

More than speed, the const qualifier is for debugging. It prevents the
programmer from inadvertently changing the values of certain variables. Some
new optimizing compilers also use it to align memory more efficiently.

___________________________________________________________

Abhijit Shylanath

E-mail:   mu...@gm... || ibr...@bi...
Web-site: http://mudeth.tripod.com/

Re: [Dev-C++] c++ widows, menus

[Carlos d. M. <cg...@wo...>]

I would recommend "Win32 Programing" By Brent E. Rector and Joseph M.
Newcomer
Other would say "Windows programming" by Charles Petzold.
Sites: www.winprog.org and www.relisoft.com

RE: [Dev-C++] Use of const qualifier

[Ioannis V. <no...@ho...>]

> -----Original Message-----
> From: dev...@li... 
> [mailto:dev...@li...] On Behalf 
> Of Scott Williams
> Sent: Thursday, October 31, 2002 11:38 PM
> To: Dev-Cpp-Users@Lists. Sourceforge. Net
> Subject: [Dev-C++] Use of const qualifier
> 
> 
> Hi,
> 
> You've all been so helpful, I'm back for more . . .
> 
> I'm curious about the use of the "const" qualifier as it applies to
> prototyping function arguments.  In particular, suppose I 
> have a function:
> 
> double myfunc(double x, double *y)
> 
> where myfunc uses the values of x and the array members of y 
> but doesn't
> change them.  Is there then an efficiency (speed) to be 
> gained by instead
> declaring:
> 
> double myfunc(const double x, const double *y)?
> 
> Are there other advantages/disadvantages?


The main benefit is type safety, that is protection from accidental
errors.


Ioannis

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

RE: [Dev-C++] c++ widows, menus

[Mark L. W. <ma...@al...>]

Randal,

the #define is a compiler directive, not part of the language.  The
statement #define IDM_EDITUNDO  210 simply assigns a symbol (IDM_EDITUNDO=
)
the value of "210".  You can think of this as doing a global find/replace=
 of
IDM_EDITUNDO with 210 (thats basically what the compiler does).

In windows, you assign values to events, so this statement is probably
assigning 210 as the event number for the Edit Undo command.  Later in th=
e
code you should see an event list referencing the IDM_EDITUNDO value and
executing a function that implements edit undo.

As for a book, when you find one, let ME know.... ;-)

I have found www.howstuffworks.com that has some great tutorial material.

Hope this helps!

Mark
  -----Original Message-----
  From: dev...@li...
[mailto:dev...@li...]On Behalf Of Randal Eck
  Sent: Friday, November 01, 2002 8:32 AM
  To: dev...@li...
  Subject: [Dev-C++] c++ widows, menus





  I am taking a course online about Visual C++, but would still like to k=
now
about C++ so I can create stuff for Linux. I am trying to learn C++ by
studying the examples in Dev C++ 4. I must admit I feel lost learning thi=
s
way. With a Visual IDE all this stuff is taken care of. Here is an exampl=
e
from the Dev C++ and so far I can figure out that

  #define IDM_EDITUNDO        210

   #define is a command or keyword (no problem)

  IDM is IDMenu, I think

  210 I have no idea about.



  I have read a couple books about C++ but thet don=92t deal with creatin=
g
windows, menus or anything related to a GUI. Can u suggest a few good boo=
ks
on they subject. Maybe a website. Thanks






-------------------------------------------------------------------------=
---
--
  Choose an Internet access plan right for you -- try MSN! Click
Here ------------------------------------------------------- This sf.net
email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Colo=
r
in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm000=
1en
_______________________________________________ Dev-cpp-users mailing lis=
t
Dev...@li... TO UNSUBSCRIBE:
http://www.noicys.cjb.net/devcpp/ub.htm
https://lists.sourceforge.net/lists/listinfo/dev-cpp-users

[Dev-C++] c++ widows, menus

[Randal E. <ra...@ho...>]

<html><div style='background-color:'><DIV>
<P><BR>&nbsp;</P>
<P class=MsoNormal>I am taking a course online about Visual C++, but would still like to know about C++ so I can create stuff for Linux. I am trying to learn C++ by studying the examples in Dev C++ 4. I must admit I feel lost learning this way. With a Visual IDE all this stuff is taken care of. Here is an example from the Dev C++ and so far I can figure out that</P>
<P class=MsoNormal><B>#define IDM_EDITUNDO<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>210<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></B></P>
<P class=MsoNormal><SPAN style="mso-spacerun: yes">&nbsp;</SPAN>#define is a command or keyword (no problem)</P>
<P class=MsoNormal>IDM is IDMenu, I think</P>
<P class=MsoNormal>210 I have no idea about.</P>
<P class=MsoNormal>&nbsp;<o:p></o:p></P>
<P class=MsoNormal>I have read a couple books about C++ but thet don’t deal with creating windows, menus or anything related to a GUI. Can u suggest a few good books on they subject. Maybe a website. Thanks</P>
<P><BR></P></DIV></div><br clear=all><hr>Choose an Internet access plan right for you -- try MSN! <a href="http://g.msn.com/8HMJEN/2015">Click Here</a> </html>

RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp

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

Please. Life is too short to religious wars about which language is the
best. I have never ever said that a C or C++ program is slower than a
Fortran program. Only that because of changes in the memory layout of the
different languages, a direct translation of a Fortran program will be 
slower in C, just as a direct translation of a C program will be slower in
Fortran.

The following link is quite good at discussing differences between array
definitions for a couple of languages:
http://www.compaq.com/fortran/docs/vf-html/pg/pgwarray.htm

It isn't possible to just swap index order of a multi-dimensional array,
since large lin-pack code often perform evaluation of subsets of the
array.

The attached source code displays exactly this behaviour. It contains two
test cases, using same algorithm but different memory layout.
- Array access in correct and incorrect order.
- Access speed for optimal and non-uptimal struct.

The speed difference between the two alternatives applies for just about
all programming languages, and just about all all computer architectures
and compilers. The only thing that differs is the amount of speed
difference between good and bad access patterns.

Small memory (< 80MB) on Linux, 1GHz PIII, 512MB
  Processing array out of order  31.3 seconds (50.1 ns/iteration)
  Processing array in order      16.5 seconds (26.5 ns/iteration)
  Improvement factor             1.89
  Non-optimum struct access      24.4 seconds (488 ns/iteration)
  Optimum struct access          12.5 seconds (250 ns/iteration)
  Improvement factor             1.95
  Total user time                46.3 seconds
  Total system time              0.5 seconds

Small memory (< 80MB) on WinXP, 1.2GHz AMD, 512MB
  Processing array out of order 46.3 seconds (74.1 ns/iteration)
  Processing array in order     7.76 seconds (12.4 ns/iteration)
  Improvement factor            5.97
  Non-optimum struct access     11.2 seconds (224 ns/iteration)
  Optimum struct access         10.2 seconds (204 ns/iteration)
  Improvement factor            1.1
  Total user time               68.9 seconds
  Total system time             0.371 seconds

Large memory (< 800MB) on Linux, 1GHz PIII, 512MB
  Processing array out of order  2.83e+03 seconds (28.3e+03 ns/iteration)
  Processing array in order      175 seconds (1.75e+03 ns/iteration)
  Improvement factor             16.2
  Non-optimum struct access      354 seconds (35.4e+03 ns/iteration)
  Optimum struct access          225 seconds (22.5e+03 ns/iteration)
  Improvement factor             1.57
  Total user time                23.7 seconds
  Total system time              646 seconds

Large memory (< 800MB) on WinXP, 1.2GHz AMD, 512MB
  Processing array out of order  1.13e+003 seconds (11.3e+03 ns/iteration)
  Processing array in order      455 seconds (4.55e+03 ns/iteration)
  Improvement factor             2.49
  Non-optimum struct access      120 seconds (12e+03 ns/iteration)
  Optimum struct access          106 seconds (10.6e+03 ns/iteration)
  Improvement factor             1.14
  Total user time                46.1 seconds
  Total system time              29.8 seconds

Linux machine: gcc 2.95.4, -O2
WinXP machine, gcc 2.95.3-6, -O2
The small case was run without memory swapping.
The large case was run with memory swapping.

/Per W

On Thu, 31 Oct 2002, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: Per Westermark [mailto:pw...@ia...] 
> > Sent: Thursday, October 31, 2002 11:02 AM
> > To: Ioannis Vranos
> > Cc: 'Dev-C++ Mailing List'
> > Subject: RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> > 
> > No, the concept is just about the same for any machine. It is just the
> > width of the memory interface, the cache line sizes, the 
> > number of cache
> > lines etc that are different. A Fortran (or C, Pascal etc) program
> > optimized for locality of reference of data accesses will 
> > will gain speed
> > on just about any computer architecture. It doesn't matter if we talk
> > about Von Neuman, SIMD, MIMD or whatever kind of machine. The physical
> > properties of memory still applies, i.e. cache is faster than primary
> > memory, primary memory is faster than disk.
> > The original Fortran algorithms might have been written for a 
> > Vax machine,
> > but the same optimizations still improves the speed on a Xeon 
> > processor.
> 
> Yes i agree. However those same types of optimisations can be performed
> in C code even if it accesses the array backwards (like Fortran does as
> you say).
> 
> 
> 
> > You disagree, while still agreeing :-) I am talking about algorithmig
> > optimization, not language optimization, and I am talking about the
> > problem of just translating an algorithm from one language to another
> > while still keeping the speed.
> 
> Algorthmically speaking, general algorithms (natively & beautifully
> supported by C++ templates) are the same for all types and languages
> (for example bubble sort etc). And the cost in Big-Oh notation is the
> same. And every compiler can perform optimisations.
> 
> 
> 
> > Take a C++ template solution 
> > with sort. I
> > can't easily convert that code to another language.
> 
> Regarding templates yes, you have to create type specialisations.
> However for a specific type why not?
> 
> 
> 
> > However, 
> > I can still
> > get the same speed in a Pascal program by doing a full 
> > rewrite, doing a
> > hand-coded qsort with inline comparison. The same goes the 
> > other way. I
> > can't take an optimized  Fortran program and convert statement for
> > statement to a C++ program and match the speed.
> 
> 
> Why? C++ has also close to the metal facilities for hand-coding that
> Fortran lacks.

When moving Fortran algorithm to C, you must rewrite all data structures
and array references, since the Fortran algorithm is written specifically
for the Fortran memory model. Yes it can be done, but if it took several
man years to write the Fortran code, don't expect less than several man
months to do it in C/C++.

> 
> 
>  
> > Since we are talking about algorithmic efficiency, and locality of
> > reference of data accesses, it shouldn't matter so much about which
> > computer architecture. The location of the break points in 
> > your referenced
> > document moves a bit to the left or right because of cache 
> > sizes, but htey
> > wouldn't even be there if locality of reference wasn't an issue, since
> > these break points isn't about code generation, but about data access
> > patterns of the algorithm.
> 
> 
> I don't understand clearly. For example,  I assume that GCC's fortran
> however-are-called integer types and GCC's C++ equivallents are the same
> implementation.
An integer for an integer or a double for a double isn't a problem.
Keeping the integers or doubles placed in the correct memory order for a
translated program is hard.
> 
> 
> Are you talking for Fortran strings (if they exist!) etc vs C++ high
> level constructs? Like C++'s complex STL type? Yes these things are not
> easy to be used from inside another language, i am talking only about
> built in types.

Strings normally never consume any time in a real program. 0.1 seconds or
0.2 seconds to open a dialog hardly matters. Fortran programs are normally
performing brutal math, where the run times may be everything from minutes
up to months or more. A factor 2 speed loss for a program requiring 1
month would result in wasted month... To solve such a problem with
another language, you can't just translate the program, since a
translation will not use the optimal features and memory layouts of the
new language.

> 
> 
> Ioannis
> 
> * Ioannis Vranos
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL: http://run.to/noicys
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future 
> of Java(TM) technology. Join the Java Community 
> Process(SM) (JCP(SM)) program now. 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> _______________________________________________
> 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++] F9 vs. F8 ...

[Phil <tsy...@ya...>]

Hi,

Just wondering if someone has yet noticed the
following behaviour :

I am using Dev-C++ v.4.9.6.5 , Win 2K platform (sri !)

Devcpp.exe is located in the d:\Dev-Cpp\ directory.

My sources are located in the
d:\Dev-Cpp\projects\current directory (Win32 GUI
project).

Makefile says :

# Project: MyProj
# Makefile created by Dev-C++ 4.9.6.5

CC   = g++.exe
WINDRES = windres.exe
RES  = MyProj_private.res
OBJ  = obj/main.o obj/file_func.o obj/decode_func.o
$(RES)
LIBS =  -L"D:/Dev-Cpp/lib" -lcomctl32
INCS =  -I"D:/Dev-Cpp/include" 
-I"D:/Dev-Cpp/include/g++-3"  -I"D:/Dev-Cpp/include" 
-I"D:/Dev-Cpp/projects/current/include" 
BIN  = bin/MyProj.exe

<blabla>

$(BIN): $(OBJ)
	$(CC) $(OBJ) -o "bin\MyProj.exe" $(LIBS) $(CFLAGS)


So the generated binary is in
d:\Dev-Cpp\projects\current\bin

I am using the GetCurrentDirectory Function.

If my app is launched via the F9 function key,
GetCurrentDirectory returns
"d:\\Dev-Cpp\\projects\\current\\bin"

If the app is launched via Debug (F8),
GetCurrentDirectory returns
"d:\\Dev-Cpp\\projects\\current"

Any way to get the same value in both cases ?


===

While speaking of Debug, "ALT+F2" should stop the
execution. It does not.
I have checked the shortcuts and "ALT+F2" is _also_
set for "Program Reset".
If I erase the shortcut for "Program Reset", then
"ALT+F2" actually stops the execution when debugging.

FWIW

Regards,

Phil

__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

Re: [Dev-C++] New User - question on linking files within a project

[Derek W. <py...@pr...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
The reason you are getting multiple linker errors about the functions in
your code is because they haven't ben<br>
previously <i>declared</i>.  You will have to make header files (*.h) (or
one header file) which contain declarations <br>
of your functions.  Include this header file within any source file that
uses a function that is declared within<br>
that header file.<br>
<br>
Example:<br>
<br>
<hr width="100%" size="2">test.c<br>
<br>
int myFunction ( int a )<br>
{<br>
        return (a * a);<br>
}<br>
<hr width="100%" size="2"><br>
To use this function in another source file you would have to create a header
file :<br>
<hr width="100%" size="2">test.h<br>
<br>
int myFunction ( int a );<br>
<hr width="100%" size="2"><br>
To use this function within, let's say, main.c you would do:<br>
<br>
<hr width="100%" size="2">main.c<br>
<br>
#include &lt;stdio.h&gt;<br>
<b>#include "test.h"</b><br>
<br>
int main ( int argc, char *argv[] )<br>
{<br>
<br>
    int num = 2;<br>
    int result = myFunction ( num );<br>
<br>
    ....<br>
<br>
    return 0;<br>
}<br>
<hr width="100%" size="2"><br>
<br>
I hope this helps.<br>
<br>
<br>
- Derek<br>
<br>
<br>
<br>
Y&amp;S Geadah wrote:<br>
<blockquote type="cite" cite="mid000801c2811a$47fb9cc0$8400a8c0@sandy">  
  <meta http-equiv="Content-Type" content="text/html; ">
 
  <meta content="MSHTML 6.00.2719.2200" name="GENERATOR">
 
  <style></style>  
  <div><font size="2">I am a new user to the Dec-C++ IDE, with a reasonably
good  knowledge of the</font></div>
 
  <div><font size="2">C language, but very poor knowledge of other tools
(linker,  debugger, etc...)</font></div>
 
  <div> </div>
 
  <div><font size="2">My problem is as follows:</font></div>
 
  <div><font size="2">   - I have been developing a program in C, with all
 the source code (main and </font></div>
 
  <div><font size="2">     functions) in one source file, i.e.  my project
consisted of only one file (extension .c)</font></div>
 
  <div> </div>
 
  <div><font size="2">   - as the program grew bigger and bigger, I  decided
to move the functions into</font></div>
 
  <div><font size="2">     their separate source files, for ease  of editing;I
added their source files (*.c)</font></div>
 
  <div><font size="2">     to the project list</font></div>
 
  <div> </div>
 
  <div><font size="2">   - by doing so, I am getting many compiler and  linker
errors (note: some</font></div>
 
  <div><font size="2">     of the function arguments are  structures; other
functions access files, </font></div>
 
  <div><font size="2">     i.e. use fopen, fprintf, ... Again,  everything
works fine with a single source</font></div>
 
  <div><font size="2">     files, containing main() and all  functions)</font> </div>
 
  <div> </div>
 
  <div><font size="2">I must be missing something fundamental in the structure
(due  to my lack of</font></div>
 
  <div><font size="2">understanding of how files are linked). Are there any
online  information (more</font></div>
 
  <div><font size="2">tutorial-like) on such topics?</font></div>
 
  <div> </div>
 
  <div><font size="2">Any help will be much appreciated. </font></div>
 
  <div> </div>
 
  <div><font size="2">Regards, </font></div>
 
  <div> </div>
 
  <div><font size="2">YG</font></div>
</blockquote>
<br>
<br>
</body>
</html>

Re: [Dev-C++] Use of const qualifier

[Abhijit S. <mu...@gm...>]

> where myfunc uses the values of x and the array members of y but doesn't
> change them.  Is there then an efficiency (speed) to be gained by instead
> declaring:
>
> double myfunc(const double x, const double *y)?

More than speed, the const qualifier is for debugging. It prevents the
programmer from inadvertently changing the values of certain variables. Some
new optimizing compilers also use it to align memory more efficiently.

___________________________________________________________

Abhijit Shylanath

E-mail:   mu...@gm... || ibr...@bi...
Web-site: http://mudeth.tripod.com/

[Dev-C++] Use of const qualifier

[Scott W. <se...@al...>]

Hi,

You've all been so helpful, I'm back for more . . .

I'm curious about the use of the "const" qualifier as it applies to
prototyping function arguments.  In particular, suppose I have a function:

double myfunc(double x, double *y)

where myfunc uses the values of x and the array members of y but doesn't
change them.  Is there then an efficiency (speed) to be gained by instead
declaring:

double myfunc(const double x, const double *y)?

Are there other advantages/disadvantages?

Thanks,
Scott

[Dev-C++] New User - question on linking files within a project

[Y&S G. <yg...@sy...>]

I am a new user to the Dec-C++ IDE, with a reasonably good knowledge of =
the
C language, but very poor knowledge of other tools (linker, debugger, =
etc...)

My problem is as follows:
   - I have been developing a program in C, with all the source code =
(main and=20
     functions) in one source file, i.e. my project consisted of only =
one file (extension .c)

   - as the program grew bigger and bigger, I decided to move the =
functions into
     their separate source files, for ease of editing;I added their =
source files (*.c)
     to the project list

   - by doing so, I am getting many compiler and linker errors (note: =
some
     of the function arguments are structures; other functions access =
files,=20
     i.e. use fopen, fprintf, ... Again, everything works fine with a =
single source
     files, containing main() and all functions)=20

I must be missing something fundamental in the structure (due to my lack =
of
understanding of how files are linked). Are there any online information =
(more
tutorial-like) on such topics?

Any help will be much appreciated.=20

Regards,=20

YG

[Dev-C++] SplashWindow problems

[Mark L. W. <ma...@al...>]

I did not get any responses to my request for information regarding
SplashWindow problems in Dev-C++, but for anyone interested....

The Splash.cpp and Splash.h files are missing from the .DevPak and WxWindows
distributions (which makes me wonder why the classes are listed in the
documentation for WxWindows...)

Also, the Splash.cpp source has a conditional in it that makes it not
compile unless you set #define wxUSE_SPLASH because the following if wrapper
is included in the source:

#if wxUSE_SPLASH

<all of the Splash Code here>

#endif

Anyone have any idea why these classes are not fundamental to the WxWindows
package?

Thanks!

Mark

BTW, I did get my program to function!!!

[Dev-C++] compiler design

[Ihsan A. Al D. <ia...@jo...>]

Hi...

Does any one of u know where I can find on the net how to develop a compiler
for my own designed language n C++?

mohammed

RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp

[Ioannis V. <no...@ho...>]

> -----Original Message-----
> From: Per Westermark [mailto:pw...@ia...] 
> Sent: Thursday, October 31, 2002 11:02 AM
> To: Ioannis Vranos
> Cc: 'Dev-C++ Mailing List'
> Subject: RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> 
> No, the concept is just about the same for any machine. It is just the
> width of the memory interface, the cache line sizes, the 
> number of cache
> lines etc that are different. A Fortran (or C, Pascal etc) program
> optimized for locality of reference of data accesses will 
> will gain speed
> on just about any computer architecture. It doesn't matter if we talk
> about Von Neuman, SIMD, MIMD or whatever kind of machine. The physical
> properties of memory still applies, i.e. cache is faster than primary
> memory, primary memory is faster than disk.
> The original Fortran algorithms might have been written for a 
> Vax machine,
> but the same optimizations still improves the speed on a Xeon 
> processor.

Yes i agree. However those same types of optimisations can be performed
in C code even if it accesses the array backwards (like Fortran does as
you say).



> You disagree, while still agreeing :-) I am talking about algorithmig
> optimization, not language optimization, and I am talking about the
> problem of just translating an algorithm from one language to another
> while still keeping the speed.

Algorthmically speaking, general algorithms (natively & beautifully
supported by C++ templates) are the same for all types and languages
(for example bubble sort etc). And the cost in Big-Oh notation is the
same. And every compiler can perform optimisations.



> Take a C++ template solution 
> with sort. I
> can't easily convert that code to another language.

Regarding templates yes, you have to create type specialisations.
However for a specific type why not?



> However, 
> I can still
> get the same speed in a Pascal program by doing a full 
> rewrite, doing a
> hand-coded qsort with inline comparison. The same goes the 
> other way. I
> can't take an optimized  Fortran program and convert statement for
> statement to a C++ program and match the speed.


Why? C++ has also close to the metal facilities for hand-coding that
Fortran lacks.


 
> Since we are talking about algorithmic efficiency, and locality of
> reference of data accesses, it shouldn't matter so much about which
> computer architecture. The location of the break points in 
> your referenced
> document moves a bit to the left or right because of cache 
> sizes, but htey
> wouldn't even be there if locality of reference wasn't an issue, since
> these break points isn't about code generation, but about data access
> patterns of the algorithm.


I don't understand clearly. For example,  I assume that GCC's fortran
however-are-called integer types and GCC's C++ equivallents are the same
implementation.


Are you talking for Fortran strings (if they exist!) etc vs C++ high
level constructs? Like C++'s complex STL type? Yes these things are not
easy to be used from inside another language, i am talking only about
built in types.


Ioannis

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

RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp

[Louis G. <lg...@ya...>]

Hi all,
I suggest we are missing the point of the original question.

The original question was about mixed-language programming.
 i.e. a compiler that is capable of compiling a single program, one part
of which is written in C and another oart in FORTRAN. GCC IS a mixed
compiler.

What you seem to  be dealing with below is CONVERTING a program written in
FORTRAN to an equivalent C/C++ program.

 Converting a FORTRAN program is difficult because of the fundamental
differences in the way FARTRAN and C/C++ stores multi-dimentional arrays,
the way parameters are passed to functions, and the way arrays are indexed
(C arrays start with index zero, FORTRAN starts with 1). You have to
re-write a program to convert it or use a program like 'f2C' (which in my
experience works poorly)

A MIXED compiler (if working correctly) is well-aware of the FORTRAN vs
C/C++ differences and should compile object code for mixed programs
correctly. The only thing that one has to learn is how to place, in the
source code, a compiler instruction or 'switch' that tells the gcc
compiler to begin and end the processing FORTRAN source code statements.
 I not sure how to do this with gcc.

 
--- Per Westermark <pw...@ia...> wrote:
> When you have declared
> double a[10][10]
> it is quite important to know in which order the individual values are
> stored in memory, when trying to interface between two languages.
> 
> If your C program does a[x][y] and your Fortran program has do do
> a[z][y] to reach the same entry. No problem when you have all three
> index variables available.
> 
> However, when you take a pointer to a an entry inside the array, the
> operation might be seen as a projection down to an array with fewer
> dimensions. Obviously, if the entry order in memory has been transposed,
> the such a projection will fail misserably when switching languages. The
> 
> sender thought it sent a row, but the receiver got a column.
> 
> When people originally started to push for the C language, the above
> problem gave rise to a related problem. When referencing large memory
> structures, it is important to assure that the code uses locality of
> reference and doesn't jump around everywhere in the data. Large linear
> packages are always implemented so that they process entries in the same
> order that they are stored in memory. When converting such an algorithm
> -
> might be thousands uppon thousands of lines of code - it isn't s easy to
> just try and adjust for row/column switches. The result is that a C
> translation of a Fortran algorithm might loose 10-30% or maybe more of
> the
> speed when the same Fortran algorithm was run.
> The mathematical world decided that C was a slower language :-)
> Nowadays,
> there are a lot of good algorithms originally written for C, so this
> issue
> shouldn't be a problem anymore. But still, there are some billion
> Fortran lines of optimized and very advanced mathematics algorithms out
> there.
> 
> /Per W
> 
> On Wed, 30 Oct 2002, Marc Heiligers wrote:
> 
> > To Ioannis,
> > 
> > Funny thing is I was reading an old Turbo C reference guide I have
> lying
> > around that mentioned linking Turbo C and Turbo Fortran (was it called
> > that?). Borland seemed to very proud of this cross language linking.
> There
> > are some difficulties with function name decoration and what-not that
> you
> > need to be aware of. I can't quite recall what they were, but I'll try
> to
> > remember to take a look this evening.
> > 
> > I'm not sure if the same advice will apply here since it is clearly
> > different compilers, but it may give you an idea. I'd still look on
> the net
> > for info specific to the compilers you want to use.
> > 
> > To Per,
> > Is there anything you don't know anything about? (LOL).
> > 
> > I don't recall if the above mentioned book mentioned any difficulties
> with
> > multi-dimensional arrays. Besides, as far as I'm aware, C uses arrays
> of
> > arrays and not multi-dimensional arrays, so would the trick not be to
> set
> > your arrays up in the same way that Fortran does?
> > 
> > _____________________________
> > Marc Heiligers
> > 
> > 
> > -----Original Message-----
> > From: Per Westermark [mailto:pw...@ia...] 
> > Sent: 30 October 2002 11:40 AM
> > To: Ioannis Vranos
> > Cc: Dev-C++ Mailing List
> > Subject: RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> > 
> > 
> > I think there might be acoule of gotchas more to think about.
> > 
> > Doesn't fortran have the reversed row/column order for
> multi-dimensional
> > arrays?
> > 
> > Anyway, I assume that there already exists excellent FAQ documents for
> this
> > kind of problems.
> > 
> > /Per W
> > 
> > On Wed, 30 Oct 2002, Ioannis Vranos wrote:
> > 
> > > > -----Original Message-----
> > > > From: dev...@li...
> > > > [mailto:dev...@li...] On Behalf 
> > > > Of Scott Williams
> > > > Sent: Tuesday, October 29, 2002 10:34 PM
> > > > To: Dev-Cpp-Users@Lists. Sourceforge. Net
> > > > Subject: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > Wondering if anyone has experience with mixed language programming
> 
> > > > and whether it can be done with Dev-Cpp?
> > > > 
> > > > In particular, I'm writing a mathematical simulation in C
> > > > (using Dev-Cpp)
> > > > and would like to make using of some existing numerical 
> > > > routines in Fortran.
> > > > My C knowledge is necessity-based self-taught and so limited; 
> > > > don't know
> > > > anything about Fortran.  Neither do I know much about using
> > > > compilers/linkers/etc in command line mode (which is why I 
> > > > use Dev-Cpp--I
> > > > let it worry about that stuff).
> > > > 
> > > > Still, I know that built-in to the gcc interface is the g77
> > > > compiler so
> > > > there must be a way to compile the fortran source to an 
> > > > object with g77 and
> > > > then link to & call the routines from C.  Could it be as 
> > > > simple as added
> > > > fortran source files to my Dev-Cpp project?  If so, any 
> > > > thoughts on how to
> > > > prototype the Fortran functions & subfunctions to make them 
> > > > accessible to
> > > > the C calling routines?
> > > 
> > > 
> > > Well if you download the whole MINGW distribution it contains a 
> > > Fortran compiler. In theory as i can think of it, if you compile
> your 
> > > fortran source code files to .o files and use C-style declarations
> of 
> > > those functions in your C source code, you should be able to use
> them.
> > > 
> > > 
> > > Ioannis
> > > 
> > > * Ioannis Vranos
> > > * Programming pages: http://www.noicys.freeurl.com
> > > * Alternative URL: http://run.to/noicys
> > > 
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > 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


__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

Re: [Dev-C++] Package for last wxWindows 2.3.3 ?

[didier B. <di...@oc...>]

Le 30/10/2002 09:49, Luc Saint-Elie a écrit :

> (...) or How can I make a package?

What I have discovered so far about that:

Copy some of your xxx.DevPack as xxx.tar.bz2, then look inside them...
You can use untbz2, or 7-zip for extracting tar.bz2 archives. If you 
have neither,
you can use what get bundled with Dev-C++ in bin (BUnzip2, then tar)

You'll find a xx.DevPackage somewhere, which is a text file describing 
the package.

Then, create the same structure with your files, make a tar.bz2 archive, 
rename it in
DevPack and that's all.
--
didier

[Dev-C++] DEV-C++ ON LINUX

[Zubillaga F. <FZu...@ik...>]

I have install dev-c++ on win2000 and works ok. I have tried to install it
over Linux (mandrake 8.2) and I cannot make it work.
The installation goes OK. Then I execute the file devcpp (I think that is
called like that) and nothing happens. I execute a "ps" Unix command (ps
-ef|grep devcpp) to see if the process was created, and it was. I think that
I miss an X module to display the application.
Please does anyone know what is going on?

thanks 

Fernando

RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp

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

EMA System        email: pw...@ia...
Per Westermark    web: http://iapetus.neab.net
Vargvaegen 174B   phone: +46 8 410 17 198
S-906 42 Umeaa
Sweden


On Thu, 31 Oct 2002, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: Ioannis Vranos [mailto:no...@ho...] 
> > Sent: Thursday, October 31, 2002 12:22 AM
> > To: 'Dev-C++ Mailing List'
> > Subject: RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> > 
> > 
> > I disagree. If you mean C algorithms accessing Fortran 
> > structures i can agree, only when talking about a dedicated system.
> > On non-dedicated systems, and C structures C code can be the 
> > same efficient (and sometimes even more).
> 
> 
> That is: "For Fortran structures at non-dedicated systems, and C/C++
> structures in every type of system, C/C++ code can be the same efficient
> (and sometimes even more)".
Once more you agree with me. C/C++ code can be as efficient as Fortran,
but only if the code is written to take advantage of the C/C++ language.
Dedicated machines is a side issue. Whatever processor or machine, you
can't simly translate a program from one language to another and get
optimum performance. The require often requires algorithmic changes to fit
the other language.
>
>
> 
> Ioannis
> 
> * Ioannis Vranos
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL: http://run.to/noicys
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future 
> of Java(TM) technology. Join the Java Community 
> Process(SM) (JCP(SM)) program now. 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> _______________________________________________
> 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++] Mixed Language Programming w/Dev-Cpp

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

On Thu, 31 Oct 2002, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: Per Westermark [mailto:pw...@ia...] 
> > Sent: Wednesday, October 30, 2002 11:49 PM
> > To: Ioannis Vranos
> > Cc: 'Dev-C++ Mailing List'
> > Subject: RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> > 
> > 
> > The speed issue isn't in this case a question about the efficiency of
> > Fortran or C, but the efficiency of porting an algorithm 
> > written for one
> > language to another language.
> > 
> > The array index  order of a language - many languages, but 
> > not all - may
> > not be changed in the language implementation, but are 
> > specified in the
> > description of the language.
> > 
> > The internal cache lines in the processor have a lot wider access path
> > than the primary memory. For a 32-bit processor, the memory 
> > access path
> > might be 64 bit, but the cache-lines might be 128 bit, 256 bit or even
> > wider. Everytime the processor doesn't find it's data in a 
> > cache line, it
> > has to wait for the data to be fetched from primary memory. 
> > That takes a
> > lot of time. Obviously, any memory-intensive algorithm should 
> > make sure
> > that the access pattern matches the physical storage of the data. Data
> > here isn't just integers and floats to perform math on, but just as
> > well the generated object code.
> > 
> > When programming in a high-level language, you normally 
> > doesn't have to
> > think so much about generated object code. That's up to the compiler.
> > 
> > However, the data layout is important. If I know that a 
> > specific processor
> > always loads at least 16 bytes from memory, whenever a cache 
> > line fails, I
> > may decide to place my 16 byte of "favorite" data first in any used
> > struct, so that the processor loads all the data from memory 
> > at a single
> > time, thereby reducing number of cache stalls.
> > 
> > On a bigger scale, when solving linear equations, the used 
> > matrices might
> > very well be 10000x10000 entries large. If each entry is a 
> > 8-byte double,
> > such a matrix will then consume 800 MB memory. If the machine 
> > hasn't that
> > amount of memory, it will start to swap out data to disk. A 
> > typical swap
> > block size might be 4kB, or 500 double numbers. If the 
> > program accesses
> > the entries in a sequential way, each disk load will guarantee 500
> > successful accesses before a new disk load is needed. If the program
> > accesses the entries in a random order (or with row/column 
> > swapped), EVERY
> > new accessed entry will require a disk load operation...
> 
> 
> All these are true. However all these that you say apply to dedicated
> machines. In a regular whatever PC with whatever multitasking OS you
> can't control the cache etc. So regarding the question of the fellow,
> there can not be an impact in speed.
No, the concept is just about the same for any machine. It is just the
width of the memory interface, the cache line sizes, the number of cache
lines etc that are different. A Fortran (or C, Pascal etc) program
optimized for locality of reference of data accesses will will gain speed
on just about any computer architecture. It doesn't matter if we talk
about Von Neuman, SIMD, MIMD or whatever kind of machine. The physical
properties of memory still applies, i.e. cache is faster than primary
memory, primary memory is faster than disk.
The original Fortran algorithms might have been written for a Vax machine,
but the same optimizations still improves the speed on a Xeon processor.
> 
> 
> > 
> > This isn't a problem for script languages etc, but a reason why few
> > "efficiency-oriented" programming languages leaves the definition
> > of array index order up to the implementation. For small structures, a
> > row/column transpose might double the execution time because of cache
> > trashing. For large structures, where swapping is needed, the speed
> > difference might be a factor of several thousand.
> > 
> > Most good Fortran algorithms contains thousands of thousands 
> > of lines of
> > code specifically designed to access the needed data in optimum order.
> > That is an important reason why it takes thousands of 
> > thousands of lines
> > of C code to match the performance. 
> 
> I disagree. If you mean C algorithms accessing Fortran structures i can
> agree, only when talking about a dedicated system.
> On non-dedicated systems, and C structures C code can be the same
> efficient (and sometimes even more).
You disagree, while still agreeing :-) I am talking about algorithmig
optimization, not language optimization, and I am talking about the
problem of just translating an algorithm from one language to another
while still keeping the speed. Take a C++ template solution with sort. I
can't easily convert that code to another language. However, I can still
get the same speed in a Pascal program by doing a full rewrite, doing a
hand-coded qsort with inline comparison. The same goes the other way. I
can't take an optimized  Fortran program and convert statement for
statement to a C++ program and match the speed.

Since we are talking about algorithmic efficiency, and locality of
reference of data accesses, it shouldn't matter so much about which
computer architecture. The location of the break points in your referenced
document moves a bit to the left or right because of cache sizes, but htey
wouldn't even be there if locality of reference wasn't an issue, since
these break points isn't about code generation, but about data access
patterns of the algorithm.
> 
> 
> 
> > The same goes with just about any
> > programming language. Understanding of language and target 
> > machine might
> > be the difference between being able to solve a problem, or 
> > having to wait
> > a couple of years for faster machines to be released.
> 
> Yes.
> 
> 
> Ioannis
> 
> * Ioannis Vranos
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL: http://run.to/noicys
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future 
> of Java(TM) technology. Join the Java Community 
> Process(SM) (JCP(SM)) program now. 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> _______________________________________________
> 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++] RE: Dev-cpp-users digest, Vol 1 #1092 - 1 msg

[Pierre L. <fam...@gl...>]

I succeed in compiling wxWindows project in IDE Dev-C++. But the compile
process is sometime hard and the compile errors are difficults to resolve.

Pierre

-----Message d'origine-----
De : dev...@li...
[mailto:dev...@li...]De la part de
dev...@li...
Envoye : 30 octobre, 2002 15:05
A : dev...@li...
Objet : Dev-cpp-users digest, Vol 1 #1092 - 1 msg

Send Dev-cpp-users mailing list submissions to
        dev...@li...

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
or, via email, send a message with subject or body 'help' to
        dev...@li...

You can reach the person managing the list at
        dev...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dev-cpp-users digest..."


Today's Topics:

   1. Re: Compiling wxWindows 2.2.9 samples with Dev-C++ 4.9.6.6 (Carlos
=?iso-8859-1?Q?Garc=EDa?= del Monte)

--__--__--

Message: 1
Date: Wed, 30 Oct 2002 19:09:02 +0100
From: Carlos =?iso-8859-1?Q?Garc=EDa?= del Monte <cg...@wo...>
To: dev-cpp-users-list <dev...@li...>
Subject: Re: [Dev-C++] Compiling wxWindows 2.2.9 samples with Dev-C++
4.9.6.6

Not find wx/msw/file is because in Dev you have to write the full path o =
the file.
But is better compile in command line through make.
Write a makefile
CPPFLAGS=3D
and such options
TARGET=3Dnameofyour application

OBJECTS=3Dobject1.o object2.o

include $(WXDIR)/src/makeprog.g95

Inside the IDE you'll never compile a wxwindows project

Luc Saint-Elie escribi=F3:

> Hello,
>
> Is there somewhere a tutorial on how to set up Dev-C++ to compile sampl=
es
> bundled with wxWindows 2.2.9 (added to Dev-C++ using the package system=
).
> I' fail to compile them using a standard "new project".
> There are a lot of things missing even trial one (for example
> "wx/msw/hand.cur" event if I try to add the path, in my case
> D:\Dev-Cpp\include\wx\msw , in the project options).
>
> On the other hand, a brand new basic wxWindows app compiles without any=
 problem
>
> Luc
>
> -------------------------------------------------------
> 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-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


End of Dev-cpp-users Digest