Where do I put the code for managed classes in managed C++

[Guest]

Hey everyone,

I noticed that unlike C#, managed C++ still uses headers and implementation
files. My question is, is there any consensus of where to put the
implementation of the managed class?

In my project, I put everything in the header file. I don't see the need to
put it in a seperate implementation file.

Any thoughts?

Thanks,

 

[Carl Daniel [VC++ MVP]]

Hey everyone,

I noticed that unlike C#, managed C++ still uses headers and
implementation
files. My question is, is there any consensus of where to put the
implementation of the managed class?

In my project, I put everything in the header file. I don't see the need
to
put it in a seperate implementation file.

Any thoughts?

It's just a question of style.

Putting all your member definitions in the header file makes them implicitly
inline, but given that most inlining is done by the JIT and happens
regardless of whether the function was marked as inline, it's not clear that
that's really a significant factor.

It's likely the case that putting all the implementation in the header file
will result in slower build times as the project gets larger - that's one
advantage the old header file/implementation file technique still has over
the C#/Java all in one file model.

-cd

 

[William DePalo [MVP VC++]]

In my project, I put everything in the header file. I don't see the need
to
put it in a seperate implementation file.

It's not something that I use, but I _think_ that WinForms puts code in
headers too. So, if you want a precedent, and one from inside the big house,
there you go.

Now I know that the language allows it, and the distinction between source
and header that was so clear to me in the K&R days is not so black and white
in modern C++, but it looks a tad strange to me. Just my opinion ...

Regards,
Will

 

[Guest]

Hi Carl,

It's just a question of style.

Putting all your member definitions in the header file makes them implicitly
inline, but given that most inlining is done by the JIT and happens
regardless of whether the function was marked as inline, it's not clear that
that's really a significant factor.

I see. But, since all methods are exported because it is a library (in my
project it is), I don't think it really matters anymore.

It's likely the case that putting all the implementation in the header file
will result in slower build times as the project gets larger - that's one
advantage the old header file/implementation file technique still has over
the C#/Java all in one file model.

Tom.

 

[Guest]

Hi William,

It's not something that I use, but I _think_ that WinForms puts code in
headers too. So, if you want a precedent, and one from inside the big house,
there you go.

YES!

Now I know that the language allows it, and the distinction between source
and header that was so clear to me in the K&R days is not so black and white
in modern C++, but it looks a tad strange to me. Just my opinion ...

Well, since I'm used to coding .NET in C#, I kind of dislike going back to
the header/implementation model. But managed C++ is probably more than just
C# so the model is probably still useful. I think I will be convinced once I
start mixing managed and unmanaged code. This is the actual purpose of my
project in managed C++: use of unmanaged C++-libraries under the hood.

BTW: Do we have a shorter name/tag for managed C++, like MC++ or so?

Thanks,
Tom Tempelaere.

 

[Peter van der Goes]

It's not something that I use, but I _think_ that WinForms puts code in
headers too. So, if you want a precedent, and one from inside the big
house, there you go.

Now I know that the language allows it, and the distinction between source
and header that was so clear to me in the K&R days is not so black and
white in modern C++, but it looks a tad strange to me. Just my opinion
...

Regards,
Will

You're correct. That's exactly where the implementing code is placed in a
..NET Windows Form project, much to the displeasure of purists (some of whom
have been very vocal about it).
AAMF, it remains that way in the VS 2005 beta, so it looks not to be a
temporary thing, but possibly a new trend coming from the "big house".

 

[William DePalo [MVP VC++]]

BTW: Do we have a shorter name/tag for managed C++, like MC++ or so?

Yes, at least in this group MC++ stands for "Managed Extensions for C++" or
just "managed C++".

That's the good news. The bad news is that the .Net targetting dialect (my
word) of C++ is getting a new name to go with new syntax in VS.Net 2005.
It's short name is usually written as C++/CLI.

Just by the way, at some point in the future C++/CLI will be an ECMA
standardized language and sometime before we all retire <g> it should be
standardized by ISO as well.

Regards,
Will
..

 

[William DePalo [MVP VC++]]

