Thread: Re: [Dev-C++] can't get dev-cpp to compile...
Open Source C & C++ IDE for Windows
Brought to you by:
claplace
Menu
▾
▴
dev-cpp-users
|
From: P.T. W. M. <pt...@ea...> - 2004-01-17 00:04:31
|
C++ has changed, and no longer uses the old style headers. Use: #include <iostream> using namespace std; ".h" is nolonger used. Patrick At 15:04 16-01-04, Kovalan Muniandy wrote: >Hi, > >I have just installed Dec-C++ on my Windows XP laptop. However, I can't >get to compile the project "Hello World". The compiler complains that >"iostream.h" is not found. > >I have tried looking into the Compiler options to make sure the include >directories are good, and they appear to be. Initially, it had c:\dev-_1~ >or something like that but I have reinstalled Dev-C++ in a eight width >friendly file folder called c:\devcpp\. So, the include directories point >to c:\devcpp\Include\G++;c:\devcpp\Include. The iostream.h is in the G++ >folder. > >What else could be wrong? > >Kovalan |
|
From: Kovalan M. <kov...@fu...> - 2004-01-17 17:18:51
|
<FONT face=3D"Default Sans Serif, Verdana, Arial, Helvetica, sans-serif" si= ze=3D2><DIV>Thank you! That's interesting. Does this apply to STL clas= ses only or any headers, i.e. can you reference any header files without th= e ".h".<BR></DIV><DIV>The code was generated by Dev-C++ (The project wizard= "Hello World"). I guess that's a bug.</DIV><DIV> </DIV><DIV>Kovalan</= DIV><DIV> </DIV><FONT color=3D#990099>-----dev-cpp-users-admin@lists.s= ourceforge.net wrote: -----<BR><BR></FONT>To: Kovalan Muniandy <kovalan.= mun...@fu...>, dev...@li...<BR>From: "P.T= . Waugh MA" <pt...@ea...><BR>Sent by: dev-cpp-users-admin@l= ists.sourceforge.net<BR>Date: 01/16/2004 07:03PM<BR>Subject: Re: [Dev-C++] = can't get dev-cpp to compile...<BR><BR>C++ has changed, and no longer uses = the old style headers. Use:<br><br>#include <iostream><br>using = namespace std;<br><br>".h" is nolonger used.<br><br>Patrick<br><br>At 15:04= 16-01-04, Kovalan Muniandy wrote:<br><br><blockquote type=3D"cite" class= =3Dcite cite=3D"">Hi,<font size=3D4> </font><br><br>I have just installed D= ec-C++ on my Windows XP laptop. However, I can'tget to compile the project = "Hello World". The compilercomplains that "iostream.h" is not found. <br><b= r>I have tried looking into the Compiler options to make sure the includedi= rectories are good, and they appear to be. Initially, it had c:\dev-=5F1~or= something like that but I have reinstalled Dev-C++ in a eight widthfriendl= y file folder called c:\devcpp\. So, the include directories pointto c:\dev= cpp\Include\G++;c:\devcpp\Include. The iostream.h is in the G++folder.<font= size=3D4> </font><br><br>What else could be wrong?<font size=3D4> </font><= br><br>Kovalan<font size=3D4> </font></blockquote></FONT>= |
|
From: <or...@vp...> - 2004-01-17 18:10:11
|
Kovalan Muniandy wrote: > Thank you! That's interesting. Does this apply to STL classes only or > any headers, i.e. can you reference any header files without the ".h". > The code was generated by Dev-C++ (The project wizard "Hello World"). I > guess that's a bug. Only applies to C++ headers - it is a standard. The C standard library is still (as always) has .h extensions (stdio.h, etc.). BTW, it indeed is a bug. Dev-C++ has quite old project templates. And that would the smaller problem, but there are bigger ones. The usage of MinGW (the compiler beneath Dev-C++) is still used in a very obsolete fashion: Dev-C++ still uses dllwrap for example for DLL compilaton, but GCC (MinGW) strongly reccomends using "g++ -shared" for compiling DLLs. I don't know why aren't they updating this. With GCC 3.4, we "will" have header precompilation, but I don't when Dev-C++ is going to recognise it. Maybe 2-3 years after MinGW Gcc 3.4 release... -- Greetings, Balázs |
|
From: * W. <wi...@fu...> - 2004-01-17 19:41:54
|
Hello 'world' ...
Comments below ..
----- Original Message -----=20
From: OROSZI Bal=E1zs
Sent: Sunday, January 18, 2004 5:13 AM
Kovalan Muniandy wrote:
K>> ... The code was generated by Dev-C++ (The project wizard "Hello
World"). I
K>> guess that's a bug.
B> Only applies to C++ headers - it is a standard. The C standard library
B> BTW, it indeed is a bug. Dev-C++ has quite old project templates. And
B> that would the smaller problem, but there are bigger ones. The usage o=
f
B> MinGW (the compiler beneath Dev-C++) is still used in a very obsolete
Yes, and at the same time, I think it is unfair to 'expect' on the Dev-CP=
P
team to keep abrest of every subtle change or update in the compilers. C
and C++ is a tool for people who will one day 'know' what their code does
and does not do (I am allowing for learners too, you see... *smile*).
I also thing there is something that can be DONE to redress the catch-up
process between Dev-CPP and an innovation in the compiler, or verily, any
other 'tool' or library.
Some of this I've discovered it is possible to do by hand, and yes it is
related to the templates (.devpacks), which means ALL of us can develop
better "Dev-CPP structures" and directory hierachies, to support changed =
in
the underlying tools. (Me too ...oops).
The compiler is a brilliant example. The 4.9.8.5 Dev-CPP uses
gcc.exe (GCC) 3.2 (mingw special 20020817-1)
compiler. It is installed 'under' the Dev-cpp folder hierachy. As
(visual)
./dev-cpp/bin/gcc.exe
/include
/lib
While this all makes sense if one is using only one compiler, and
environment say as I might with a microsoft(r) product. Does it make sen=
se
in the Dev-cpp world. I recently grabbed the mingw 3.3 compiler suite.
gcc.exe (GCC) 3.3.1 (mingw special 20030804-1)
And I placed it as a seperate hierachy so I can have different versions o=
f
the same tool placed so I can use the compiler of choice. For example;
./dev-cpp/bin (same, left it alo=
ne)
./mingw32/3.2/bin/gcc.exe
/include
/lib
./mingw32/3.3/bin/gcc.exe
/include
/lib
./wxWindows/ ......
Please note, my example of wxWindows... I can't "enforce" this on people,=
it
is simply something I think will work better for me. I have found occasi=
ons
when moving to a new version causes problems. If I can alter the path to
point to a different configuration, and go backwards or forwards that is =
a
good thing.
It is also set up this way because Dev-cpp is not always the only tool to
use these directories and I don't want to point makefiles into a 'product
specific' folder layout. In make, I cna use relative path references.
"../../here" and macros "$(WXSTUB)/include"... Hey it gets creative.
The consisitient point is by changing ONE folder (parameter) for a make, =
I
can build with a beta or a stable release, or old release. Because there=
is
a consistiency and anyone can setup their directories this way by hand.
So much the better imho, if the DevPack templates WE makeup started to
'think' like this. And the 'think' is probably why things are as they ar=
e.
At some point there would need to be a 'consistient agreed scheme' so tha=
t
might work.
Something deep and challenging and complex like a "dev-cpp.config" file
perhaps ?
It could look like:
[wxWindows] // peer tool
path: $(package)/wxWindows
[mingw32] // peer tool
path: $(package)/mingw32/$(ver)/
[winmerge] // peer tool
path: $(tool)/winmerge/
[cvs] // peer tool
path: $(tool)/cvs/
Where $ver is the user designation (folder name) or null for that version.
An empty $(ver) might be the default compiler, wxWindows, resource editor=
,
etc
And the macro: "$(package)" is a folder path where these toys 'go to'.
The other thing is sometimes, there are tools already in place, that I ca=
n't
"just move" because that might mean changing other bits and pieces. I'm
pointing out user-supportive concepts. It is rare for most people to hav=
e
to work where I can make No assumptions about the deployed-configuration =
for
software. That is changing. OSS means plug-n-play together. So think
flexible folks...
That's a 15 min write-up. It seems to me that 'chaotic' tool use and
placement forces people into two modes. First is a supportive mode where
everything goes HERE. Second is a spend a few days (hours then) configur=
ing
where things go... do-it-yourself.
A few macros, with default values and using relative paths can offer a
median path between flexibility and utility. To its credit, DevCPP allow=
s
me to set-up my folders how I wish. It is the way DevPacks and tempelate=
s
are organised that stop it being 'as valuable' as it might be. Or to be
fair, it is the way it began and has not been looked at ...
As the 'customers' and 'users' of dev cpp we could begin consensus for
peer/external (to dev cpp) tools and add-ins. It isn't the dev cpp's
business if you need to use mingw v2.x, but if you upgrade dev cpp, it mi=
ght
break your project by up-dating the compier.... oopz.
What I can not find so far is where the Dev CPP defaults are maintained. =
I
would hope they are in some resouce and not compiled Into dev cpp ???
Aloha,
William
|
|
From: RUDOLPH B. <ku...@sp...> - 2004-01-19 00:15:43
|
BRAVO BRAVO
WELL WRITTEN
----- Original Message -----
From: "* William" <wi...@fu...>
To: "dev c++" <dev...@li...>
Sent: Saturday, January 17, 2004 7:41 PM
Subject: Re: [Dev-C++] can't get dev-cpp to compile...
Hello 'world' ...
Comments below ..
----- Original Message -----
From: OROSZI Bal=E1zs
Sent: Sunday, January 18, 2004 5:13 AM
Kovalan Muniandy wrote:
K>> ... The code was generated by Dev-C++ (The project wizard "Hello
World"). I
K>> guess that's a bug.
B> Only applies to C++ headers - it is a standard. The C standard library
B> BTW, it indeed is a bug. Dev-C++ has quite old project templates. And
B> that would the smaller problem, but there are bigger ones. The usage o=
f
B> MinGW (the compiler beneath Dev-C++) is still used in a very obsolete
Yes, and at the same time, I think it is unfair to 'expect' on the Dev-CP=
P
team to keep abrest of every subtle change or update in the compilers. C
and C++ is a tool for people who will one day 'know' what their code does
and does not do (I am allowing for learners too, you see... *smile*).
I also thing there is something that can be DONE to redress the catch-up
process between Dev-CPP and an innovation in the compiler, or verily, any
other 'tool' or library.
Some of this I've discovered it is possible to do by hand, and yes it is
related to the templates (.devpacks), which means ALL of us can develop
better "Dev-CPP structures" and directory hierachies, to support changed =
in
the underlying tools. (Me too ...oops).
The compiler is a brilliant example. The 4.9.8.5 Dev-CPP uses
gcc.exe (GCC) 3.2 (mingw special 20020817-1)
compiler. It is installed 'under' the Dev-cpp folder hierachy. As
(visual)
./dev-cpp/bin/gcc.exe
/include
/lib
While this all makes sense if one is using only one compiler, and
environment say as I might with a microsoft(r) product. Does it make sen=
se
in the Dev-cpp world. I recently grabbed the mingw 3.3 compiler suite.
gcc.exe (GCC) 3.3.1 (mingw special 20030804-1)
And I placed it as a seperate hierachy so I can have different versions o=
f
the same tool placed so I can use the compiler of choice. For example;
./dev-cpp/bin (same, left it alo=
ne)
./mingw32/3.2/bin/gcc.exe
/include
/lib
./mingw32/3.3/bin/gcc.exe
/include
/lib
./wxWindows/ ......
Please note, my example of wxWindows... I can't "enforce" this on people,=
it
is simply something I think will work better for me. I have found occasi=
ons
when moving to a new version causes problems. If I can alter the path to
point to a different configuration, and go backwards or forwards that is =
a
good thing.
It is also set up this way because Dev-cpp is not always the only tool to
use these directories and I don't want to point makefiles into a 'product
specific' folder layout. In make, I cna use relative path references.
"../../here" and macros "$(WXSTUB)/include"... Hey it gets creative.
The consisitient point is by changing ONE folder (parameter) for a make, =
I
can build with a beta or a stable release, or old release. Because there=
is
a consistiency and anyone can setup their directories this way by hand.
So much the better imho, if the DevPack templates WE makeup started to
'think' like this. And the 'think' is probably why things are as they ar=
e.
At some point there would need to be a 'consistient agreed scheme' so tha=
t
might work.
Something deep and challenging and complex like a "dev-cpp.config" file
perhaps ?
It could look like:
[wxWindows] // peer tool
path: $(package)/wxWindows
[mingw32] // peer tool
path: $(package)/mingw32/$(ver)/
[winmerge] // peer tool
path: $(tool)/winmerge/
[cvs] // peer tool
path: $(tool)/cvs/
Where $ver is the user designation (folder name) or null for that version.
An empty $(ver) might be the default compiler, wxWindows, resource editor=
,
etc
And the macro: "$(package)" is a folder path where these toys 'go to'.
The other thing is sometimes, there are tools already in place, that I ca=
n't
"just move" because that might mean changing other bits and pieces. I'm
pointing out user-supportive concepts. It is rare for most people to hav=
e
to work where I can make No assumptions about the deployed-configuration =
for
software. That is changing. OSS means plug-n-play together. So think
flexible folks...
That's a 15 min write-up. It seems to me that 'chaotic' tool use and
placement forces people into two modes. First is a supportive mode where
everything goes HERE. Second is a spend a few days (hours then) configur=
ing
where things go... do-it-yourself.
A few macros, with default values and using relative paths can offer a
median path between flexibility and utility. To its credit, DevCPP allow=
s
me to set-up my folders how I wish. It is the way DevPacks and tempelate=
s
are organised that stop it being 'as valuable' as it might be. Or to be
fair, it is the way it began and has not been looked at ...
As the 'customers' and 'users' of dev cpp we could begin consensus for
peer/external (to dev cpp) tools and add-ins. It isn't the dev cpp's
business if you need to use mingw v2.x, but if you upgrade dev cpp, it mi=
ght
break your project by up-dating the compier.... oopz.
What I can not find so far is where the Dev CPP defaults are maintained. =
I
would hope they are in some resouce and not compiled Into dev cpp ???
Aloha,
William
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Dev-cpp-users mailing list
Dev...@li...
TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
|
