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