You're correct. That's exactly where the implementing code is placed in a
.NET Windows Form project, much to the displeasure of purists (some of
whom have been very vocal about it).

Count me in that group. Or in the "dinosaurs" group of people who learned
_the man's_ language from the famous tome by K&R with the white cover and
the big blue C.

Regards,
Will

 

[Arnaud Debaene]

You're correct. That's exactly where the implementing code is placed
in a .NET Windows Form project, much to the displeasure of purists
(some of whom have been very vocal about it).
AAMF, it remains that way in the VS 2005 beta, so it looks not to be a
temporary thing, but possibly a new trend coming from the "big house".

Then there is something I don't understand : I believed that part of the
"C++ come back" in VS2005 was due to the fact that MS realized that the
compilation model of C# and VB.NET didn't scale well, and that the
header/implementation separation was still the only way to keep build time
to grow exponentially on large projects. I am totally wrong here?

Arnaud
MVP - VC

 

[Tamas Demjen]

You're correct. That's exactly where the implementing code is placed in a

.NET Windows Form project, much to the displeasure of purists (some of whom
have been very vocal about it).

Nothing prevents you from manually cut and pasting those event handlers
to the .cpp file, though. The form designer will still be working.
However, you might get into trouble in the long run, like if you double
click on an event in the designer. I would certainly prefer if the final
release had the option of putting the event handlers to the .cpp file.
At least it should tolarete if we do that manually.

Tom

 

[Carl Daniel [VC++ MVP]]

Then there is something I don't understand : I believed that part of
the "C++ come back" in VS2005 was due to the fact that MS realized
that the compilation model of C# and VB.NET didn't scale well, and
that the header/implementation separation was still the only way to
keep build time to grow exponentially on large projects. I am totally
wrong here?

I don't think so.

OTOH, if you're worried about build times, you're probably building
something big. And if you're building something big, you're worried about
having a solid, maintainable design (right?). In which case, your WinForms
classes shouldn't have much "meat" in them - they should just be a GUI
veneer over the real guts of your application (model-view anyone?), so the
bulk of your code can still be implemented in The One True Style of
splitting interface into header files and implementation into implementation
files.

Of course, YMMV - mine always does

-cd

 

[adebaene]

I don't think so.

OTOH, if you're worried about build times, you're probably building
something big. And if you're building something big, you're worried about
having a solid, maintainable design (right?). In which case, your WinForms
classes shouldn't have much "meat" in them - they should just be a GUI
veneer

The problem is not the size of the code in the header : it is in how
many translation units is this header #included and how often it is
changed (and when finishing the GUI, it changes a lot...)

Arnaud
MVP - VC

 

[Ronald Laeremans [MSFT]]

I would certainly prefer if the final
release had the option of putting the event handlers to the .cpp file.
At least it should tolarete if we do that manually.

Hi Tom,

This will not be possible for the Whidbey release, the basic
architecture for the designers assumes headerless programming model. For
future releases we are looking into supporting a more traditional (at
least for non template code) C++ model.

Ronald Laeremans
Visual C++ team

 

[Tamas Demjen]

Thanks. It's odd, because in both VC++ 2003 and 2005 Beta 1, when I
manually move the InitializeComponent function to the .cpp file, the
designer is still working OK, as far as I can tell. I don't know what
kind of problems we may run into with this in the long run, though. So
it's officially not supported, it's good to know.

Tom

 

[Guest]

I find that in vc++ 2003 having all the implimentation code in the header is
a head ache, if i need to define class A which has a method that uses class B
and Class B has a member of Class A you are dead unless you have
implimentation code file. If ms is not going to change this every thing in
the header desing in Whidbey then the new compiler needs to handle the above
case like c# and vb.net.

 

[Guest]

Aaron,

I've been trying to figure this one out for a while and I'm stumped. I have
a class which has a member object (child class), but in the child class I
want to access a function from the parent form. When I add the cross
referencing headers I get compile errors. Are you saying that if I split up
the .h and .cpp files I will be able to achieve this? I appreciate any help.
It's driving me crazy. Basically, having a form as a member of another form.
But the smaller child form wants to either call a function in the parent form.