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.
