What's the use of CPP files?

  • Thread starter Thread starter wraith
  • Start date Start date
W

wraith

Hi to all,

Im just wondering on why VC++ .NET puts all of its code in the header file?
why not use th cpp file? wheres the two file approach?

I've read a comment on this newsgroup that suggests that microsoft is
dropping off cpp files and moving to the 1 file approach. Well for me,
microsoft has no such plans for they have just implemented the 2 file system
in C# Express (with the introduction of partial classes) i've used C# 2005
and was wondering why microsoft hasn't implemented this kind of approach in
C++/CLI. Upon creating a form, C# automatically creates another file to
store all of the compiler generated code (Initialization of controls,
etc..):
eg.

myForm.cs
-myForm.designer.cs

I also hate it when the compiler automatilcally places the scope on your
event or control...
eg

private: System::Windows::Forms::TextBox^ textBox1;
private: System::Windows::Forms::TextBox^ textBox2;

instead of

private:
System::Windows::Forms::TextBox^ textBox1;
System::Windows::Forms::TextBox^ textBox2;

In fairness to microsoft, they have done a very good job on upgrading the
language itself. (Now I don't see any __underscores) =)




cheers

Paul June A. Domag
nth geographics and geometrics
 
wraith said:
Hi to all,

Im just wondering on why VC++ .NET puts all of its code in the header
file? why not use th cpp file? wheres the two file approach?
Click to expand...

The simple answer: because the Winforms designers were designed with C# in
mind.

-cd
 
Hello Carl,
The simple answer: because the Winforms designers were designed with C# in
mind.
Click to expand...
This means that Visual Studio will focus on C#, dropping C++ in the process?
I am a C++ developer, and usually I use .NET for Windows Forms
interfaces, but I find very disturbing and annoying the fact that
VStudio puts all the code into the .h. This, and the bug that causes
loooong load times when switch to design view, binds me to move all
function bodies manually to the .cpp file, and wait some minutes
(sometimes a LOT of minutes. e.g: 20-30 minutes for large forms) every
time that I modify the .h file and switch to design view. I know that
there are a KB patch for this bug, but only for English and German
versions, and I'm spanish, so I MUST wait those minutes ever.

What do MS have in mind about C++ developers?


P.D: sorry for my bad english, please.
-cd
Click to expand...


--
Jacobo Rodríguez Villar

TyphoonLabs Lead Programmer

http://www.typhoonlabs.com
 
Jacobo said:
This means that Visual Studio will focus on C#, dropping C++ in the
process?
Click to expand...

Of course not. I simply means that the Winforms designers were designed
with C# in mind and so are not ideal for C++.
What do MS have in mind about C++ developers?
Click to expand...

See all the documentation about C++/CLI and other new C++ features in Visual
Studio 2005. Fear not, us C++ developers are not being left behind - not by
a long shot.

-cd
 
That's good to hear, Carl :)

Has VS 2005 address any of the not-so-C++ issues mentioned here?
 
The said:
That's good to hear, Carl :)

Has VS 2005 address any of the not-so-C++ issues mentioned here?
Click to expand...

AFIAK the WinForms designers are still C#-centric in Whidbey, but I haven't
tried 'em myself so I can't say for certain.

The changes in the language for .NET development are stunning, however.

-cd
 
Carl said:
AFIAK the WinForms designers are still C#-centric in Whidbey, but I haven't
tried 'em myself so I can't say for certain.

The changes in the language for .NET development are stunning, however.
Click to expand...


One could joke here and talk about the platform, bloated code, etc. :-)
 
Hi Carl,

If the winform designers were designed with C#, then why is it that C# in
Whidbey is already on 2 file approach? Well I guess that the winform
designer in c++ is patterned in the C# 2003...

I really hope that the Microsoft would consider implementing a 2 file
approach in C++/CLI final release...

cheers


Paul June A. Domag
nth geographics and geometrics
 
The change in designer load time for splitting up the files would not be
significant. The extremely long times you are seeing are indeed caused by a
bug in VS 2003 that you can get a fix for if you call product support, if
you don't give up too easily, you should be able to get the patch fro the
Spanish version as well. For QFEs we do not pro-actively create them for all
localized version, but only when a customer specifically has a need for
them.

Ronald Laeremans
Visual C++ team
 
Hi Ronald,
The change in designer load time for splitting up the files would not be
significant. The extremely long times you are seeing are indeed caused by a
bug in VS 2003 that you can get a fix for if you call product support, if
you don't give up too easily, you should be able to get the patch fro the
Spanish version as well. For QFEs we do not pro-actively create them for all
localized version, but only when a customer specifically has a need for
them.
Click to expand...
I asked to the Spanish Customer Support for the patch about one week
(thats when I knowed that there are a patch for this bug), but I am
waiting yet for a reply yet.
I hope that won't take a long time
Ronald Laeremans
Visual C++ team
Click to expand...


--
Jacobo Rodríguez Villar

TyphoonLabs Lead Programmer

http://www.typhoonlabs.com
 
Ronald said:
For QFEs we do not pro-actively create them for all
localized version, but only when a customer specifically has a need for
them.
Click to expand...

What is it, a piece of art? :-)
 
With C++/CLI you have the option of writing all of your code in the header
file. Before managed code, this was a no-no, because the header file was used
to link other libraries. The implementation in the .cpp file could change all
it wanted as long as the .h file stayed the same. Then you didn't have to
re-compile the dependant program. Also the .h file was supposed to be as
small as possible, because it was brought in to other pieces of code. If it
was large then the dependant app would be larger. With .Net, the .dll is a
self-contained, self-describing module. You add the assembly in the project
properties and there is no need to add the .h file to each dependent program.
Therefore these outside dependant apps can't see the difference inside the
assembly. So it's up to you if you want to use two files, or just move the
implementation into the .h file.

GrkEngineer
 
Back
Top