B
BilfFord X
I'm shopping around to figure out where I'm going to devote my finite
energies as I get back into the windows world. A question that pops up
right away for a lot of fellas is, if I'm going to be doing stuff in the dot
net world, do I go c++/CLI or c#. Some people might be able to do both, but
I would go cross-eyed. Legacy code is not as big an issue for me as opposed
to a refusal to leave the c world behind completely. I'm given to believe
that I can wrap c stuff so as to make it compile the way I want, i.e. as ISO
C, and then can make that available to the managed environment. An informed
opinion from nearby was: "If anything, I would interop with it, through the
P/Invoke layer, COM interop, or by creating managed wrappers for it."
This answer raises as many questions as it solves, as, for example, I
thought the managed environment was the end of COM. I was hoping that there
would be persons around here looking at this scenario in their rearview
mirror who might have advice. cheers, bfx
energies as I get back into the windows world. A question that pops up
right away for a lot of fellas is, if I'm going to be doing stuff in the dot
net world, do I go c++/CLI or c#. Some people might be able to do both, but
I would go cross-eyed. Legacy code is not as big an issue for me as opposed
to a refusal to leave the c world behind completely. I'm given to believe
that I can wrap c stuff so as to make it compile the way I want, i.e. as ISO
C, and then can make that available to the managed environment. An informed
opinion from nearby was: "If anything, I would interop with it, through the
P/Invoke layer, COM interop, or by creating managed wrappers for it."
This answer raises as many questions as it solves, as, for example, I
thought the managed environment was the end of COM. I was hoping that there
would be persons around here looking at this scenario in their rearview
mirror who might have advice. cheers, bfx