dev-cpp-users Mailing List for Dev-C++

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

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

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

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

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

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

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/

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

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

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
> 

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
> 

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

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



Ioannis

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

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



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




> 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

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

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

/Per W

On Wed, 30 Oct 2002, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: Per Westermark [mailto:pw...@ia...] 
> > Sent: Wednesday, October 30, 2002 2:11 PM
> > To: Marc Heiligers
> > Cc: Ioannis Vranos; Dev-C++ Mailing List
> > Subject: RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> > 
> > 
> > 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.
> 
> 
> It's a syntax matter. As far as i can guess Fortran implementation is
> not required to store them in that order.
> 
> 
> 
> > 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.
> 
> Why?
> 
> > The mathematical world decided that C was a slower language 
> > :-) 
> 
> 
> Well, one of the reasons that Fortran is fast is because it is heavily
> optimised during those years and not because its syntax is close to the
> metal. Now this doesn't apply anymore.
> 
> Check the following: 
> 
> http://csweb1.cs.tamu.edu/seminars/dlecture/abstracts/stroustrup.MPP-sli
> des.pdf
Very good document. Exactly my point. A language is efficient when it is
used in the correct way. One interesting note.
On page 7, the "bumpines" of the curves clearly display how the different
algorithms and compiler optimization has managed to optimize the memory
accesses.

> 
> 
> where it has the graphh with the title "Uncompromising Performance".
> 
> 
> 
> > 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.
> 
> 
> Yes there are indeed.
> 
> 
> Btw, Fortran has the notion of pointers?
Call by reference is an important concept, and one where the index order
is significant, if you only send a reference to a part of a larger matrix.
> 
> 
> 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
> 

> -----Original Message-----
> From: Per Westermark [mailto:pw...@ia...] 
> Sent: Wednesday, October 30, 2002 2:11 PM
> To: Marc Heiligers
> Cc: Ioannis Vranos; Dev-C++ Mailing List
> Subject: RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> 
> 
> 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.


It's a syntax matter. As far as i can guess Fortran implementation is
not required to store them in that order.



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

Why?

> The mathematical world decided that C was a slower language 
> :-) 


Well, one of the reasons that Fortran is fast is because it is heavily
optimised during those years and not because its syntax is close to the
metal. Now this doesn't apply anymore.

Check the following: 

http://csweb1.cs.tamu.edu/seminars/dlecture/abstracts/stroustrup.MPP-sli
des.pdf


where it has the graphh with the title "Uncompromising Performance".



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


Yes there are indeed.


Btw, Fortran has the notion of pointers?


Ioannis

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

weren't there also issues on some platforms with ordering of arguments to
functions on the stack ... and issues with semantics on how stuff got popped
off the stack when the call returned ?

"PASCAL calling convention" semantics ?

I thought maybe this same set of issues applied to COBOL and FORTRAN libs as
well.

Tony

--- Marc Heiligers <ma...@e-...> 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


=====

Thanks to everyone who responded to my question about mixed language
programming (particularly to Horst for the references).  Persistence has
paid off!  For the record . .

Turns out Dev-Cpp works quite nicely with mixing Fortran and C.  At compile,
gcc implicitly invokes g77 for any Fortran source files and the resulting
object files are linked without a problem; So including Fortran source files
in a Dev-Cpp project appears to be seamless.

Actually using the Fortran subroutines takes a little more work.  First, the
Mingw libraries libg2c and libm must be linked, i.e., Project Options :
Linker Options : -lg2c -lm (in that order!).  Next, the Mingw header file
g2c.h must be included in any C source file that will call C.

libg2c and g2c.h are gcc's versions of f2c.  However, as near as I can tell,
this isn't an f2c operation (translating Fortran to C then compiling from C
source), rather, the Fortran source files are compiled with g77 and so
retain the native efficiencies of their Fortran implementation; the library
and header files merely provide the interface for C.

Prototyping the Fortran subroutines is a little tricky but I found a use for
f2c after all!  When used with the -P switch, it produces a file with
subroutine prototypes to be used in C.

After that, it took some trial & error to figure out how to correctly
declare & pass the variables from C.  Biggest problem I had was with the C
function passed to and called from the Fortran routines (using their own
internally declared variables).  Essentially I had to create a shell of the
C routine to be called by the Fortran routines where I adjusted array
indexing and then call the real C routine.

Hope that is helpful anyone else interested in the issue.  Thanks again for
the feedback.

Scott

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

Hello all!

Sorry for being such a newbie but...  I get the following link error trying
to use the "splash" routine for displaying a splash screen on my first
WxWindows project.

Can anyone help here?

