|
For all it is worth, I am a former developer of Microsoft Excel and am using C# to develop shrink-wrapped desktop software.
The plus:
1) Garbage collection reduces an entire class of errors
2) Performance is actually quite good. One thing that you often don't hear is that code written in C# can actually be faster than C++ in many cases because of
a) Extensive inlining,
b) use of the __fastcall convention,
c) ultrafast heap allocation
d) sizeable library
3) Very good exception handling
4) You are going to develop your software much faster
The one bad thing is the omission of some of the document infrastructure of MFC and the number of third-party support for MFC.
Thanks,
Wes
|
|
|
|
|
Please take a look at WTL. As for the argument of C# being faster, it depends on what you are doing - if you accessing database, the speed is actually not much dependent on the application but by the database provider access protocol and other factors.
I have just completed an MC++ GIS component, the GDI+ speed is so disappointing. However, using the direct COM version with GDI where necessary, I got a manageable speed.
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|
|
Paul Selormey wrote:
I have just completed an MC++ GIS component
An article possibility?? 
-Nick Parker
|
|
|
|
|
Nick Parker wrote:
An article possibility??
It is a company work, however, I might find time to share some points and experience if this is what you mean.
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|
|
Paul Selormey wrote:
It is a company work, however, I might find time to share some points and experience if this is what you mean.
It sounded interesting, sure, write something up. 
-Nick Parker
|
|
|
|
|
Right, after my June holiday (going to Ghana-Africa to enjoy sunshine!) I will try to put something up.
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|
|
Paul Selormey wrote:
going to Ghana-Africa to enjoy sunshine!
Enjoy and take it easy.
-Nick Parker
|
|
|
|
|
Hello everyone, I've been working with a developer of a commercial email component written in managed c++ for the past three weeks trying to pin down a problem.
We think we've found a bug in .net (problem happens with both 1.0 and 1.1). I would like to know if anyone has seen anything similar or heard of a bug that might be related to this. (I've scoured the net for weeks now but nothing)
Here are the details:
.Net reports a null reference exception very randomly and intermittently, (sometimes not for days, sometimes almost immediately when the test app is run) like this:
************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an
object.
at ClsEmail.Clone(ClsEmail* )
(truncated here)
The author of the component has kindly provided the source code to the function being called and his comments below it:
Email *EmailBundle::GetEmail(long index)
{
if (!m_bundle) return 0;
ClsEmail __nogc *e = m_bundle->GetEmail(index);
if (!e) return 0;
ClsEmail __nogc *e2 = e->Clone(); <---- Stack traceback indicates the failure is here
if (!e2) return 0;
Email *eTemp = new Email(e2);
return eTemp;
}
The stack traceback and error message indicate that "e" is not a valid
managed object, but e isn't a managed object in the first place.
The code that calls it is plain vanilla c# and can work for days or only minutes, it just loops and gets email from a server. The problem happens on both an XP Pro and a Windows 2000 server computer that are stripped bare test stations.
The component author is unable to reproduce the error, however I can reproduce it easily on test computers here and he has at least one other client that has reported the problem.
I really need this to work reliably for a project I'm working on. Problem is it works perfectly most of the time, then fails and it's an unattended mail server type program with remote users so it's disastrous when it fails.
Does anyone have any thoughts on this or has seen anything similar before?
(I have much more information but didn't want to post too much)
"Things are more like they are now than they ever were before."
-- Dwight Eisenhower
|
|
|
|
|
If m_bundle is a __gc class and you are referencing it with a __nogc pointer, garbage collection can move the pointed to memory at anytime. You need to use a pinned pointer.
ClsEmail __pin *e2 = e->Cloned();
The pinned pointer remains pinned until it goes out of scope or gets assigned a value of zero.
|
|
|
|
|
I asked the component author about something similar before, but I'll ask specifically about the point you raised, thank you for taking the time to look at it.
"Things are more like they are now than they ever were before."
-- Dwight Eisenhower
|
|
|
|
|
Author says m_bundle is a __nogc so that's not it I guess.
|
|
|
|
|
Strange! I suspect it is since it looks like it is using the Clone() method of the ICloneable interface. Since we cannot see under the covers, it's hard to determine what is going on.
|
|
|
|
|
Hmmm...you have a point there, I'll ask.
"Things are more like they are now than they ever were before."
-- Dwight Eisenhower
|
|
|
|
|
|
So, where is the managed code? Is everything unmanaged?
|
|
|
|
|
Hi im new to Managed C++
Can a anyone tell me how to convert String to int..
In native C++ we used atoi(CString) function.So in MC++ what should I use.
cheers,
Super
------------------------------------------
Too much of good is bad,mix some evil in it
|
|
|
|
|
If you're using .NET string and int datatypes (internally the String and Int32 classes) you can use the Parse method of Int32:
int nResult = 0;
String* pMyNumber = "15";
nResult = Int32::Parse( pMyNumber );
I've found that it's possible to cast between the CString and the .NET String datatypes without any trouble (at least I think I did -- was a while ago I last used MC++).
If not, I'm sure someone far more knowledgeable than me will be able to suggest exactly what you need to do 
--
Paul
"Put the key of despair into the lock of apathy. Turn the knob of mediocrity slowly and open the gates of despondency - welcome to a day in the average office."
- David Brent, from "The Office"
MS Messenger: paul@oobaloo.co.uk
|
|
|
|
|
Hello All,
I have a project in MC++ consisting of several components/controls.
Many parts used indexed properties. These are recognized in VB.NET as properties, and shows in the VB.NET code browser as such.
However, in C#, the indexed properties are seen as methods;
get_Item/set_Item instead of the Item property in the following:
__property String __gc* get_Item(Int32 index)
{
}
__property void set_Item(Int32 index, String __gc* value)
{
}
Is this a known problem? is there anyway to work around it? It is
becoming very difficult to document our components.
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|
|
Hi Paul
Put [ DefaultMember( "Item" ) ] before your class declaration
Regards,
Nish
p.s. I answered this in the newsgroup too (then saw this post and confirmed that you and he are the same )
p.s. #2 - I posted this here too so you'll find it earlier
"I'm a bit bored at the moment so I'm thinking about writing a new programming language" - Colin Davies
My book :- Summer Love and Some more Cricket [New Win]
Review by Shog9 Click here for review[NW]
|
|
|
|
|
Thanks.
Nishant S wrote:
p.s. I answered this in the newsgroup too (then saw this post and confirmed that you and he are the same )
Read that too. Andre claims it is a bug. It works with VB.NET without marking it as DefaultMember. I do not know when the MC++ team will have put a real working compiler for .NET - it is still too buggy
BTW, should it be DefaultMember or DefaultProperty?
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|
|
Paul Selormey wrote:
Andre claims it is a bug
Well, I did not say it is a bug. All I said was that
a) As DefaultMember makes the property in question the indexer for C# (e.g. public string this[int index]{get; set;} ), there can be only one indexed property in C#
b) The way the indexer is accessed (instance[5] instead of what on expect for a indexed property instance.MyProp[5]) makes the class look array-like.
So, after all, it is not a missing feature in MC++ (which supports indexed properties), but more of a missing feature in the C# specifications.
(BTW. it is System.Reflection.DefaultMemberAttribute)
Best regards,
Andre
P.S.: damn, i hate it when I have to rewrite the whole post just because I forgot to log in
|
|
|
|
|
When compiling and linking a MC++ 2003 class library, the /EHsc compiler option causes a
LNK2001 error when a class is derived from a base class containing a destructor! Remove the
/EHsc option and the code compiles and links with any problems.
Create a MC++.NET 2003 Class Library with the following:
// bd.h
#pragma once
using namespace System;
namespace Testing
{
public __gc class Base
{
public:
Base(void)
{
Console::WriteLine(S"Base::Ctor");
}
~Base(void)
{
Console::WriteLine(S"Base::Dtor");
}
virtual void FromtheBase(void)
{
Console::WriteLine(S"Base::FromtheBase");
}
};
public __gc class Derived : public Base
{
public:
Derived(void)
{
Console::WriteLine(S"Derived::Ctor");
}
};
}
C++ Command Line:
/Od /AI "C:\Projects2003\Test\LinkError\Debug" /D "WIN32" /D "_DEBUG" /D "_MBCS" /D
"_WINDLL" /FD /EHsc /MTd /GS /Yu"stdafx.h" /Fp"Debug/bd.pch" /Fo"Debug/"
/Fd"Debug/vc70.pdb" /W3 /nologo /c /Zi /clr /TP /FU
"C:\WINNT\Microsoft.NET\Framework\v1.1.4322\mscorlib.dll" /FU
"C:\WINNT\Microsoft.NET\Framework\v1.1.4322\System.dll" /FU
"C:\WINNT\Microsoft.NET\Framework\v1.1.4322\System.Data.dll"
Additional Options: /Zl
Linker Command Line:
/OUT:"C:\Projects2003\Test\LinkError\Debug\bd.dll" /INCREMENTAL /NOLOGO /DLL /DEBUG
/ASSEMBLYDEBUG /PDB:"C:\Projects2003\Test\LinkError\Debug/bd.pdb" /FIXED:No nochkclr.obj
mscoree.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib
shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib "\Program
Files\Microsoft Visual Studio .NET 2003\Sdk\v1.1\Lib\mscoree.lib"
Additional options: /noentry
Error:
bd error LNK2001: unresolved external symbol "void __cdecl __CxxCallUnwindDtor(void
(__thiscall*)(void *),void *)" (?__CxxCallUnwindDtor@@$$J0YAXP6EXPAX@Z0@Z)
After doing a link with the /FORCE option, I noticed the following in ildasm in the derived
class ctor:
.method public specialname rtspecialname
instance void .ctor() cil managed
{
// Code size 32 (0x20)
.maxstack 2
IL_0000: ldarg.0
IL_0001: call instance void Testing.Base::.ctor()
.try
{
IL_0006: ldstr "Derived::Ctor"
IL_000b: call void [mscorlib]System.Console::WriteLine(string)
IL_0010: leave.s IL_001f
} // end .try
fault
{
IL_0012: ldftn instance void Testing.Base::__dtor()
IL_0018: ldarg.0
IL_0019: call void
modopt([mscorlib]System.Runtime.CompilerServices.CallConvCdecl) __CxxCallUnwindDtor(method
unmanaged thiscall void modopt([mscorlib]System.Runtime.CompilerServices.CallConvThiscall)
*(void*),
void*)
IL_001e: endfinally
} // end handler
IL_001f: ret
} // end of method Derived::.ctor
Since /NOENTRY is enabled, linkage to __CxxCallUnwindDtor and __DllMainCRTStartup@12 is
impossible. This leaves me with a some options while I wait for an answer from somebody:
1. Remove /EHsc with my fingers crossed. What are the side effects of doing this?
/EH{s|a}[c][-] specifies the model of exception handling to be used by the compiler
according to the Microsoft Visual C++.NET Language Reference.
2. Remove /NOENTRY and configure compile and link options like MC++ 2002. (Danger!)
3. Create a netmodule or assembly for the base class declaration to be reference by an assembly with the derived class declaration. (No way, more files to maintain)
4. Compile to .exe from .h and .cpp files. (very limiting, hard to maintain. Anti .NET!)
5. Mixed DLL Loading Problem Solution (Pain in the neck!)
Actually, I believe the solution deals with the disabling of /EHsc (/EHsc- or /GX-). /EHsc- is the default setting if you compile from the command line. You will need /EHsc only when you have unmanaged C++ unwinding exceptions. For example, if you use STL, /EHsc would be required, and the Mixed DLL Loading Problem solution applied.
|
|
|
|
|
Just turn it off for the "managed" files. And keep the rest as you want.
Hey leppie! Your "proof" seems brilliant and absurd at the same time. - Vikram Punathambekar 28 Apr '03
|
|
|
|
|
I just installed Visual Studio .NET 2002 a few months ago. I am using the C++ compiler almost exclusively for ATL, MFC, WTL and managed C++ apps. Why should I upgrade to Visual Studio .Net 2003? What REAL benefits do I get. My company has already rejected the .Net framework for now... So I only use the C++ compiler. Is the upgrade worth it?
Robert Greene
|
|
|
|
|
I upgraded due to the following:
1. The upgrade costs less than $30.
2. VC++ 2003 conforms more closely with the standard.
3. MC++ has been enhanced.
Of course, with any new product, there will be bugs!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
