[Wolves] C++

[Andy Wootton]

Mark Croft wrote:
> yeah visual is like m$ tradename for there group of development
> environments. This gave the impression that C++ was heading towards a
> rapid application development system similar to Visual Basic. I did
> use visual C++ 5 & 6 back in the early 90s when i was an programming ,
> doing C++ embedded modules/AutoLISP APIs(best term I can come up with)
> for autocad (was all quite involved stuff).
> The visual side is that is has a dialog/form tool built into it and in
> turn willl create a load of predefine code to drive the UI etc.
> Obvious being microsoft it was based around a lot of the ideas of how
> to create object oriented code and there a massive Microsoft Class
> Library to deal with things. It was a very steep learning for myself
> being a junior programmer , trying to get to grips with MFC &
> Dialog/form. It was also enjoyable in a sort of geeky way too.
>
> Hope that makes some sense , my english is terrible , why i do not
> both much of the time trying to put my pence worth in and also I still
> really live in the world that I am comfortable and that is still M$
> Windows 2000.
>
> Mark
>
>
> On 10/02/2008, Andrew Lewis <andrew at monkeysailor.co.uk> wrote:
>   
>> baza wrote:
>>     
>>> Might be a stupid question this. But is there any difference between
>>> Visual C++ and 'vanilla' C++?
>>>       
>> As far as I can remember,  Visual C++ is like C++ but with some ms only
>> IDE and libraries to deal will the windows API for drivers, windows
>> callbacks, dll hooking ,etc. I think that the name mangling is also
>> different in MS VC++, but that's just a vague memory from many years ago
>> and might not be the case now.
>>
>> So the short answer is that the core is similar, but the libraries are
>> different.
Is there such a thing as an 'off-topic reply'? If so, this may be one.

I'm currently learning web programming in C# on .NET having last written 
code 20 years ago in BASIC, Pascal and FORTRAN for terminals connected 
to VAXes.
The language is the least of my problems and I suspect that if you've 
used a different C++ the same is going to be true for you.

The .NET environment supports command-line, native Windows (WinForms) 
and web (ASP.NET) coding models. Microsoft are clearly moving towards 
making the experience very similar for each model but they aren't quite 
there yet. Whatever language you code in gets compiled into a common 
intermediate language that runs on a .NET run-time environment. The code 
creation process is to design screens by dragging and dropping icons 
representing 'objects' such as a button or a  table onto a form then to 
double-click on the object and create the 'code-behind' page. The 
biggest problem for a 'newbie' like me is negotiating the object model 
and the huge set of  libraries without much of a map. When something 
goes wrong there is a whole load of code written by magic behind the 
scenes that you haven't ever seen before that may be causing trouble. 
The most worrying thing is that even my experienced colleagues don't 
seem to understand how everything works. Many problems seem to be solved 
by the Windows philosophy of "trying something different until the 
problem goes away".