[Linker error] undefined reference to
`wxSplashScreen::wxSplashScreen(wxBitmap const &, long, int, wxWindow *,
int, wxPoint const &, wxSize const &, long)'

Thanks!

Mark

When compiling wxWindows applications, you want to point out the path
D:\Dev-Cpp\include
and whenever you include something, you write
#include <wx/some_file.h>

You should never every reference nto the xxx\include\wx\msw directory.
That directory is only for use by the wxWindows code. All includes you
should use are in the parent directory.

/Per W

On Wed, 30 Oct 2002, Luc Saint-Elie wrote:

> Hello,
> 
> Is there somewhere a tutorial on how to set up Dev-C++ to compile samples 
> 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
> 

Hello,

Is there somewhere a tutorial on how to set up Dev-C++ to compile samples 
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

Hi everybody

Long time ago (1994)  I worked in a simulation program using Borland C++ 3=
.1 and 
Microsoft Fortran 5.1.

The way I found to work fine was making a windows DLL from the Fortran cod=
e (with 
Microsoft Fortran was possible) and using the DLL in a standard way from m=
y C++ 
code.

I don=B4t know if it=B4s possible with gnu Fortran compiler to make a DLL,=
 but if you can=B4t 
do it, you will have some problems with the function calling beteween C an=
d Fortran, 
the byte ordering, etc.

If you need some other help I will review my program because I don=B4t rem=
ember the 
details

Roger

Send reply to:  	<se...@al...>
From:           	"Scott Williams" <se...@al...>
To:             	"Dev-Cpp-Users@Lists. Sourceforge. Net" <dev-cpp-
us...@li...>
Subject:        	[Dev-C++] Mixed Language Programming w/Dev-Cpp
Date sent:      	Tue, 29 Oct 2002 15:33:56 -0500

> 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?
> 
> BTW, I've tried f2c but have been unable to make that work.  That
> approach is suboptimal anyway because the resulting C code is far less
> efficient than the original Fortran source.
> 
> Perhaps specifics would help.  The fortran code I'm trying to use is a
> single file ode.f  The entry point is the subroutine ode.  Here's how
> the file is laid out:
> 
> // ode.f
> 
>       subroutine ode(f,neqn,y,t,tout,relerr,abserr,iflag,work,iwork)
>       implicit real*8(a-h,o-z)
> 
> c      f -- double precision subroutine f(t,y,yp) to evaluate
> c                derivatives yp(i)=3Ddy(i)/dt
> c      neqn -- number of equations to be integrated (integer*4)
> c      y(*) -- solution vector at t                 (real*8)
> c      t -- independent variable                    (real*8)
> c      tout -- point at which solution is desired   (real*8)
> c      relerr,abserr -- relative and absolute error tolerances for
> local c           error test (real*8).  at each step the code requires
> c             dabs(local error) .le. dabs(y)*relerr + abserr c        
>   for each component of the local error and solution vectors c     
> iflag -- indicates status of integration     (integer*4) c     
> work(*)  (real*8)  -- arrays to hold information internal to c     
> iwork(*) (integer*4)    which is necessary for subsequent calls
> 
> . . . ode calls de:
>       subroutine de(f,neqn,y,t,tout,relerr,abserr,iflag,
>      1  yy,wt,p,yp,ypout,phi,alpha,beta,sig,v,w,g,phase1,psi,x,h,hold,
>      2  start,told,delsgn,ns,nornd,k,kold,isnold)
>       implicit real*8(a-h,o-z)
> 
> . . . de calls step & intrp:
>       subroutine step(x,y,f,neqn,h,eps,wt,start,
>      1  hold,k,kold,crash,phi,p,yp,psi,
>      2  alpha,beta,sig,v,w,g,phase1,ns,nornd)
>       implicit real*8(a-h,o-z)
> 
>       subroutine intrp(x,y,xout,yout,ypout,neqn,kold,phi,psi)
>       implicit real*8(a-h,o-z)
> // end ode.f
> 
> The derivative function f is written in C (and that's where I was
> having probs with the f2c route).
> 
> All help is appreciated (sorry for the long post).
> 
> Scott
> 
> 
> 
> -------------------------------------------------------
> 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

> How easy is it to write code to monitor ports? Say you wanted to watch
what
> was happening at port 80 (which is where http packets are retrieved
> (correct?)) would it be easy for an intermediate programmer? Would it
> require many hours of work? Could you set up a text file to store activity
> and then look at it after?
>
> I've not done anyhting like this before so any advice would be great. I'm
> just interested to know that's all.

Greets, Daniel.

You want to use WinSock (sockets in Unix), google for "socket programming
tutorial" or something. There's a good one called `Beej's Guide to Network
Programming'. What you want to do is pretty simple, not much code required.

___________________________________________________________

Abhijit Shylanath

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

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