"Managed Extensions" sounds better (if that is what you mean). ;) Its because CLI is confusing abbreviation. http://en.wikipedia.org/wiki/CLI
I have impression that these extensions do not interoperate with most good old C++ code without tons of conversions. At least the interfaces between true C++ and extended C++ i have seen looked as bad as interfaces between true C++ with VB or C#.
So there are two ways:
Easier:
Make separate classbuilders for managed C++ and true C++ and keep them separate.
Harder:
Make strong (visible) difference between managed and not managed classes.
Add lots of interoperability support between managed and not managed classes.
Not managed C++ is still perfomance king so i do not see a way to entirely drop and forget it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, C++ is the way to go. Back in the early 80's went fro assembler to C++ and C++/CLI may seem like a step backwards, but I my real like I'm a database administrator. Using C++/CLI made my life easier, writing code to access databases.
Gunner
P.S. Did you get 2.6?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I did take the source package, and ran it but did get confused what it does. ;-) Last when i checked then these microsoft managed c++ classes did look something like:
.NET 2005 made it to look bit less obscure but interoperability with C++ was still very sad. Classbuilder 2.6 did not generate me something like that so ... i am unsure if i understand what is going on. I dont have to use .NET managed things for something so i am probably worst expert anyway. :-)
I think that reverse engineering parser is somewhat difficult to find too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Lets call it MC++/CLI then ... its most clear? :-)
It parses differently than C++.
It works differently than C++.
It takes work to interoperate with C++ MC++/CLI.
It changes once in 2 years.
Libraries do not work with it ... like STL, boost, loki etc.
Easiest is to write pure MC++/CLI or pure C++ apps and not to mix them (even if you can compile both in a single cpp they dont interact without pain).
MS 2005 IDE supports C# LOT better than MC++/CLI or C++.
MC++/CLI and C# differ not that heavily from each other.
That pattern shows that our good old MS is trying to convert his loyal C++ developers (you) into C# developer with that MC++/CLI. ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Don't get me wrong, I am not a big fan MC++/CLI and .Net because it doesn't compile to machine code. Microsoft say their p-code (or what ever they want to call it) is almost as fast as native code compilers but I question how true that is.
I have no plans to use MC++/CLI within the source for Classbuilder. Writing apps for things like SQL Server, I'll use it, but not CB.
C#, I have never used it, I look at C# source and think of how I can rewrite it in C++.
Gunner
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oh dont get me wrong too. My opinions are that MS C# is fine. Not useful for my work but ok neverthless. MC++/CLI i like less but that is probably personal.
Lets better discuss ... what to do? In a very general plan i mean. We have very cute C++ tool. These are rare. Does fine C++ classes that do not crash and do not need to be "managed" at all.
1) We can go for MC++/CLI and support only managed classes on.
2) We can try to make it universal to build classes for both at once.
3) We can split Classbuilder up as two directions "Classbuilder for MC++/CLI" and "Classbuilder for C++".
4) We can ignore current MC++/CLI (let it mature) and not to support it now.
I myself like option 3). 1) is bad because the fine side of classbuilder building C++ classes that dont need to be managed is wasted. Also its bad for people who maintain old code, write for odd hardware or develop crossplatform. 2) is dangerous because I believe we may fail to mix two ideologies together, break it and find us in emergency rollback situation. 4) is also bad if you need them extensions for your work.
What you think?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Number 2 but use an option in the DataModel dialog to turn it on and off. When off you get the Non-CLI dialogs for Class, Member and Methid and when on the extended versions of the dialog boxes. If you take seperate paths for Standard C+ and CLI you get .CBD that are out out sync.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am slow here. Probably not getting your idea. How we avoid someone doing something like that:
1) turn MC++/CLI on
2) make a class M
3) turn MC++/CLI off
4) make a class N
5) add some forbidden relation between M and N (most of them ... say make N as member of M)
6) Write source.
7) does not compile.
8) Write bug report in SourceForge ClassBuilder
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Prevent step 3 by scanning for MC++/CLI classes, if there is MC++/CLI classes, don't let the option to be turn off until it is corrected. I've seen this done within Classbuilder for other thing.
So far the primary problems I have had between CLI and Standard C++ is constants, because a CLI Object can be moved at runtime. So anything involving an address can NOT be constant. I've been discovering these differences as I go, so it is a little bit of hit and miss currently.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK. Relations between MC++/CLI classes have to be made differently but as long they are all MC++/CLI classes its possible.
I am still suspidous about possible mixing up. For example how we prevent him doing it other way around?
1) turn MC++/CLI off
2) make a class N
3) turn MC++/CLI on
4) make a class M
5) add some forbidden relation between M and N ... ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I uploaded a new version that is MC++/CLI selectable at the data model level.
I have not attempted to compile the new code under VC++ 6.0, 7.0 or 7.1, I have only tested it with 8.0.
Gunner
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Appears i got 8.0 only at one computer and only at home. It is because 8.0 compiler seemed quite super but IDE looked downstriped, buggy, hangy and crashy.
So ... good reason to evaluate that 8.0 once more. :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The impression i got however was that there is lot of compiler checks code style:
#if _MSC_VER < 1300
where differences have nothing to do with a compiler used so ATL or MFC version should be checked instead.
I believe it is no best practice (common in open source however) to have cpp file full of this sort of #if s.
Crossplatforming is better to hide in include files to keep preprocessor directives count low in code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What VC++/CLI Extensions due you consider important
Gunner
"Managed Extensions" sounds better (if that is what you mean). ;) Its because CLI is confusing abbreviation.
http://en.wikipedia.org/wiki/CLI
I have impression that these extensions do not interoperate with most good old C++ code without tons of conversions. At least the interfaces between true C++ and extended C++ i have seen looked as bad as interfaces between true C++ with VB or C#.
So there are two ways:
Easier:
Make separate classbuilders for managed C++ and true C++ and keep them separate.
Harder:
Make strong (visible) difference between managed and not managed classes.
Add lots of interoperability support between managed and not managed classes.
Not managed C++ is still perfomance king so i do not see a way to entirely drop and forget it.
Yes, C++ is the way to go. Back in the early 80's went fro assembler to C++ and C++/CLI may seem like a step backwards, but I my real like I'm a database administrator. Using C++/CLI made my life easier, writing code to access databases.
Gunner
P.S. Did you get 2.6?
Yes, I did take the source package, and ran it but did get confused what it does. ;-) Last when i checked then these microsoft managed c++ classes did look something like:
__abstract __gc struct Blaah : Mnjaah
{
__property int get_Kize() { return 0; };
__property void set_Kize(int i) { };
__sealed virtual int funka() {return 1;}
};
__gc __interface Inert
{
void fou();
};
__value struct Voo
{
int i;
};
.NET 2005 made it to look bit less obscure but interoperability with C++ was still very sad. Classbuilder 2.6 did not generate me something like that so ... i am unsure if i understand what is going on. I dont have to use .NET managed things for something so i am probably worst expert anyway. :-)
I think that reverse engineering parser is somewhat difficult to find too.
Yes, 2005 does look different, in fact that is why it is not longer referred to as Managed C++, instead it is referred to as C++/CLI
Craig
Lets call it MC++/CLI then ... its most clear? :-)
It parses differently than C++.
It works differently than C++.
It takes work to interoperate with C++ MC++/CLI.
It changes once in 2 years.
Libraries do not work with it ... like STL, boost, loki etc.
Easiest is to write pure MC++/CLI or pure C++ apps and not to mix them (even if you can compile both in a single cpp they dont interact without pain).
MS 2005 IDE supports C# LOT better than MC++/CLI or C++.
MC++/CLI and C# differ not that heavily from each other.
That pattern shows that our good old MS is trying to convert his loyal C++ developers (you) into C# developer with that MC++/CLI. ;-)
Don't get me wrong, I am not a big fan MC++/CLI and .Net because it doesn't compile to machine code. Microsoft say their p-code (or what ever they want to call it) is almost as fast as native code compilers but I question how true that is.
I have no plans to use MC++/CLI within the source for Classbuilder. Writing apps for things like SQL Server, I'll use it, but not CB.
C#, I have never used it, I look at C# source and think of how I can rewrite it in C++.
Gunner
Oh dont get me wrong too. My opinions are that MS C# is fine. Not useful for my work but ok neverthless. MC++/CLI i like less but that is probably personal.
Lets better discuss ... what to do? In a very general plan i mean. We have very cute C++ tool. These are rare. Does fine C++ classes that do not crash and do not need to be "managed" at all.
1) We can go for MC++/CLI and support only managed classes on.
2) We can try to make it universal to build classes for both at once.
3) We can split Classbuilder up as two directions "Classbuilder for MC++/CLI" and "Classbuilder for C++".
4) We can ignore current MC++/CLI (let it mature) and not to support it now.
I myself like option 3). 1) is bad because the fine side of classbuilder building C++ classes that dont need to be managed is wasted. Also its bad for people who maintain old code, write for odd hardware or develop crossplatform. 2) is dangerous because I believe we may fail to mix two ideologies together, break it and find us in emergency rollback situation. 4) is also bad if you need them extensions for your work.
What you think?
Number 2 but use an option in the DataModel dialog to turn it on and off. When off you get the Non-CLI dialogs for Class, Member and Methid and when on the extended versions of the dialog boxes. If you take seperate paths for Standard C+ and CLI you get .CBD that are out out sync.
I am slow here. Probably not getting your idea. How we avoid someone doing something like that:
1) turn MC++/CLI on
2) make a class M
3) turn MC++/CLI off
4) make a class N
5) add some forbidden relation between M and N (most of them ... say make N as member of M)
6) Write source.
7) does not compile.
8) Write bug report in SourceForge ClassBuilder
Prevent step 3 by scanning for MC++/CLI classes, if there is MC++/CLI classes, don't let the option to be turn off until it is corrected. I've seen this done within Classbuilder for other thing.
So far the primary problems I have had between CLI and Standard C++ is constants, because a CLI Object can be moved at runtime. So anything involving an address can NOT be constant. I've been discovering these differences as I go, so it is a little bit of hit and miss currently.
OK. Relations between MC++/CLI classes have to be made differently but as long they are all MC++/CLI classes its possible.
I am still suspidous about possible mixing up. For example how we prevent him doing it other way around?
1) turn MC++/CLI off
2) make a class N
3) turn MC++/CLI on
4) make a class M
5) add some forbidden relation between M and N ... ?
Hi Vambola,
I uploaded a new version that is MC++/CLI selectable at the data model level.
I have not attempted to compile the new code under VC++ 6.0, 7.0 or 7.1, I have only tested it with 8.0.
Gunner
I made some more changes. To track which build is being used, I have included the build number on the about dialog. Current build is 2565.
Thanks Craig.
Appears i got 8.0 only at one computer and only at home. It is because 8.0 compiler seemed quite super but IDE looked downstriped, buggy, hangy and crashy.
So ... good reason to evaluate that 8.0 once more. :-)
Btw... what version of ATL/MFC you use with 8.0?
Seems that ATL/MFC is abandonware ... none was distibuted with 2005, OTOH our ClassBuilder does not compile without.
Are you sure you are not using Studio 2005 Express? Studio 2005 Standard/Pro came with MFC.
Exactly, i had Express. <g>
The impression i got however was that there is lot of compiler checks code style:
#if _MSC_VER < 1300
where differences have nothing to do with a compiler used so ATL or MFC version should be checked instead.
I believe it is no best practice (common in open source however) to have cpp file full of this sort of #if s.
Crossplatforming is better to hide in include files to keep preprocessor directives count low in code.