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

What is the function to generate a random number?

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*   
http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=https%3a%2f%2f2.zoppoz.workers.dev%3a443%2fhttp%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca

                                               (I hope this doesn't get =
repeated)
Hi folks

Hope you are well out there.  Happy 2004...   I thought this was a =
simple
point to resolve.  However, it turns out to be very dev-cpp specific.

I want the 'equivalent' or either

   <netinet/in.h>                  ... or ...
   <in.h>

I have found <wininet.h> in the folder.  Can someone point me to =
documentation on this file please ?  (Oh yes the context is from a gawk =
project. )

Your help is much appreciated.

Aloha,
              William

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

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

<FONT face=3D"Default Sans Serif, Verdana, Arial, Helvetica, sans-serif" si=
ze=3D2><DIV>Thank you!&nbsp;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>&nbsp;</DIV><DIV>Kovalan</=
DIV><DIV>&nbsp;</DIV><FONT color=3D#990099>-----dev-cpp-users-admin@lists.s=
ourceforge.net wrote: -----<BR><BR></FONT>To: Kovalan Muniandy &lt;kovalan.=
mun...@fu...&gt;, dev...@li...<BR>From: "P.T=
. Waugh MA" &lt;pt...@ea...&gt;<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.&nbsp;Use:<br><br>#include &lt;iostream&gt;<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>=

Ok just about every developer knows about background processes. Under
any *NIX they are pretty easy to create. Under Windows NT (including
2000/XP) there exist tons of tutorials that explain how to create
them. 

My question is does anyone know about creating such processes under
Windows9x? I would rather not have to go to creating a VxD. 

Essentially I am creating a number cruncher which has just about no
output (problems/results are in files) and require no input from the
user. Right now I have a console application that can be killed using
<CTRL-C> or <CTRL-BREAK> at which point it saves where it was and
performs a graceful shutdown. Upon starting back up it reads the
checkpoint file and starts back where it left off.

Any help would be appreciated.
David McKen

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

What I have here is a very simple FLTK program, all it is supposed to do 
is to create a window with a tab in it.
It compiles fine, but when it is executed MSW98 OS pops up a dialog box 
that reads: "This program has performed an illegal operation and will be 
shut down ....",
What am I doing wrong? but most importantly, how do I fix it?
#ifndef NEW_ACCOUNT_DLG_H
#define NEW_ACCOUNT_DLG_H

#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Double_Window.H>
#include <FL/Fl_Tabs.H>

#include <iostream>

namespace jme{
   class NewAccountDlg : public Fl_Double_Window{
      private:
         Fl_Tabs* box;

      public:
         NewAccountDlg();
         virtual ~NewAccountDlg();
         void setWindow();
   }; //NewAccount
}
#endif

#ifndef NEW_ACCOUNT_DLG_H
   #include "NewAccountDlg.H"
#endif
jme::NewAccountDlg::NewAccountDlg()
: Fl_Double_Window(10,10,300,200,"Maya"){
  try{ box = new Fl_Tabs(10,10,360,260,"Tab 1"); }
  catch(std::bad_alloc& x){std::cout << x.what() << std::endl;}
}

void jme::NewAccountDlg::setWindow(){
   box->box(FL_UP_BOX);
   box->labelsize(36);
   box->labelfont(FL_BOLD+FL_ITALIC);
   box->labeltype(FL_SHADOW_LABEL);
}
jme::NewAccountDlg::~NewAccountDlg(){}

#include "NewAccountDlg.H"
#include <iostream>

int main ()
{
   jme::NewAccountDlg* ndd;
   ndd->begin();
   ndd->setWindow();
   ndd->end();
   ndd->show();
   std::cin.get();

    return Fl::run();
}

-- 

FYI
http://www.astro.umd.edu/~marshall/abbrev.html

E-Mail Policy
http://www.vif.com/users/escalante/Email_Policy.html

* You cannot exercise your power to a point of humiliation.
                               - Jean Chretien

* The media's the most powerful entity on earth. They have the 
  power to make the innocent guilty and to make the guilty 
  innocent, and that's power. 
                                - Malcom X
* "Innocent until proven guilty", no... not in Canada!!

One other drawback to idle functions is that they cannot take advantage of
a second CPU like a thread can.

On Fri, 16 Jan 2004, Daniel K. O. wrote:

> The idle funcs have low priority by default, your thread could call
> gtk_idle_add a million times, and if the GUI is still busy with other
> things, the idle funcs will wait.

True. This works. But its pretty old fashioned and not nearly as
responsive as doing the update in a seperate thread. Generally, this is
how we used to do things before Windows had preemptive multitasking.  But
now that we have preemptive multitasking, we don't like to use idle
methods anymore.

As an example, in Petzold's book, Programming Microsoft Windows (the Bible
on the Windows API), there is a program that draws random rectangles on
the screen as fast as the computer can draw them. The example uses the
PeekMessage function to only draw when the application is otherwise idle.
However, if you move the mouse cursor through the random rectangle frame,
it is noticably sluggish as the random rectangle loop runs between the
firing of mouse events.

