471,056 Members | 1,650 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,056 software developers and data experts.

Orcas C++ - still monolithic headers?

After reading the good news concerning STL/CLI in Orcas C++, the next
question is:

Does anybody know whether Orcas C++ still uses monolithic header files
containing all definitions and declarations, or will there be "real
header files" containing only declarations?

Richard
Oct 6 '06 #1
5 1373
R.Kaiser wrote:
Does anybody know whether Orcas C++ still uses monolithic header files
containing all definitions and declarations
Yes, monolithic header files in the Sep CTP.

Tom
Oct 6 '06 #2
"Tamas Demjen" <td*****@yahoo.comwrote in message
news:uU**************@TK2MSFTNGP04.phx.gbl...
R.Kaiser wrote:
>Does anybody know whether Orcas C++ still uses monolithic header files
containing all definitions and declarations

Yes, monolithic header files in the Sep CTP.
I assume you're talking about Windows Forms designer generated classes?

Personally, I wouldn't expect that to ever change - but who knows :) The
problem is, the designers are not maintained by the C++ team, so getting the
designer to support a separation of declaration/definition requires getting
another group to do work that's of no benefit to their own product.

-cd
Oct 6 '06 #3
Carl Daniel [VC++ MVP] schrieb:
"Tamas Demjen" <td*****@yahoo.comwrote in message
news:uU**************@TK2MSFTNGP04.phx.gbl...
>R.Kaiser wrote:
>>Does anybody know whether Orcas C++ still uses monolithic header files
containing all definitions and declarations
Yes, monolithic header files in the Sep CTP.

I assume you're talking about Windows Forms designer generated classes?
Yes.
Personally, I wouldn't expect that to ever change - but who knows :) The
problem is, the designers are not maintained by the C++ team, so getting the
designer to support a separation of declaration/definition requires getting
another group to do work that's of no benefit to their own product.
Somewhere (I can't remember where) I read of an announcement that future
versions of Visual C++ allow you to write classes that are split on
several source files, just like C# partial classes. If you split the
currently monolithic Forms class into one file with the declarations and
into another file with the definitions, these would be traditional
interface/implementation files.

Or did I get something wrong?

Thanks
Richard

-cd

Oct 6 '06 #4
Carl Daniel [VC++ MVP] wrote:
I assume you're talking about Windows Forms designer generated classes?
Yes, I assume that's what the original poster meant.
Personally, I wouldn't expect that to ever change - but who knows :) The
problem is, the designers are not maintained by the C++ team, so getting the
designer to support a separation of declaration/definition requires getting
another group to do work that's of no benefit to their own product.
I realize that, but C++/CLI is claimed to be the primary .NET language.
Changing the designer would obviously benfit Visual Studio as a whole.
Although I'm not sure what percentage of the developers design GUI in
C++/CLI.

Fortunately it's not too hard to move the event handler implementations
to the .cpp file, but it's a major inconvenience. I don't think it would
be too hard to implement that feature (to generate an entry to the
header file as well as the .cpp, as Borland C++Builder does it), and it
would save a lot of time to the developers. I really insist that event
handlers are implemented in the .cpp file.

Moving the InitializeComponent to the .cpp file is a little bit less
important. Yes, it's annoying that moving an edit box around triggers a
recompile to other units, but frankly, most changes to the form do.
Typically when the GUI changes it involves adding new controls, thus new
declarations. Let's face it, most designer changes would trigger a
recompile to other modules anyway.

It would still be appreciated if moving a component, or changing its
color, wouldn't trigger any changes to any header file. It still has
much less impact than the event handlers.

At least this issue with monolithic header files enforces developers to
consider the separation of the GUI from the business logic, which I
personally support even in smaller projects, except maybe in quick and
dirty prototypes. The rest of the application logic should not depend on
the implementation of a particular component. Let's say a year into the
development you change from list box to list view, or from a Microsoft
component to a 3rd party with a different interface. It's definitely not
nice if such a change requires the editing of 100 function calls and
property references all across the project. So it's probably safe to say
that if the designer's inability of maintaining a separate .cpp file
causes enormous dependency issues, the project itself has architectural
issues. I tend to wrap forms into form managers, and the majority of the
code interacts with the form manager, without even including the forms'
header file.

Tom
Oct 6 '06 #5

"Tamas Demjen" <td*****@yahoo.comwrote in message
news:Oo**************@TK2MSFTNGP02.phx.gbl...
Carl Daniel [VC++ MVP] wrote:
>I assume you're talking about Windows Forms designer generated classes?

Yes, I assume that's what the original poster meant.
>Personally, I wouldn't expect that to ever change - but who knows :)
The problem is, the designers are not maintained by the C++ team, so
getting the designer to support a separation of declaration/definition
requires getting another group to do work that's of no benefit to their
own product.

I realize that, but C++/CLI is claimed to be the primary .NET language.
Changing the designer would obviously benfit Visual Studio as a whole.
Although I'm not sure what percentage of the developers design GUI in
C++/CLI.

Fortunately it's not too hard to move the event handler implementations to
the .cpp file, but it's a major inconvenience. I don't think it would be
too hard to implement that feature (to generate an entry to the header
file as well as the .cpp, as Borland C++Builder does it), and it would
save a lot of time to the developers. I really insist that event handlers
are implemented in the .cpp file.

Moving the InitializeComponent to the .cpp file is a little bit less
important. Yes, it's annoying that moving an edit box around triggers a
recompile to other units, but frankly, most changes to the form do.
Typically when the GUI changes it involves adding new controls, thus new
declarations. Let's face it, most designer changes would trigger a
recompile to other modules anyway.

It would still be appreciated if moving a component, or changing its
color, wouldn't trigger any changes to any header file. It still has much
less impact than the event handlers.

At least this issue with monolithic header files enforces developers to
consider the separation of the GUI from the business logic, which I
personally support even in smaller projects, except maybe in quick and
dirty prototypes. The rest of the application logic should not depend on
the implementation of a particular component. Let's say a year into the
development you change from list box to list view, or from a Microsoft
component to a 3rd party with a different interface. It's definitely not
nice if such a change requires the editing of 100 function calls and
property references all across the project. So it's probably safe to say
that if the designer's inability of maintaining a separate .cpp file
causes enormous dependency issues, the project itself has architectural
issues. I tend to wrap forms into form managers, and the majority of the
code interacts with the form manager, without even including the forms'
header file.
Use an interface class and then nothing need include the form's header file
except its single .cpp
>
Tom

Oct 10 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Lior Bobrov | last post: by
4 posts views Thread by David Veeneman | last post: by
9 posts views Thread by squishy | last post: by
8 posts views Thread by subtle | last post: by
1 post views Thread by somequestion | last post: by
35 posts views Thread by Jon Skeet [C# MVP] | last post: by
5 posts views Thread by Showjump | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.