|
Demian Panello wrote: Like fflush(stdin) does in C.
What about using System::IO::FileStream::Flush() ?
|
|
|
|
|
Thank you Prasad.
Demian.
"I have always wished that my computer would be as easy to use as my
telephone. My wish has come true. I no longer know how to use my telephone."
-Bjarne Stroustrup, computer science professor, designer of C++
programming language (1950- )
|
|
|
|
|
Hello,
i want to use a Lib in a C# Projekt. Therefore i want to reconfig the Lib-Project (all sources) into a dll Project.
new Settings:
Configuration Typt: Dynamic Library (.dll)
Common Language Runtime support: Common Language Runtime Support (/clr)
For Debug:
Enable C++ Exceptions: No
Runtime Library: Multi-threaded Debug DLL (/MDd)
After this i wand to compile the Project and get a D8045 Error.
-------------------
Only C++ source code files can be passed to a compilation that uses /clr. Use /TP to compile a .c file as a .cpp file; see /Tc, /Tp, /TC, /TP (Specify Source File Type) for more information.
-------------------
one source-File is a c-File.
does that run at all ore have i find another solution?
|
|
|
|
|
Did you follow the instructions in the error message?
Use /TP to compile a .c file as a .cpp file; see /Tc, /Tp, /TC, /TP (Specify Source File Type) for more information.
led mike
|
|
|
|
|
Hi all,
Iam working on Pointers. How would I pass this memory location as an argument to a function?
ie.,
#define REG (*((volatile unsigned long *) 0x3FFFC00E))
this is my function
void funcTest( unsigned long reg, char value)<br />
{<br />
reg= value;<br />
}<br />
I need to pass the "REG" as an argument so that I write the "value" to that particular memory location or the register.
|
|
|
|
|
I'm not sure what you are trying to do...
REG dereferences the pointer so it becomes the unsigned long stored at address 0x3FFFC00E.
You need a reference or pointer to an object passed to a funtion if you want to modify the object
in the function:
Then in your func you assign a char to an unsigned long??
Whatcha tryin to do? 
"Great job, team. Head back to base for debriefing and cocktails."
(Spottswoode "Team America")
|
|
|
|
|
Looks to me like you're in the wrong forum, this doesn't look like a .NET C++ question. Try the Visual C++ forum.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
If I have a C# only application I could ship my application without worrying about the target platform.
However if I have a Managed C++ DLL I should, it seems, provide a 32bits installer and a 64bits installer.
Right now I'm considering ship 2 version of the ManagedC++ DLL with a C# wrapper which call into the appropriate one depending of the platform.
But this a lot of work to create this wrapper.
Particularly as I declare some managed struct in the Managed C++ library which I pass around.
Is there any better and quicker way to be platform independant?
One of the problem we face is we create installer for affiliates.
All the installer together are quite big.
If I should now double the size because of 32bits/64bits consideration that becomes daunting...
-- moved at 21:21 Tuesday 20th March, 2007
|
|
|
|
|
Super Lloyd wrote:
Is there any better and quicker way to be platform independant?
I'd just stick to both...
"I've seen more information on a frickin' sticky note!" - Dave Kreskowiak
|
|
|
|
|
|
Please ask in the VC++ forum. This one's for C++/CLI related stuff.
|
|
|
|
|
dear programmers,i have started my first programming experience with C++,
and i have read the DEITEL c++ book,i want to know,what should i do now?
should i continue with the MFC or C#.net 2005?thanks
khodadad pakdaman
pakdaman@cleanmail.it
|
|
|
|
|
You should probably ask your questions in the right forum, this one is for neither C++, nor C#, but for C++/CLI.
It depends what you want to do. C# is probably a more likely choice.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Christian Graus wrote: It depends what you want to do. C# is probably a more likely choice.
 Definitely the appropriate path after finishing the book on C++ 