Later in the book, the same program appears again, but this time using a
seperate thread to draw the rectangles. If you try both examples, I think
you find that the threaded version is more responsive than the version
that uses PeekMessage().



Then they all will run; or you can
> just change their priority, calling gtk_idle_add_full, giving them more
> priority, for example, depeinding what you want. I don't think you can
> freely define this behavior in a log of GUI toolkits.
>
>
> >Animation and VR simulations that require rapid repainting of the display
> >are another area where you often don't want to tie up the main thread by
> >forcing it to handle the paint requests and such. The application can
> >become extremely unresponsive if the main thread has to handle such paint
> >intensive tasks.
> >
>
> Yeah, this really seems a problem.
> But GTK+ isn't intended for intensive repainting, like VR and
> Animations. You can use something like GtkGLExt, or GtkSDL, or something
> else, and plug this extra widget into your application. To manipulate
> their content you won't need to use Gtk+ API calls, you'll use
> SDL_BlitSurface, glVertex, etc. They should work fine when running from
> another thread.
>
>
>
> Daniel K. O.
>
>
>
>
> -------------------------------------------------------
> 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
>

Michael C Urban wrote:

>Updating the GUI in the main thread can cause noticable delays in the user
>interface. The progress bar is a good example. If you update that from the
>main thread, then every time the main thread has to repaint the progress
>dialog, it's going to interrupt the user experience.
>  
>


I don't think repainting the progress bar could take more time than 
painting a label... the idea isn't to make all the job in the main 
thread, just use a function that receives one arg, and call something like:

---
gboolean my_idle_callback_that_updates_the_progress_bar()
{
    gdk_threads_enter(); /* idle funcs run outside the lock */

    /* my_val is set in the other thread, inside 
gdk_threads_enter()/leave(),
    so the gui is not updated ouside the main thread, no problem at all.
     Now the idle func just have to retrieve the value, and use it properly.
 */
    float pb =  (float)g_object_get_data(G_OBJECT(my_progress_bar), 
"my_val");  
   
    gtk_progress_bar_set_fraction(GTK_PROGRESS_BAR(my_progress_bar), pb);

    if (pb>0.99) { /* are we finished? lets make the GUI sensitive again */
       gtk_widget_set_sensitive(toplevel_window, TRUE);

       /* here we could also change some texts, show a message window, 
play some sound, etc */
    }
  
    gdk_threads_leave();
    return FALSE; /* run this idle func just once */
}
---


The idle funcs have low priority by default, your thread could call 
gtk_idle_add a million times, and if the GUI is still busy with other 
things, the idle funcs will wait. Then they all will run; or you can 
just change their priority, calling gtk_idle_add_full, giving them more 
priority, for example, depeinding what you want. I don't think you can 
freely define this behavior in a log of GUI toolkits.


>Animation and VR simulations that require rapid repainting of the display
>are another area where you often don't want to tie up the main thread by
>forcing it to handle the paint requests and such. The application can
>become extremely unresponsive if the main thread has to handle such paint
>intensive tasks.
>

Yeah, this really seems a problem.
But GTK+ isn't intended for intensive repainting, like VR and 
Animations. You can use something like GtkGLExt, or GtkSDL, or something 
else, and plug this extra widget into your application. To manipulate 
their content you won't need to use Gtk+ API calls, you'll use 
SDL_BlitSurface, glVertex, etc. They should work fine when running from 
another thread.



Daniel K. O.

<html><div style='background-color:'><DIV class=RTE>
<P><BR>This is found on the&nbsp; WinXP Pro CD or installed with VC6 as a "depends.exe" or go here:</P>
<P><A href="http://www.dependencywalker.com">http://www.dependencywalker.com</A><BR></P></DIV>
<DIV></DIV><mailto:dev...@li...?subject=unsubscribe><mailto:dev...@li...><mailto:dev...@li...?subject=help><mailto:dev...@li...?subject=subscribe>
<DIV></DIV></mailto:dev...@li...?subject=subscribe></mailto:dev...@li...?subject=help></mailto:dev...@li...></mailto:dev...@li...?subject=unsubscribe></div><br clear=all><hr>STOP MORE SPAM with <a href="http://g.msn.com/8HMBEN/2728??PS=">the new MSN 8</a> and get 2 months FREE*</html>

On Fri, 16 Jan 2004, Daniel K. O. wrote:

> I don't see it as a big problem. There aren't too much cases when you
> really NEED to update the gui outside the main thread.

Updating the GUI in the main thread can cause noticable delays in the user
interface. The progress bar is a good example. If you update that from the
main thread, then every time the main thread has to repaint the progress
dialog, it's going to interrupt the user experience.

Animation and VR simulations that require rapid repainting of the display
are another area where you often don't want to tie up the main thread by
forcing it to handle the paint requests and such. The application can
become extremely unresponsive if the main thread has to handle such paint
intensive tasks.

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