If I haven't made substantial investment in either C++ or C#, which language
would the experts recommend I become well acquainted with?
Daniel
151  4984 
"Daniel" <ne******@cableone.netwrote in message
news:OZ**************@TK2MSFTNGP03.phx.gbl...
If I haven't made substantial investment in either C++ or C#, which
language would the experts recommend I become well acquainted with?
Java, Ruby, Python
--PA
Daniel wrote:
If I haven't made substantial investment in either C++ or C#, which language
would the experts recommend I become well acquainted with?
First I will make a prediction: the .vc guys will suggest C++ and
the .csharp guys will suggest C#.
:-)
If you want to write general business apps, then I will suggest C#.
If you have special requirements for real time, embedded, device
driver programming and similar then go for C++.
Arne
Pavel A. wrote:
"Daniel" <ne******@cableone.netwrote in message
news:OZ**************@TK2MSFTNGP03.phx.gbl...
>If I haven't made substantial investment in either C++ or C#, which
language would the experts recommend I become well acquainted with?
Java, Ruby, Python
:-)
Arne
Daniel wrote:
If I haven't made substantial investment in either C++ or C#, which language
would the experts recommend I become well acquainted with?
Daniel
Both. I'd choose C++ first because once you learn it C# will be really
easy in comparison. If you want to see immediate results, I'd go for C#
though.
Regards.
I meant which of the two languages C++ or C# should I pursue, if I don't
already have projects I have to support in either one. If I I have to give
support for an application I created in one of those two languages, then
that is the language I have to be most familiar with. Once I use the
language in a substantial project I have to support, I am committed to that
language.
Daniel
"Pavel A." <pa*****@NOwritemeNO.comwrote in message
news:u7****************@TK2MSFTNGP02.phx.gbl...
"Daniel" <ne******@cableone.netwrote in message
news:OZ**************@TK2MSFTNGP03.phx.gbl...
>If I haven't made substantial investment in either C++ or C#, which
language would the experts recommend I become well acquainted with?
Java, Ruby, Python
--PA
VB6 yay.
--
Regards,
Alvin Bruney [MVP ASP.NET]
[Shameless Author plug]
Download OWC Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $15.00
Need a free copy of VSTS 2008 w/ MSDN Premium? http://msmvps.com/blogs/alvin/Default.aspx
-------------------------------------------------------
"Daniel" <ne******@cableone.netwrote in message
news:OZ**************@TK2MSFTNGP03.phx.gbl...
If I haven't made substantial investment in either C++ or C#, which
language would the experts recommend I become well acquainted with?
Daniel
I meant which of the two languages C++ or C# should I pursue, if I don't
already have projects I have to support in either one. If I I have to
give support for an application I created in one of those two languages,
then that is the language I have to be most familiar with. Once I use the
language in a substantial project I have to support, I am committed to
that language.
This is a religious issue and it really depends on what you plan on doing.
That said, for "general-purpose" programming in the Windows world, C# is
usually the way to go these days IMO. I believe the trend has been strongly
moving in that direction for a period of years now. Note (FWIW) that I spent
many years in the C++ trenches.
"Daniel" <ne******@cableone.netwrote in message
news:OZ**************@TK2MSFTNGP03.phx.gbl...
If I haven't made substantial investment in either C++ or C#, which
language would the experts recommend I become well acquainted with?
Java. :)
C++ is well past its heyday. C# is (in my opinion) the best-designed of the
3 languages but is very similar to Java, which is more widely used; you
should at least be acquainted with it.
Does C# have as much meticulous control over the micro matters as C++ does?
Daniel
"Larry Smith" <no_spam@_nospam.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
>I meant which of the two languages C++ or C# should I pursue, if I don't
already have projects I have to support in either one. If I I have to
give support for an application I created in one of those two languages,
then that is the language I have to be most familiar with. Once I use
the language in a substantial project I have to support, I am committed
to that language.
This is a religious issue and it really depends on what you plan on doing.
That said, for "general-purpose" programming in the Windows world, C# is
usually the way to go these days IMO. I believe the trend has been
strongly moving in that direction for a period of years now. Note (FWIW)
that I spent many years in the C++ trenches.
On Thu, 17 Jul 2008 21:28:11 -0700, Daniel <ne******@cableone.netwrote:
Does C# have as much meticulous control over the micro matters as
C++ does?
"Meticulous control" and "micro matters" are not well-defined terminology
in the field of programming. It's not possible to answer that question
without you providing it in a more detailed, less ambiguous way.
In any case, I doubt that's a question you really need an answer to. As
has been explained previously, it really has more to do with what you're
trying to write. While there are specific differences between each
language, with only some exceptions what you can do in one, you can do in
the other. But C# is generally better-suited to dealing with .NET, while
C++ is likely to be better suited if you're having to deal with unmanaged
APIs.
So the proper choice of language has more to do with what you're going to
use it for than in differences between the languages in the abstract.
Pete
MC <fo**************@www.ai.uga.edu.slash.mcwrote:
"Daniel" <ne******@cableone.netwrote in message
news:OZ**************@TK2MSFTNGP03.phx.gbl...
If I haven't made substantial investment in either C++ or C#, which
language would the experts recommend I become well acquainted with?
Java. :)
C++ is well past its heyday. C# is (in my opinion) the best-designed of the
3 languages but is very similar to Java, which is more widely used; you
should at least be acquainted with it.
Java 1.4 and C# 1.0 were very similar, but the languages have diverged
significantly since then. Almost all the new features in C# 2.0 and 3.0
either have no real equivalent in Java (e.g. iterator blocks, nullable
types) or have very significant differences (e.g. generics).
--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon_skeet
C# in Depth: http://csharpindepth.com
On Jul 18, 2:31*am, "Daniel" <newso...@cableone.netwrote:
If I haven't made substantial investment in either C++ or C#, which language
would the experts recommend I become well acquainted with?
It's well worth knowing both, but knowing C++ well is going to take
much more time and energy. I'd suggest learning C# first, still -
moving from C++ to C# is often more of a pain than it seems.
"Arne Vajhøj" <ar**@vajhoej.dkha scritto nel messaggio
news:48***********************@news.sunsite.dk...
First I will make a prediction: the .vc guys will suggest C++ and
the .csharp guys will suggest C#.
:-)
I'm a .vc guy :-)
If you want to write general business apps, then I will suggest C#.
I agree with that.
If you have special requirements for real time, embedded, device
driver programming and similar then go for C++.
Moreover, if you want to build Windows shell extensions, you should use C++.
If you want crossplatform code, you should use C++ (with proper libraries
like wxWidgets for the GUI).
If you want to build small .exe's easy to deploy (no need of huge runtime to
distribute), you should use C++ (with CRT/MFC/ATL statically linked).
If you learn C++ first, then moving to C# is a very easy path, as others
wisely wrote.
Instead, the opposite is not true.
Both languages have pro's and con's: choose the better tool for your
particular job.
Giovanni
On Jul 18, 2:31*am, "Daniel" <newso...@cableone.netwrote:
If I haven't made substantial investment in either C++ or C#, which language
would the experts recommend I become well acquainted with?
By the way, one reason why a .NET developer might want to learn C++ or
at least C is to be able to write MSI custom actions for installers
(while it's possible to create managed actions, there is a number of
issues and technical difficulties associated with them).
In article news:<OZ**************@TK2MSFTNGP03.phx.gbl>, Daniel wrote:
If I haven't made substantial investment in either C++ or C#, which
language would the experts recommend I become well acquainted with?
It depends what you want to do, and where you want to do it.
C++ is the more powerful language but there is more to learn, C# is
relatively simple but less powerful. OTOH there are more productivity
tools for C# (largely because it has a simpler syntax, so the tools are
easier to write).
C++ can be used to write software for a huge range of systems -- not
only Windows but also Mac, linux and others (including mini and
mainframe computers, and embedded systems). C# targets a virtual machine
architecture, so C# programs can run only on computers for which such a
runtime (a JIT compiler or an interpreter) is available -- that means
Windows, certainly, and platforms that support Mono (an Open Source
NET-compatible runtime); but not nearly so many as can run C++
programs.
C++ can be used to write system-level code: operating systems, device
drivers, etc.. Although there are research projects and proof of concept
implementation that use C# for these things, current C# implementations
do not allow C# to be used for this kind of work with mainstream OSes --
you can't write even a Windows device driver in C#. If you want to do
driver work then choose C++ (or even C).
A good implementation plan is to write your back-end code -- the
business logic of your application -- in a fast portable language (such
as C++) so that it can be built to run on the maximum possible number of
platforms, and then to write a GUI wrapper around it for each platform
on which you want to ship ... you might choose to write such a GUI
wrapper in C# for a Windows version of your software, though other
possibilities (including VB, Java, Python, etc) exist.
Alternatively you could write your application logic in a webserver
format and use your platform's browser for the GUI, which would save you
writing any platform-specific GUI code at all.
Personally, I usually write the application back-end in C++ and then
write the Windows-specific GUI wrapper in C++ using MFC ... but then I'm
from a C++ background and I just do what comes naturally.
Cheers,
Daniel.
"Daniel James"
C# targets a virtual machine
architecture, so C# programs can run only on computers for which such a
runtime (a JIT compiler or an interpreter) is available -- that means
Windows, certainly, and platforms that support Mono (an Open Source
NET-compatible runtime);
I've heard about Mono before. But I wonder: what is the level of
implementation of Mono?
Is Mono as robust as the Microsoft .NET framework implementation?
Does Mono fully support C# 3?
Does Mono fully support .NET Framework 3.5 ?
Thanks,
Giovanni
On Fri, 18 Jul 2008 11:46:56 +0200, Giovanni Dicanio wrote:
I've heard about Mono before. But I wonder: what is the level of
implementation of Mono?
Is Mono as robust as the Microsoft .NET framework implementation?
A lot of the .net framework is directly from Microsoft. A lot is
implemented a totally different way. I expect that it will be very
compliant as time progresses just not now.
Does Mono fully support C# 3?
I cannot compile anymore:
[Task:File=/home/ken/projects/Capture/Capture/inMatch.cs, Line=266,
Column=32, Type=Error, Priority=Normal, Description=Feature `query
expressions' cannot be used because it is not part of the C# 2.0 language
specification(CS1644)]
Does Mono fully support .NET Framework 3.5 ?
definitely not.
Mono is about portability you have to build with that in mind and you can
be fully portable. I write my test classes on Console and run them on
Linux as well. I have socket based tests and I need two machine to make
it work.
Ken
Daniel wrote:
If I haven't made substantial investment in either C++ or C#, which language
would the experts recommend I become well acquainted with?
Daniel:
As you are posting in dotnet groups, you should know that there are actually
three languages
C++
C#
C++/CLI
Up to now you have been using C++/CLI, which is the wrong choice if you want to
write GUI Windows applications, because Microsoft no longer recommends C++/CLi
for writing GUI .NET applications.
Assuming that you want to write GUI applications for Windows, you need a library.
If you use native C++, you will probably want to use the MFC library (which does
not come with VC Express. by the way). MFC is old, and not very elegant, and has
quite a learning curve. But there is a huge base of available code samples for
it, and Microsoft is once again working on improving it (after many years of
neglect). MFC is not portable to other platforms, but if you separate the
back-end of your application from the GUI, you can port the back-end to other
platforms such as MAC/linux. For me, one of the advantages of going the MFC
route is that you can use static linking, which means that you can deploy
without installing any components on the target machine.
[Note that the main newsgroups for standard C++ are microsoft.public.vc.language
and microsoft.public.vc.mfc]
If you use C#, you will use the .NET library, which is more elegant, and
probably easier to learn than MFC. If you go this route, you need to make sure
that the appropriate version of the .NET framework is installed on the target
system.
There are also hybrid methods, where you write your back-end in standard C++,
the GUI in C#, and build an interface layer using C++/CLI. This may be
appropriate if you have a large amount of legacy C++ code, but it means you have
to learn and understand three languages.
Feel free to ask more questions. This is an important decision, and you should
be sure you make the one that is correct for you.
--
David Wilkinson
Visual C++ MVP
Ken Foskey wrote:
On Fri, 18 Jul 2008 11:46:56 +0200, Giovanni Dicanio wrote:
>I've heard about Mono before. But I wonder: what is the level of
implementation of Mono?
Is Mono as robust as the Microsoft .NET framework implementation?
A lot of the .net framework is directly from Microsoft. A lot is
implemented a totally different way. I expect that it will be very
compliant as time progresses just not now.
>Does Mono fully support C# 3?
I cannot compile anymore:
[Task:File=/home/ken/projects/Capture/Capture/inMatch.cs, Line=266,
Column=32, Type=Error, Priority=Normal, Description=Feature `query
expressions' cannot be used because it is not part of the C# 2.0
language specification(CS1644)]
Sounds like a command line option, or lack thereof, put you in C# 2
compatibility mode. Certainly the compiler wouldn't be describing a feature
such as LINQ query expressions if it didn't understand it.
>
>Does Mono fully support .NET Framework 3.5 ?
definitely not.
Mono is about portability you have to build with that in mind and you
can be fully portable. I write my test classes on Console and run
them on Linux as well. I have socket based tests and I need two
machine to make it work.
Ken
Assuming that you want to write GUI applications for Windows, you
need a library.
If you use native C++, you will probably want to use the MFC library
(which does not come with VC Express. by the way). MFC is old, and
not very elegant, and has quite a learning curve. But there is a huge
ATL/WTL follow modern C++ principles much better than MFC, and should
probably be the library of choice for C++ Windows-only GUI.
base of available code samples for it, and Microsoft is once again
working on improving it (after many years of neglect). MFC is not
portable to other platforms, but if you separate the back-end of your
application from the GUI, you can port the back-end to other
platforms such as MAC/linux. For me, one of the advantages of going
the MFC route is that you can use static linking, which means that
you can deploy without installing any components on the target
machine.
[Note that the main newsgroups for standard C++ are
microsoft.public.vc.language and microsoft.public.vc.mfc]
If you use C#, you will use the .NET library, which is more elegant,
and probably easier to learn than MFC. If you go this route, you need
to make sure that the appropriate version of the .NET framework is
installed on the target system.
There are also hybrid methods, where you write your back-end in
standard C++, the GUI in C#, and build an interface layer using
C++/CLI. This may be appropriate if you have a large amount of legacy
C++ code, but it means you have to learn and understand three
languages.
Feel free to ask more questions. This is an important decision, and
you should be sure you make the one that is correct for you.
On Jul 18, 2:56*pm, "Ben Voigt [C++ MVP]" <r...@nospam.nospamwrote:
[Task:File=/home/ken/projects/Capture/Capture/inMatch.cs, Line=266,
Column=32, Type=Error, Priority=Normal, Description=Feature `query
expressions' cannot be used because it is not part of the C# 2.0
language specification(CS1644)]
Sounds like a command line option, or lack thereof, put you in C# 2
compatibility mode. *Certainly the compiler wouldn't be describing a feature
such as LINQ query expressions if it didn't understand it.
Indeed, you need the command line option -langversion:linq but to
quote the documentation:
<quote>
This enables the C# 3.0 support. Only a few features of C# 3.0 have
been implemented in the Mono C# compiler, so not everything is
available.
</quote>
:(
Jon
>Assuming that you want to write GUI applications for Windows, you
>need a library.
If you use native C++, you will probably want to use the MFC library
(which does not come with VC Express. by the way). MFC is old, and
not very elegant, and has quite a learning curve. But there is a huge
ATL/WTL follow modern C++ principles much better than MFC, and should
probably be the library of choice for C++ Windows-only GUI.
WTL still wasn't officially supported by MSFT the last time I worked with it
(3+ years ago now). There was also no documentation. A quick check and it
still doesn't appear to be supported. This may or may not affect someone's
decision to use it but it is a serious consideration. I do agree however
that it's better than MFC which I abandoned in favour of WTL. Note however
that ATL is incredibly arcane and very difficult to master. It's not for the
weak and most programmers can't handle it. People who care about the
integrity of their programs should seriously consider other choices before
choosing it (and there aren't many unfortunately).
Ben Voigt [C++ MVP] wrote:
ATL/WTL follow modern C++ principles much better than MFC, and should
probably be the library of choice for C++ Windows-only GUI.
Ben:
Yes, I think about this sometimes. But I am not sure that WTL provides as many
features as MFC, and it is not supported by Microsoft, which makes me nervous. I
also have a huge investment in MFC, both in knowledge and code base. I wish MFC
were more elegant, but I have gotten used to it.
If this old programmer is going to learn something new, I think it's going to be
C# and .NET.
--
David Wilkinson
Visual C++ MVP
I had forgotten the proper terminology. I meant to ask whether C# was a low
level language to the same extent as C++.
Daniel
"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...
On Thu, 17 Jul 2008 21:28:11 -0700, Daniel <ne******@cableone.netwrote:
>Does C# have as much meticulous control over the micro matters as C++
does?
"Meticulous control" and "micro matters" are not well-defined terminology
in the field of programming. It's not possible to answer that question
without you providing it in a more detailed, less ambiguous way.
In any case, I doubt that's a question you really need an answer to. As
has been explained previously, it really has more to do with what you're
trying to write. While there are specific differences between each
language, with only some exceptions what you can do in one, you can do in
the other. But C# is generally better-suited to dealing with .NET, while
C++ is likely to be better suited if you're having to deal with unmanaged
APIs.
So the proper choice of language has more to do with what you're going to
use it for than in differences between the languages in the abstract.
Pete
ok. Thanks.
"Giovanni Dicanio" <gdicanio@_NOSPAM_email_DOT_itwrote in message
news:uy**************@TK2MSFTNGP04.phx.gbl...
>
"Arne Vajhøj" <ar**@vajhoej.dkha scritto nel messaggio
news:48***********************@news.sunsite.dk...
>First I will make a prediction: the .vc guys will suggest C++ and
the .csharp guys will suggest C#.
:-)
I'm a .vc guy :-)
>If you want to write general business apps, then I will suggest C#.
I agree with that.
>If you have special requirements for real time, embedded, device
driver programming and similar then go for C++.
Moreover, if you want to build Windows shell extensions, you should use
C++.
If you want crossplatform code, you should use C++ (with proper libraries
like wxWidgets for the GUI).
If you want to build small .exe's easy to deploy (no need of huge runtime
to distribute), you should use C++ (with CRT/MFC/ATL statically linked).
If you learn C++ first, then moving to C# is a very easy path, as others
wisely wrote.
Instead, the opposite is not true.
Both languages have pro's and con's: choose the better tool for your
particular job.
Giovanni
What is MSI? What do you mean by "MSI custom actions"?
Daniel
"Pavel Minaev" <in****@gmail.comwrote in message
news:f2**********************************@z16g2000 prn.googlegroups.com...
On Jul 18, 2:31 am, "Daniel" <newso...@cableone.netwrote:
If I haven't made substantial investment in either C++ or C#, which
language
would the experts recommend I become well acquainted with?
By the way, one reason why a .NET developer might want to learn C++ or
at least C is to be able to write MSI custom actions for installers
(while it's possible to create managed actions, there is a number of
issues and technical difficulties associated with them).
Thanks.
"David Wilkinson" <no******@effisols.comwrote in message
news:ee**************@TK2MSFTNGP03.phx.gbl...
Daniel wrote:
>If I haven't made substantial investment in either C++ or C#, which
language would the experts recommend I become well acquainted with?
Daniel:
As you are posting in dotnet groups, you should know that there are
actually three languages
C++
C#
C++/CLI
Up to now you have been using C++/CLI, which is the wrong choice if you
want to write GUI Windows applications, because Microsoft no longer
recommends C++/CLi for writing GUI .NET applications.
Assuming that you want to write GUI applications for Windows, you need a
library.
If you use native C++, you will probably want to use the MFC library
(which does not come with VC Express. by the way). MFC is old, and not
very elegant, and has quite a learning curve. But there is a huge base of
available code samples for it, and Microsoft is once again working on
improving it (after many years of neglect). MFC is not portable to other
platforms, but if you separate the back-end of your application from the
GUI, you can port the back-end to other platforms such as MAC/linux. For
me, one of the advantages of going the MFC route is that you can use
static linking, which means that you can deploy without installing any
components on the target machine.
[Note that the main newsgroups for standard C++ are
microsoft.public.vc.language and microsoft.public.vc.mfc]
If you use C#, you will use the .NET library, which is more elegant, and
probably easier to learn than MFC. If you go this route, you need to make
sure that the appropriate version of the .NET framework is installed on
the target system.
There are also hybrid methods, where you write your back-end in standard
C++, the GUI in C#, and build an interface layer using C++/CLI. This may
be appropriate if you have a large amount of legacy C++ code, but it means
you have to learn and understand three languages.
Feel free to ask more questions. This is an important decision, and you
should be sure you make the one that is correct for you.
--
David Wilkinson
Visual C++ MVP
On Fri, 18 Jul 2008 09:40:45 -0700, Daniel <ne******@cableone.netwrote:
I had forgotten the proper terminology. I meant to ask whether C# was a
low
level language to the same extent as C++.
I guess I would describe C++ as being "lower level" than C#. However, if
you're writing .NET code the difference doesn't matter. C++ has roughly
the same degree of "high level" features that C# has and vice a versa, and
even in C# you can write "unsafe" code to do certain "low level" things.
The main limitation with C# is that if you write C# code, it has to
execute in the managed environment, which excludes it from certain kinds
of applications (already discussed elsewhere in these threads).
Pete
On Jul 18, 1:36*pm, Daniel James <wastebas...@nospam.aaisp.orgwrote:
A good implementation plan is to write your back-end code -- the
business logic of your application -- in a fast portable language (such
as C++) so that it can be built to run on the maximum possible number of
platforms, and then to write a GUI wrapper around it for each platform
on which you want to ship ... you might choose to write such a GUI
wrapper in C# for a Windows version of your software, though other
possibilities (including VB, Java, Python, etc) exist.
I disagree about the "business logic in C++" part. In practice,
standard C++ tends to be too low-level, verbose, and overcomplicated
for many common patterns that arise when developing a typical business
layer in many desktop and LOB applications. I'd still recommend C# for
that.
Leave C++ for tightly optimized algorithm implementations, device
drivers, shell plugins, MSI custom actions, etc.
On Jul 18, 1:52*pm, Pavel Minaev <int...@gmail.comwrote:
On Jul 18, 1:36*pm, Daniel James <wastebas...@nospam.aaisp.orgwrote:
A good implementation plan is to write your back-end code -- the
business logic of your application -- in a fast portable language (such
as C++) so that it can be built to run on the maximum possible number of
platforms, and then to write a GUI wrapper around it for each platform
on which you want to ship ... you might choose to write such a GUI
wrapper in C# for a Windows version of your software, though other
possibilities (including VB, Java, Python, etc) exist.
I disagree about the "business logic in C++" part. In practice,
standard C++ tends to be too low-level, verbose, and overcomplicated
for many common patterns that arise when developing a typical business
layer in many desktop and LOB applications. I'd still recommend C# for
that.
Leave C++ for tightly optimized algorithm implementations, device
drivers, shell plugins, MSI custom actions, etc.
On the low level stuff. What exactly is the "lowest" level in Windows
C++. I don't mean assembly or machine language. I mean if I wanted
to know how graphics are really drawn on the screen. What would I
look at? I know I can use C++ to createwindow or something like it,
but how is it doing it? Is that part in C or C++? Is that the hidden
source code that Microsoft uses?
Thanks.
On Fri, 18 Jul 2008 11:00:29 -0700, jmDesktop <ne***********@gmail.com>
wrote:
On the low level stuff. What exactly is the "lowest" level in Windows
C++.
First, let's straighten out some terminology: I don't feel that there's
any such thing as "Windows C++". C++ is a language, Windows is an
operating system with an API (or, a lot of different APIs, depending on
how you look at it :) ).
The majority of the Windows API has nothing at all to do with C++. It's
all accessible by C or other similar purely procedural, non-OOP
languages. Even where the Windows API starts to look like C++ (e.g. COM,
GDI+), you can in fact get by without C++ albeit with more complicated
code (since you have to write explicitly the things that C++ would do for
you).
So it's important to be clear about whether you're talking about the
Windows API and if so what part, or if you're talking about a language and
if so, why it is a particular language is of particular interest.
I don't mean assembly or machine language. I mean if I wanted
to know how graphics are really drawn on the screen. What would I
look at?
That's a pretty vague question. The most literal answer is "the graphics
driver". That's the part of the operation system that actually interfaces
directly with the video hardware, and it's the only thing that really
knows "how graphics are really drawn on the screen".
I know I can use C++ to createwindow or something like it,
CreateWindow() doesn't draw graphics. It just sets up an OS object that
provides for a specific kind of way to draw graphics.
but how is it doing it?
How is what doing what? That's a lot of pronouns without any clear
antecedent.
Pete
David Wilkinson wrote:
Ben Voigt [C++ MVP] wrote:
>ATL/WTL follow modern C++ principles much better than MFC, and should
probably be the library of choice for C++ Windows-only GUI.
Ben:
Yes, I think about this sometimes. But I am not sure that WTL
provides as many features as MFC, and it is not supported by
Microsoft, which makes me nervous. I also have a huge investment in
MFC, both in knowledge and code base. I wish MFC were more elegant,
but I have gotten used to it.
I guess I didn't actually say "for new C++ code". I meant to though. There
are certainly good reasons to keep an existing MFC application as MFC that
probably outweigh any benefits of WTL.
>
If this old programmer is going to learn something new, I think it's
going to be C# and .NET.
On Jul 18, 2:20*pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
On Fri, 18 Jul 2008 11:00:29 -0700, jmDesktop <needin4mat...@gmail.com*
wrote:
On the low level stuff. *What exactly is the "lowest" level in Windows
C++.
First, let's straighten out some terminology: I don't feel that there's *
any such thing as "Windows C++". *C++ is a language, Windows is an *
operating system with an API (or, a lot of different APIs, depending on *
how you look at it :) ).
The majority of the Windows API has nothing at all to do with C++. *It's *
all accessible by C or other similar purely procedural, non-OOP *
languages. *Even where the Windows API starts to look like C++ (e.g. COM, *
GDI+), you can in fact get by without C++ albeit with more complicated *
code (since you have to write explicitly the things that C++ would do for*
you).
So it's important to be clear about whether you're talking about the *
Windows API and if so what part, or if you're talking about a language and *
if so, why it is a particular language is of particular interest.
I don't mean assembly or machine language. *I mean if I wanted
to know how graphics are really drawn on the screen. *What would I
look at?
That's a pretty vague question. *The most literal answer is "the graphics *
driver". *That's the part of the operation system that actually interfaces *
directly with the video hardware, and it's the only thing that really *
knows "how graphics are really drawn on the screen".
I know I can use C++ to createwindow or something like it,
CreateWindow() doesn't draw graphics. *It just sets up an OS object that *
provides for a specific kind of way to draw graphics.
but how is it doing it?
How is what doing what? *That's a lot of pronouns without any clear *
antecedent.
Pete
How is a windows drawn on the screen? Is that where the OS provided
APIs come in (we don't need to know how they work)?
Ben Voigt [C++ MVP] wrote:
I guess I didn't actually say "for new C++ code". I meant to though. There
are certainly good reasons to keep an existing MFC application as MFC that
probably outweigh any benefits of WTL.
No, I'm certainly not going to rewrite my existing MFC applications. But even if
I were to start a new GUI application, I would probably go with MFC because I
know what to do, and have a bunch of supporting code ready to go, etc.
To use WTL or C#/.NET I would have to learn a bunch of stuff, and of the two I
think I would go with C#.
Fortunately most of my consulting work is cross-platform non-GUI C++, si I do
not need to worry about this. The code is developed in Visual Studio, but runs
as a console application in various linux/Unix systems, as well as Windows. My
client also wraps it in C++/CLI for Windows GUI with C#, but I am not
responsible for that.
--
David Wilkinson
Visual C++ MVP
On Fri, 18 Jul 2008 11:59:48 -0700, jmDesktop <ne***********@gmail.com>
wrote:
How is a windows drawn on the screen? Is that where the OS provided
APIs come in (we don't need to know how they work)?
Again, it depends. The question is too vague to answer, because there are
a variety of ways a window could be drawn on the screen.
That said, for the typical, mainstream Windows application, yes...the OS
itself provides the implementation that actually draws the window-specific
graphics on the screen. This includes things like the frame, titlebar,
menu, scrollbars, etc.
An application uses this built-in functionality, and then optionally
provides its own customized drawing for the "client" area of the window.
Where it doesn't provide customized drawing, it usually simply adds "child
windows" (in a .NET Forms application, this is in the form of Control
sub-classes) to the main window, and each child window implements its own
drawing (again, as part of the OS API and implementation).
Pete
Actually, VB.NET usage has surpassed C#. Thought I would point that out,
this came from a forester survey if memory serves me correctly.
--
Regards,
Alvin Bruney [MVP ASP.NET]
[Shameless Author plug]
Download OWC Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $15.00
Need a free copy of VSTS 2008 w/ MSDN Premium? http://msmvps.com/blogs/alvin/Default.aspx
-------------------------------------------------------
"Larry Smith" <no_spam@_nospam.comwrote in message
news:#q**************@TK2MSFTNGP02.phx.gbl...
>I meant which of the two languages C++ or C# should I pursue, if I don't
already have projects I have to support in either one. If I I have to
give support for an application I created in one of those two languages,
then that is the language I have to be most familiar with. Once I use
the language in a substantial project I have to support, I am committed
to that language.
This is a religious issue and it really depends on what you plan on doing.
That said, for "general-purpose" programming in the Windows world, C# is
usually the way to go these days IMO. I believe the trend has been
strongly moving in that direction for a period of years now. Note (FWIW)
that I spent many years in the C++ trenches.
Peter Duniho wrote:
The majority of the Windows API has nothing at all to do with C++. It's
all accessible by C or other similar purely procedural, non-OOP
languages. Even where the Windows API starts to look like C++ (e.g.
COM, GDI+), you can in fact get by without C++ albeit with more
complicated code (since you have to write explicitly the things that C++
would do for you).
COM in C sounds as about as much fun as 1000 meter swimming with
50 pounds of lead ...
Unlike Win32 API then COM is intended for C++ (or other OO language).
Arne
Pavel Minaev wrote:
On Jul 18, 2:31 am, "Daniel" <newso...@cableone.netwrote:
>If I haven't made substantial investment in either C++ or C#, which language
would the experts recommend I become well acquainted with?
By the way, one reason why a .NET developer might want to learn C++ or
at least C is to be able to write MSI custom actions for installers
(while it's possible to create managed actions, there is a number of
issues and technical difficulties associated with them).
There are several type of code where C++ is either better or
plain necessary.
But is "write MSI custom actions for installers" really a common task ?
Arne
Ken Foskey wrote:
On Fri, 18 Jul 2008 11:46:56 +0200, Giovanni Dicanio wrote:
>I've heard about Mono before. But I wonder: what is the level of
implementation of Mono?
Is Mono as robust as the Microsoft .NET framework implementation?
A lot of the .net framework is directly from Microsoft. A lot is
implemented a totally different way.
AFAIK then no code at all in Mono comes from Microsoft.
Arne
Giovanni Dicanio wrote:
"Daniel James"
>C# targets a virtual machine
architecture, so C# programs can run only on computers for which such a
runtime (a JIT compiler or an interpreter) is available -- that means
Windows, certainly, and platforms that support Mono (an Open Source
NET-compatible runtime);
I've heard about Mono before. But I wonder: what is the level of
implementation of Mono?
Is Mono as robust as the Microsoft .NET framework implementation?
Does Mono fully support C# 3?
Does Mono fully support .NET Framework 3.5 ?
http://mono.ximian.com/class-status/ http://www.mono-project.com/Mono_Project_Roadmap
should provide you with some info.
Arne
Alvin Bruney [ASP.NET MVP] wrote:
Actually, VB.NET usage has surpassed C#. Thought I would point that out,
this came from a forester survey if memory serves me correctly.
There were indeed a Forrester report claiming that.
But it does not match very well with what people observe. Try search
for C# and VB.NET at your favorite job site and see how many hits
you find. There are practically always about twice as many C# jobs as
VB.NET jobs.
Arne
[David Wilkinson]
Fortunately most of my consulting work is cross-platform non-GUI C++, si I
do not need to worry about this. The code is developed in Visual Studio,
but runs as a console application in various linux/Unix systems, as well
as Windows. My client also wraps it in C++/CLI for Windows GUI with C#,
but I am not responsible for that.
Do you know if it is possible to throw native C++ exceptions from the C++
layer, and directly catch them at the C++/CLI or C# layer?
Or must the C++/CLI layer catch all native C++ exceptions (like those
derived from std::exception) and rethrow them in a different form, derived
from managed base exception class System.Exception ?
Thanks,
Giovanni
In article news:<#Q**************@TK2MSFTNGP03.phx.gbl>, Daniel wrote:
I had forgotten the proper terminology. I meant to ask whether C# was
a low
level language to the same extent as C++.
The short, quick, easy answer is: "No".
In fact, that's largely an artefact of the way that C# is currently
implemented, not of the language itself. It's possible to conceive of a
C# implementation that generated native code which could -- with a
little library support -- be just as low-level as C++. There are
research projects that use such implementations of C# to implement OSes
... but nothing mainstream.
For all practical purposes the quick answer should suffice.
Cheers,
Daniel.
In article
news:<28**********************************@r66g200 0hsg.googlegroups.com>
, Pavel Minaev wrote:
I disagree about the "business logic in C++" part. In practice,
standard C++ tends to be too low-level, verbose, and overcomplicated
for many common patterns that arise when developing a typical business
layer in many desktop and LOB applications.
I would have to disagree.
There is a lot of C++ code about that is lower-level than it needs to
be. When sensibly used C++ can result in code that is every bit as
high-level an abstraction of the business logic as you get with C#.
Sure, bad C++ programming will lead to a poor abstraction and
overcomplex code, but so will bad programming in any language.
Cheers,
Daniel.
In article news:<ee**************@TK2MSFTNGP03.phx.gbl>, David Wilkinson
wrote:
C++/CLI ... is the wrong choice if you want to write GUI Windows
applications, because Microsoft no longer recommends C++/CLi
for writing GUI .NET applications.
If you are an experienced C++ programmer but know no C# (or other .NET
language) and you want to write an application for the .NET runtime that
has some GUI functionality but a lot more back-end logic it might well
be ideal to use C++/CLI for the whole thing. There are no hard-and-fast
rules, here, just a lot of technologies that can play together or on
their own and which have different strengths and weaknesses.
It's perfectly possibly to use C++/CLI to write GUI .NET applications --
it wouldn't be everybody's choice (for a number of good reasons) but it
is certainly possible ... and what Microsoft "recommend" shouldn't play
a big part in your decision-making process. Their recommendations are
often more political than technical, and in any case can't consider the
specific technical factors affecting any individual case.
For that matter: I don't think I've seen any definitive statement from
Microsoft saying that C++/CLI is no longer recommended for GUI .NET
applications ... can you provide a reference/link for that?
If you use native C++, you will probably want to use the MFC library
...
That's certainly a valid choice, and a reasonable one for a native C++
application that's limited to the Windows platform.
Other good choices would be Qt or the wxWdigets libraries which also
target other OSes, such as linux and MacOS.
There are also hybrid methods, where you write your back-end in
standard C++, the GUI in C#, and build an interface layer using
C++/CLI. This may be appropriate if you have a large amount of
legacy C++ code ...
Yes, indeed. It's also an appropriate strategy if you want your back-end
code to be portable to ther systems but want to code a platform-specific
GUI for each target system to take best advantage of the facilities of
each platform. The Windows front-end can then be C# (or whatever takes
your fancy), and you can use other tools for other platforms.
Cheers,
Daniel.
Giovanni Dicanio wrote:
Do you know if it is possible to throw native C++ exceptions from the C++
layer, and directly catch them at the C++/CLI or C# layer?
Or must the C++/CLI layer catch all native C++ exceptions (like those
derived from std::exception) and rethrow them in a different form, derived
from managed base exception class System.Exception ?
Giovanni:
I don't know about that. The code I am talking about is a mathematical library
that uses exceptions (derived from std::exception) internally, but catches them
and converts them to error codes for the client.
--
David Wilkinson
Visual C++ MVP
On Jul 19, 5:11*am, Arne Vajhøj <a...@vajhoej.dkwrote:
There are several type of code where C++ is either better or
plain necessary.
But is "write MSI custom actions for installers" really a common task ?
If you develop desktop applications, you typically have to make
installers for them. And, yes, given the limitations of Windows
Installer, it often requires one to write a custom action to do a
particular check or operation.
"David Wilkinson" <no******@effisols.comha scritto nel messaggio
news:eq****************@TK2MSFTNGP02.phx.gbl...
Giovanni:
I don't know about that. The code I am talking about is a mathematical
library that uses exceptions (derived from std::exception) internally, but
catches them and converts them to error codes for the client.
Thanks David.
Giovanni This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Rob |
last post by:
i know javascript, vbscript, asp css and alot more and im only 14 i was
wondering which is easier to learn php or cgi. any help?
|
by: Bicho Verde |
last post by:
I have now free time and money to do what I want :-)
I have some basic skills in programming (C, Pascal, Macromedia
Actionscript) but don't know exactly what to do in the world of programming.
And...
|
by: Elijah |
last post by:
I have read many of the topics on learning C++ or Java first.
It seems like everyone says something different.
I would like to know if I should learn C++ or Java.
First a little about myself.
I...
|
by: Rhino |
last post by:
I am giving some thought to applying for some jobs that want people with
Java and C++ experience. I have been writing Java for several years and am
fluent enough that I don't have to get help with...
|
by: Hermawih |
last post by:
Hello ,
I want your opinion about this .
In order to say it clearly , I think I have to describe it in long sentences .
I could consider myself as Intermediate/Advance Access Developer ;...
|
by: TAM |
last post by:
Hi,
I read that ASP.NET uses VB.NET instead of VBScript. I also read that
ASP.NET is a subset of VB.NET. So if I learn VB.NET first then do I have the
knowledge for programming ASP.NET...
|
by: abhi |
last post by:
hi everybody am new to this group and help me to learn C
|
by: anand devarajan |
last post by:
hi friends,
im anand im just a beginner in c learning for the past two
weeksnow i can write simple prgs can anyone help me to get well known
to c lang so that i should able to write even tough...
|
by: pandit |
last post by:
hai all,
i want to become a good programmer. one of my friends ( named
"arnuld", he posts here infrequently), taught me Lisp. so i am not a
programming beginner.
i have heard these 2 points....
|
by: Chris Carlen |
last post by:
Hi:
From what I've read of OOP, I don't get it. I have also found some
articles profoundly critical of OOP. I tend to relate to these articles.
However, those articles were no more objective...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
| |