"Great job, team. Head back to base for debriefing and cocktails."
(Spottswoode "Team America")
|
|
|
|
|
Easier to use, better library support, more support online, I'd say it's a more likely choice for someone starting to program windows.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
I know I was entertained by the response after the original post.
Mark
"Great job, team. Head back to base for debriefing and cocktails."
(Spottswoode "Team America")
|
|
|
|
|
Hi,
I'm running a team where our .net development is going to need to integrate with some commercial software with C++ APIs. I've identified Managed C++ as the implementation mechanism for integrating the technologies and we have a couple of prototypes working...
.. however, I've managed to convince the Project Manager that we should have a couple of reference books available for the team.
Can anyone recommend any MC++ books, specifically Visual Studio 2005?
Regards,
Ray
|
|
|
|
|
Ray,
Unfortunately, there aren't many books available. However, I have found the following useful:
C++/CLI
The Visual C++ Language for .NET
Gordon Hogenson, Apress
ISBN-13:978-1-59059-705-7
ISBN-10:59059-705-2
This deals mostly with the C++/CLI language. The same author will have the following available in April, 2007:
Expert Visual C++/CLI, Apress
Also,
Pro Visual C++/CLI and the .NET 2.0 Platform
Stephen G. Fraser. Apress
seems to be more for beginners than the aforementioned.
Also,
C++/CLI in Action
Nishant Sivakumar, Manning
ISBN: 1-932394-81-8
will be released in April, 2007 also. This book is written by one of our great contributors here at the Code Project.
Geo.
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|
|
Hi,
I have a question regarding C++/CLI and classes. I can declare a managed class like this:
#pragma managed<br />
public ref class A<br />
{<br />
public:<br />
void DoSomething();<br />
};
The compiler will translate this one into MSIL or CIL. And I can use this class in any .Net language by adding my compiled dll/exe as a reference e.g. in a C# project.
And here's the unmanaged pendant:
#pragma unmanaged<br />
class B<br />
{<br />
public:<br />
void DoSomething();<br />
};
This is code gets translated into native code.
But what happens, if I have the following:
#pragma managed<br />
class C<br />
{<br />
public:<br />
void DoSomething();<br />
};
What does the compiler exactly with this code? I'm confused 
|
|
|
|
|
class C gets compiled to MSIL. Check it out in the disassembler
"Great job, team. Head back to base for debriefing and cocktails."
(Spottswoode "Team America")
|
|
|
|
|
Hi Marc, thank you for the information. Well, I used Reflector.Net and didn't see these "hyrid" classes. But how is it possible that e.g. the managed class C could inherit from native class B?
And if I call call a native function in class C, does it use internally PInvoke to call it? So, is it basically faster to call managed functions/methods from class C than calling native functions?
|
|
|
|
|
class C is not a managed class. It is compiled to MSIL because of the #pragma managed (or by
default if no #pragma used and the /CLR compiler switch is used) but that doesn't make it a
managed class.
I'm not sure about the specifics of how native calls get done from MSIL but I don't think it
involves pinvoke since it's not a managed class.
Ludi83 wrote: So, is it basically faster to call managed functions/methods from class C than calling native functions?
Whether you compile your unmanaged classes to MSIL or native, all the same rules apply when mixing
managed and unmanaged classes. Intuitively, any MSIL code should be slightly slower than native
C++ code but since it's JIT compiled (not interpreted) there's no noticable difference in speed
that I've seen. I've never benchmarked it but I bet the difference is minimal.
If performance is an issue, marshalling between managed and unmanaged code is a way bigger issue
than how the unmanaged code is compiled.
Mark
"Great job, team. Head back to base for debriefing and cocktails."
(Spottswoode "Team America")
|
|
|
|
|
I have a .NET project with a mix of standart interop in C# and Managed C++.
It used to work and compile fine on WindowsXP 32 bits, with Visual Studio standart edition.
Today I upgraded to Windows Vista 64 bits, with Visual Studio Professional.
I deleted all .obj, .exe, *.dll files, bin/obj folders.
And rebuild and run...
I have this exception at startup with one of my Managed C++ dlls...
BadImageFormatException was unhandled
Could not load file or assembly 'NScribe, Version=1.0.2635.30786,
Culture=neutral, PublicKeyToken=null' or one of its dependencies. An
attempt was made to load a program with an incorrect format.
Any tips?
|
|
|
|
|
Have you solved this?
"I've seen more information on a frickin' sticky note!" - Dave Kreskowiak
|
|
|
|
|
simple!
While C# assembly don't target any architecture by default, Managed C++ assembly should target a given architecture.
For my Managed C++ I targeted x86 / 32 bits.
Now, all I need is set my main / starting / exe C# assembly affinity to x86 as well (in project properties => build => platform target combo box )
Otherwise, what will happen, is the C# assembly will start as a 64bits executable and will have the aforementioned problem when trying to load a 32bit Managed C++ dll..
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
