🚀 go-pugleaf

"fwang11" <fwang11@pub3.fz.fj.cn> writes:

> BCB use 
> extern PACKAGE TForm *Form;
> for object declaration.
>
> This is non object oriented C style declaration. 
> Why not declare the object within C++ class?    

Which class would you propose to embed it in?  How would that improve
anything? 

Does it really matter?

-- 
Chris (TeamB);

Chris Uzdavinis (TeamB) <chris@uzdavinis.com> wrote:
>"fwang11" <fwang11@pub3.fz.fj.cn> writes:
>
>> BCB use 
>> extern PACKAGE TForm *Form;
>> for object declaration.
>>
>> This is non object oriented C style declaration. 
>> Why not declare the object within C++ class?    
>
>Which class would you propose to embed it in?  

could embed it in another class, eg  

class TForm1: public TForm
{
      private: 
        TForm2 *Form2; 
}


>How would that improve
>anything? 
>
>Does it really matter?
>
>-- 
>Chris (TeamB);

To make it pure C++ instead of mix C and C++.

Feng

fwang11 wrote:


> could embed it in another class, eg  
> 
> class TForm1: public TForm
> {
>       private: 
>         TForm2 *Form2; 
> }

What does this achieve?
In what way is this a 'better' design than the BCB default?


> To make it pure C++ instead of mix C and C++.

I'm not sure what 'pure' C++ is.
I can write a lot of C++ that looks nothing like 'C' and still uses no
classes.  C++ is a 'multi-paradigm' lanaguage, and OO is only one of
them.

Many leading C++ advocates (including some on the ISO comittee) now
believe 'free functions' (i.e. non-member functions) give better
encapsulation than member functions (i.e. better OO) and are more
re-usable in generic code.  Would you also dismiss this as writing 'C'
rather than 'C++'.


For the record though, the only global form variable I use is that of
the main form.  I routinely remove all the others from my source.  Just
because BCB automatically generates them for me does not mean I need to
use them!

However, 'quick and dirty' projects (often prototypes) may be developed
that little bit quicker by cutting such corners, and that is one of the
key markets for BCB, and RAD in general.

AlisdairM(TeamB)

"fwang11" <fwang11@pub3.fz.fj.cn> writes:

>>Which class would you propose to embed it in?  
>
> could embed it in another class, eg  
>
> class TForm1: public TForm
> {
>       private: 
>         TForm2 *Form2; 
> }

That's fine and all, but you still have to have an instance of TForm1
before you can access the pointer to Form2.  If Form2 really depends
on having a Form1 already made, then write your code exactly like you
have it above, and take form2 out of the auto-creation list.

>>Does it really matter?
>
> To make it pure C++ instead of mix C and C++.

First, how is this C instead of C++?

Second, what is wrong with C (even if this were C?)

Third, why is this better?


Making Form2 be a member of Form1 is a fine design idea, and you're
free to do it.  But the auto-created forms (created by starting your
application, without any code by you needing to be written) are
implemented with a global variable.  If you move form2 into form1,
then you're changing the meaning of your program.  Before, form2 was
created by the generated code at program startup.  Your proposal makes
it that form2 isn't created until sometime after form1 is created, and
you have to write (by hand) the code to create the object and
initialize the Form2 pointer that is inside form1.

Both are valid designs that accomplish different things.


-- 
Chris (TeamB);

I always looked at it as a convenience thing.  You're not going to have
*that* many forms in any given project.  Also, by their nature it is fairly
easy to give them unique names so they don't really pollute the global
namespace. Or you could leave the plain TFormN form, but for projects of
more than 2 or 3 forms it aides understanding to give them meaningful names.

But for convenience with auto-create forms it is easy to wire them together
by simply including a header and knowing that you've got the global pointer
to the instance.  Also, as created by the IDE, each form is a global
resource, so a global pointer to the instance is appropriate IMHO.  If
you're going to dynamically create and own forms, then by all means, own
them in the appropriate scope...