Wow.... slow down.....



1) the suggestion was a good one, and I doubt any one on this list has
NOT read that book at some point or another. It is the bible of C. I
have the second edition re-print myself.



2) I too was going to make the same suggestions. 

2.1) Global variables are in bad in general, but they do have some (very 
limited) uses these days.

2.2) There is probably a memory leak somewhere. Where the structure of
the application (the compiled code) puts that pointer outside the reach
of the overflow so when you re-wrote it, it magically worked (voodoo appearing 
indeed). 

2.3) Demo applications are just that, they can have plenty of errors in
them, and mostly do NOT have proper initialization / freeing of
objects. 



The reality is that I have many times thought there was something wrong
with the library that turned out to be my own strange ways of doing it,
and there have been plenty of times, where bad programming (my own) has
lead me down the wrong path. So I would at least entertain the idea
that this may be something along those lines, before pointing the
finger at a tested library widget.



As for why global variables are bad is WAY outside the scope of
this email list. Without getting into the detail to much, just think of these
questions two questions. 

1) When a variable is declared global, where in the program code (the assembly 
code / byte structure if you will) does it lie, 

2) and durring CPU operations on that code, where would that assembly code 
reside in the CPU physical locations? 



If you answer those to questions correctly you will find one reason
(not all), why global variables are bad, not to mention that the
probability of corruption leaking to other global variables being high.



Good luck,


> Date: Thu, 10 Jun 2010 18:39:30 +0200
> To: y...@physics.muni.cz
> From: mys...@seznam.cz
> Subject: Re: GTK Widget assertion problem
> CC: gtk-app-devel-list@gnome.org
> 
> Hi,
> > 
> > Hello, this all looks like utter voodoo.  
> 
> Yes it does. I tried 10 other ways and they didn't work. This one works 
> perfectly (so far).
> > You have probably a trivial
> > bug somewhere (elsewhere) in your code, maybe some
> > extern/static/initialization confusion? 
> 
> All initialization was shown in the previous examples. All my initializations 
> are taken directly from the GTK+ documentation and I never had one problem. 
> More people have been developing this very same application and there was no 
> problem until I needed to work with the progress bar widget.
> There is no static identifier used because it is not needed. The extern 
> identifier is used only, when the widget is accessed from other files which 
> is precisely what this identifier was designed for.
> 
> >  Or you overwrite the stack and
> > calling progressBarHack() causes a change of the layout so that you
> > overwrite a less sensitive place now?  
> 
> progressBarHack() does nothing with the layout. All it does is a proper 
> initialization of the global variable which should work without the hack, but 
> doesn't. 
> 
> > Anyway, it is recommended fix to
> > avoid global variables, they are evil, and externs are double-evil. 
> 
> Why? I've personally read the first book on C called The C programming 
> language from 1978 written by the inventor of the language and using global 
> variables is explained there as a proper way to implement things. I wonder 
> what is the source of the 'evil global variables' legend, but if I'm wrong, 
> please correct me. The extern identifier is just a way to access the global 
> variable from a different file. I don't see why it should be a double-evil.
> 
> > But
> > perhaps if you show a minimal *complete* example that exhibits the error
> > some will be able to help you.  Or, likely, you will find the root cause
> > while trying to extract the bad behaviour into a simple example...
> 
> I tried to do so in my first email (not the one you responded to). I also 
> mentioned that I use several widgets as global variables because I need to 
> access them from multiple functions. Hence, callbacks are not sufficient, in 
> my opinion.
> There was never one problem with using widgets as global variables and the 
> application uses a lot of them. That's why I think there's a problem 
> particularly with the Progress bar widget. 
> My hack just initializes the global variable properly, all it does is 
> re-initializing the global variable outside the current function stack.
> 
> Anywayz, a another simple example:
> 
> // global variables
> GtkWidget *combobox;
> GtkWidget *textField; 
> GtkWidget *progBar;
> 
> GtkWidget* create_main_window (void)
> {
>     .... //necessary window initializations, vertical boxes, tables etc.
> 
>    combobox = gtk_combo_box_new_text();
>    
>       gtk_combo_box_append_text(GTK_COMBO_BOX (combobox), (const char*) 
> "U/t");
>       gtk_combo_box_append_text(GTK_COMBO_BOX (combobox), (const char*) 
> "Q/t");
>       gtk_combo_box_set_active(GTK_COMBO_BOX (combobox), 0);
> 
>       gtk_widget_show(combobox);
>       gtk_box_pack_start (GTK_BOX (vbox3), combobox, FALSE, FALSE, 0);
> 
>    textField = gtk_text_view_new ();
>       gtk_widget_show (textField);    
>       gtk_table_attach_defaults(table, textField, 3, 5, 0, 1);
> 
>    progBar = gtk_progress_bar_new();  
>      gtk_box_pack_start (GTK_BOX (vboxGr), GTK_PROGRESS_BAR(progBar), FALSE, 
> FALSE, 0);
>      gtk_widget_show (progBar);
>   
>    // progressBarHack(progBar);
> 
>    ...
> }
> 
> All the widgets are used as global variables due to reasons I have explained. 
> All of them work perfectly and can be accessed from various functions except 
> the progress bar widget. With the hack, progress bar works perfectly, too. 
> There are about twenty or more widgets in the application that are used the 
> same way - as global variables, there's never been one single problem.
> 
> Please correct me, if I'm wrong anywhere.
> 
> Thanks,
> 
> Michael
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
                                          
_________________________________________________________________
Hotmail is redefining busy with tools for the New Busy. Get more from your 
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Reply via email to