Doxygen seems confused by some C++/CX syntax constructs (the new C++ extensions introduced by Microsoft for Windows 8 development). Is this a known issue? Are there patches to make it work? Or a better doc system to use? (Bear in mind that the code base in question also runs on non-Microsoft platforms.)
Doxygen supports C++/CLI. The C++/CX syntax for declarations is (nearly?) identical to the C++/CLI syntax, so enabling C++/CLI support in the Doxygen options should work fine.
Related
Just discovered Alea.Gpu and am very pleased with its simplicity of use and C# integration.
However I was just wondering if compiler directives such as "__unroll" are available somewhere? It seems that it used to be available in the Alea.CUDA package which seems deprecated.
Any tips ?
Regards
this directive works only for F# quotation based code. It provides kernel as a F# quotation. C# coded kernel is not supported.
For more information on using AleaGPU in F#, see http://www.aleagpu.com/release/3_0_3/doc/advanced_features_fsharp.html
I have some C++/CLI code which derives from the .NET System Namespace classes.
Is there a way to reuse this code for Universal Windows Platform Apps?
I can't get a reference to the System Namespace in C++, though in C# it is possible. It looks like there is only support for C++/Cx code and not for managed C++/CLI.
The syntax and keywords of the C++/CX extension resembles C++/CLI a great deal. But that's where similarity ends, they have nothing whatsoever in common. C++/CX gets compiled directly to native code, just like native C++. But C++/CLI is compiled to MSIL, the intermediate language of .NET. Their syntax looks so similar because they both solve the same problem, interfacing C++ to a foreign type system. .NET's in the case of C++/CLI, WinRT in the case of C++/CX.
Which is the basic reason why you cannot use the System namespace, it is a .NET namespace. You instead use the std namespace, along with the Platform and Windows namespaces for WinRT specific types. The compiler cannot import .NET reference assemblies with the /ZW compile option in effect, only WinRT metadata files, the ones with the .winmd filename extension. Which are an extension to the COM .tlb type library file format, the ones you previously had to import with the #import directive.
Which in itself is another major source for confusion, the internal .winmd file format was based on the format of .NET metadata. Most .NET decompilers can show you the content of a .winmd file because of this. But again just a superficial similarity, it is completely unrelated to a .NET assembly. It can just contain declarations, not code. Best to compare it to a .h file you'd use in a native C++ project. Or a .tlb file if you previously had exposure to COM.
Knowing how COM works can be very helpful to grok what this is all about. It is in fact COM that lies at the core of WinRT, the basic reason why your C++/CX project can be easily used by a program written in a completely different language like Javascript or VB.NET. A WinRT app is actually an out-of-process COM server. A class library or WinRT component is actually an in-process COM server. COM object factories work differently, the scope is limited to the files named in the package manifest. C++/CX is part of the language projection that hides COM, along with the C++ libraries you link that implement the Platform namespaces. WinRT would be still-born if programmers had to write traditional COM client code. You still can in native C++, the WRL library does little to hide the plumbing.
WinRT readily supports code written in a managed language like C# or VB.NET, the language projection is built into the framework and highly invisible. But not C++/CLI, a structural limitation. A Store/Phone/Universal app targets a subset of the .NET Framework named .NETCore. Better known these days as CoreCLR, the parts that were open-sourced. Which does not support module initializers, critical to C++/CLI.
Enough introduction and getting to the answer: no, you have no use for your C++/CLI code and you'll have to rewrite it. You'll have a decent shot at porting the native C++ code that your C++/CLI wrapper interfaced with, as long as it observes the api limitations. You should always start there first, given that it is easy to do and instantly tells you if your native C++ code is using verboten api functions, the kind that drains a battery too quickly or violates the sandbox restrictions.
The ref class wrappers however have to be significantly tweaked. Little reason to assume that will be a major obstacle, it could still structurally be similar. Biggest limitations are the lack of support for implementation inheritance, a COM restriction, and having to replace the code that used .NET Framework types with equivalent C++ code. The typical hangup is that there tends to be a lot of it, the original author would normally have favored the very convenient .NET types over the standard C++ library types. YMMV.
I have read in Foundations of C++ CLI the following:
If you try to compile a native C++
application with /clr:pure, it will
work only if the code being compiled
has no constructs that generate
machine-specific code. You can,
however, link with native libraries.
What is meant by "constructs that generate machine-specific code" ? Example?
Also the book says that this mode is not verifiably safe, so we can use pointers for example, now i am confusing in how can say that the compiler will produce pure MSIL code and also we can use pointers! What i know is that, the pointer is somehow native concept! how it will be made as pure MSIL!?
MSIL is quite powerful, it has no trouble with standard compliant C++03 code. The only "constructs" I know of that it cannot deal with is the __fastcall calling convention, r-value references as implemented in the C++0x additions in VS2010 and obvious machine specific extensions like the __asm keyword (inline assembly) and intrinsics.
Most any native C++ you compile with /clr in effect will use pointers, either explicitly or compiler-generated to implement things like C++ classes and references. MSIL has no trouble with it but that code is not verifiable, any MSIL that uses pointers is rejected by the verifier. This is not necessarily a problem, lots of code runs in full-trust. You'll only get in trouble when you try to run it on sandboxed execution environments, like a browser, a phone or a game console. Or when your customer has a nervous system administrator.
Using /clr:pure is otherwise pretty useless. The point of using C++/CLI is for its great support for interop with native code. Compiling native code to MSIL is largely a waste, the JIT optimizer can't do as effective a job as the native code optimizer.
I want to make an easy to deploy Windows application and was was wondering which programming systems can create totally self contained Windows .exe files?
As a plus, if the same can be done with MacOSX and Linux from the same source this would be a bonus. I took a look at Realbasic but they have since abandoned the single .exe concept.
update: i am looking for something that can run from Windows XP up to Windows 7, no matter what version of .NET is installed. Is this even possible?
Delphi compiles to one executable, and generates native windows executables. So no dependencies to any kind of framework. If you use Free Pascal (fpc) and the Lazarus IDE, you could even develop for Linux and Apple from the same source.
If your using external dll's this would become a bit more tricky, but you could pack them up in your resource file and still maintain the one exe property.
Update 2020: since #Vassilis & #Marco van der Voort commented on this, I would like to update my old andswer and add that go is a very good way to make self-contained executables. Even crossplatform compilation is realy simple.
You can certainly do this with C/C++. Technically the runtime libraries are required, but they should already be installed on any windows, mac or linux system.
With .NET you can compile to an EXE, but of course the .NET framework is required. For newer versions of windows it should be installed by default, but on older versions (XP or older?) it may or may not be there. And of course you couldn't expect mono to be there by default on linux or mac either.
For Windows the following languages are viable:
C (MS, gcc)
C++ (MS, g++, Digital Mars)
D (Digital Mars)
Delphi (Embarcadero??? how do you spell that? just trips off the tongue doesn't it?)
Fortran (Intel, Salford Software)
Visual Basic 6 (MS)
Lua (you'll need a special tool to do it, but it is doable)
C#, VB.Net, F#, J#, etc (assuming that you don't mind using .Net technology)
You can use Tcl/tk. The technology you should research is a "starpack", which combines a runtime executable (a starkit) with a platform-specific runtime (a "tclkit") to create a single-file executable. It's remarkable in the fact that it's not just compiled code, but an entire self-contained virtual filesystem that can include images, sound, data, etc.
This same technology works for many platforms from the same code base. The only thing that is different is the platform-specific runtime. You can even "cross compile" in that you can copy the runtime for multiple platforms onto your dev box and then build starpacks for each platform without having to actually be on each platform.
Tcl can do this, especially through producing starpacks. They can be produced for all platforms from the same code. Note that this also includes all the necessary runtime libraries (except for things like the C library, but you don't want to make that static under normal circumstances).
JavaFX 2.2 supports that. It allows creation of self-contained applications targeting Windows, Mac OS, and Linux.
Please follow this link for more information: http://docs.oracle.com/javafx/2/deployment/self-contained-packaging.htm.
I would recommend taking a look at AutoIt. It is an easy-to-use scripting language that will compile into an exe, so there are no runtimes needed. This would be for windows only though.
http://www.autoitscript.com/autoit3/index.shtml
From the website:
AutoIt v3 is a freeware BASIC-like
scripting language designed for
automating the Windows GUI and general
scripting. ... AutoIt is also very small,
self-contained and will run on all
versions of Windows out-of-the-box
with no annoying "runtimes" required!
c/c++
purebasic
delphi
vb6
i hope this help :)
Here's a good source for a number of basic-like programming languages that build small stand-alone EXEs. Some are cross-platform for Windows and Linux:
www.basic.mindteq.com
You can use Liberty Basic which is easy and cheap, you can easily make stand alone programs for windows but not possible to transfer to MacOS or Linux.
You can do this for Windows with .NET languages using ILMerge
ILMerge is a utility for merging multiple .NET assemblies into a single .NET assembly. It works on executables and DLLs alike and comes with several options for controlling the processing and format of the output. See the accompanying documentation for details.
However:
Currently, ILMerge works only on Windows-based platforms. It does not yet support Rotor or Mono.
QBasic can :-)
I wrote a few command line tools using it!
Long winded title, short question:
If one wants to develop for Windows but not have to rely on any external dependency (no runtime, thus ruling out .net), what supported, alive and fully functioning* alternatives are there?
Visual Basic 6 is dead, Visual C++ is obvious and Delphi seems to be the prime choice for that, but I wonder if there are any other alternatives?
*as in: Being able to use all the Windows Features like putting an icon in the Notification Area, making the Taskbar Icon flash etc.
Have a look at this -
http://www.codegear.com/products/delphi
Glynn
C (lots of compilers available)
D using D compiler
eiffel using SmartEiffel*
(*note SmartEiffel interprets eiffel, and generates ANSI C code, which can be compiled with any standard C compiler. It also generates Java byte code.)
Ada compiled with gnat
C/C++ with Borland, if you don't want to be entirely beholden to MS.
Mercury using the Mercury compiler (compiles to ANSI C, which can then be compiled to native code)
Modula 2 using modula2 compiler
Pascal with FreePascal compiler
Vala (compiles to ANSI C)
Haskell using GHC. Compiles via C or direct to native code requiring no special libraries.
Have a look at this page:
http://dada.perl.it/shootout/
It's a port of the computer language shootout to compile on the Win32 platform. In the chart of languages used, he lists which ones compile to native code (the compiler is listed in bold italics). I did notice that he listed C# and Java as compiling to native code, but that of course is incorrect, so make sure you investigate.
I will list each language separately to allow for individual voting.
Awk using awka*
(*note: awka interprets awk, and generates ANSI C, which can be compiled to native code with any C compiler).
PowerBasic
Forth using BigForth compiler
Haskell using ghc
Modula 3 using Critical Mass *
(*note: compiles to ANSI C, which can compile to native code using any standard C compiler)
OCaml compiled with OCaml compiler
Prolog using Visual Prolog
Ubercode using UberCode compiler
Goo using Goo compiler (generates ANSI C)
REALbasic which gives you the extra benefit of being able to compile for Mac and Linux as well.
I think you should give Qt a try. At least, download the file and run the samples, because it ships with a working example of the Notification area feature as you want.
http://qt-project.org/
MASM32 ( http://masm32.com/ ) if you can live with the licensing agreement.