C# alias
-
Of course, just as in C like he asked:
C:\>type test.h
using System ;C:\>type test.cs
include "test.h"
namespace Template
{
public static class Template
{
[STAThreadAttribute()]
public static void
Main
(
)
{
Console.WriteLine ( "It works" ) ;
}
}
}C:\>"C:\Program files\mingw\bin\cpp" -P -C -w test.cs test.csi
C:\>csc test.csi
Microsoft (R) Visual C# 2008 Compiler version 3.5.30729.1
for Microsoft (R) .NET Framework version 3.5
Copyright (C) Microsoft Corporation. All rights reserved.C:\>test
It worksC:\>
:-D
-
Great answer. :D Only caveat would be with
#definesand#if/#else. Since C# DOES recognize those, the cpp preprocessor might be problematic if you used them for any reason (i.e.#if DEBUG blah)Yes, but I have ways of dealing with them. Actually, I only use it for
# defines, it goes back to my PRO*C days. -
Well blow me sideways with a plastic marionette. I've just learned something new - and if I could award you a 100 for that post I would. Way to go you keyboard lovegod you.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
:laugh: I will quote you on that. Once I stop laughing. Which may be a while.
-
Well blow me sideways with a plastic marionette. I've just learned something new - and if I could award you a 100 for that post I would. Way to go you keyboard lovegod you.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
-
I just wonder if he's willing to be a reference.
-
Yes, but I have ways of dealing with them. Actually, I only use it for
# defines, it goes back to my PRO*C days. -
Yes, but generally just constants like:
# define MAXNAMELEN 32I kinda wish there were a different directive for macroes. It would also be good if the pre-processor took a switch to indicate it should only process the# defines and not other directives. -
Or maybe I misunderstood. My technique for having the C-preprocessor process only
# defines goes back to my PRO*C days. But, yes, I do (kinda/sorta) use macroes in my C# code... just to prove the point. But only when using CSC; I haven't bothered to try to use them with Visual Studio. Even though Microsoft gives good reasons for frowning on macroes in C#, I believe a bigger factor was integration with VS, and I don't fault them on that. -
I just wonder if he's willing to be a reference.
-
I sounds like he's willing to be the father of your offspring!
___________________________________________ .\\axxx (That's an 'M')
Nope. One set of anklebiters is enough for anybody.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
-
Nope. One set of anklebiters is enough for anybody.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
-
Or maybe I misunderstood. My technique for having the C-preprocessor process only
# defines goes back to my PRO*C days. But, yes, I do (kinda/sorta) use macroes in my C# code... just to prove the point. But only when using CSC; I haven't bothered to try to use them with Visual Studio. Even though Microsoft gives good reasons for frowning on macroes in C#, I believe a bigger factor was integration with VS, and I don't fault them on that.Thanks for your responses guys, and just to say that I have managed to adapt PIEBALDconsult's creative solution into something that will work in a straight-through build run with MSBuild rather than Csc. I can now run VS Projects and have MSBuild selectively pre-process files that have #includes in them, and process the others normally in one run. The 'trick', if you like, was to set up a custom Task that does the preprocessing if it finds a file with a given extension (and I've used PIEBALD's .csi). All the code is actually written in .cs files, but the build is looking for .csi's in specified cases, and the custom Task is doing the pre-processing and generating these 'pre-build'. All I have to do is link my Task into the project in the 'BeforeBuild' targets:
<Project ... >
...
<Target Name="BeforeBuild">
<PreProcessor
Sender="$(RootNamespace).$(AssemblyName)"
Sources="@(Compile)"
/>
</Target>
<UsingTask Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' "
TaskName="PreProcessor"
AssemblyFile="bin\Debug\Com.Cinsault.PreProcessor.dll"
/>
<UsingTask Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' "
TaskName="PreProcessor"
AssemblyFile="bin\Release\Com.Cinsault.PreProcessor.dll"
/>
</Target>
</Project>and the pre-processing of the headers is done before the build starts. I suppose there are just a couple of issues though. The most inconvenient is that, as the coding is done in the .cs file, but the build is working off the intermediate file, then any errors or warnings in VS are pointing to the wrong one, and the line numbers will be out too because of the included header code. The other is that, on the first run, MSBuild must find something for the files that it expects, even if these are empty, otherwise - even though the pre-build Task gets to do it's stuff first - MSBuild is looking ahead and saying "I got nothing to work with here!" Could be useful though, so thanks again. BS