Top posted comments moved down here ... |
V
bruce said:
the best is managed C++ as you can add C# entry points and ref .net
objects directly.
Erm, no thanks. I have resisted Microsoft forcibly over the years
because of they are (or have been) extremely keen on vendor "lock in"
and non-portable code. I think even the great Redmond company have
realized the futility of this approach in todays open standards world -
and AFAIk, they've canned this silly language along with its bizzare
non-standard "C++" syntax.
the second best is use simple objects and use pinvoke from c# to call
the C++ code. if you use winapi standard entry points, you can just use
C# declarations to call the libraries.
This looks like the most viable option - although I was (somehow) hoping
I could get around marshalling large chunks of data around.
the last is to use com. this requires discipline in C# to release ref
counters when done (the GC will do it automactally but usually not soon
enough).
Also a potential contender as I can easily right ATL COM wrappers around
my C++ classes), I was hoping this would provide tighter integration -
since the (C#) syntax i've seen so far looked less "exotic" ...., still
I guess I'll have to weigh up the Pros and con's (i.e. workload) between
the COM wrappers and Pinvoke approach.
there are 4 learning curves:
the .net runtime library which is huge (quick transition if you have
done java).
Yeah C# is (mostly) Java and C++ repackaged and branded as a new language
I've done some Java programming in the past and had to do a "double
take" when I first saw a C# code snippet.
the asp.net page model and events handling. this is really a stateless
request response model. a class instance is created and destroyed for
each request. (a button click is really a request). also as all requests
are handled by the same application, but seperate threads, statics need
be avoided. also as a single request may change threads, no thread local
storage should be used.
Ok, so there is more to it than simple wrapping the classes up. Since
state must somehow be maintained. For "heavy" objects - you can't go
about creating them from scratch at each request - there must be a way
of creating object pools or something similar server side ...
html/css - enough said.
ajax/javascript (WEB 2.0). this is turning into the most important new
technology for web pages.
note: there is probably no advantage in using C++ on a website, release
the blanket.
True, apart from the fact that I have over 10 years worth of custom
business logic in C++ libraries (where it is likely to stay) - until
decompiling code from compiled .Net binaries requires AT LEAST some
effort. At the moment decompilation/deobfuscation (even to the point of
recovering source code comments) is almost TRIVIAL.
