How about the future of VC++/MFC
workaholic
windows programmers, do you think so? What about the usage of VC in
companies now? Still a lot of software firms also use it, aren't they?
Unknown
>Now,a lot of fellas told me that .NET is now the primary target of
>windows programmers, do you think so?
No. Though I have written test programs and demonstration systems in
.Net, I have still not written a single commercial application in it.
All my work is native code.
Actually a sizeable chunk of my work has been in (Win32 native) Delphi
for the past couple of years, but since Borland seems to be committing
the slowest suicide in software history I'll probably end up using C#
within a year or so. But my server side apps will be native code
C++/MFC for the foreseeable future.
--
Bob Moore
http://bobmoore.mvps.org/
(this is a non-commercial site and does not accept advertising)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Do not reply via email unless specifically requested to do so.
Unsolicited email is NOT welcome and will go unanswered.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ajay Kalra
> windows programmers, do you think so? What about the usage of VC in
> companies now? Still a lot of software firms also use it, aren't they?
It all depends upon the firm you work for. I haven't seen many ads for
winforms but I have not seen many ads for MFC type either. I think
these are at same footing for now but learning .Net at this stage to do
windows app is OK and will gain momentum. For web type of work, .Net is
the way to go.
---
Ajay
Joseph M. Newcomer
C++ and MFC are languages/frameworks. So is VB, and C#. You use the language that makes
sense in your application domain. Worrying about issues like this is pointless.
Learn C#, it is a cool language.
Worrying about who is using what for which purpose is a game of
follow-who-you-think-is-the-leader. You use what makes technical sense in the context of
your company, your project, and your goals. To do anything else is a waste of time.
This discussion comes up about once a month. Go back and read the archives.
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
David Webber
"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:nkljm29c6184t5ej0...@4ax.com...
> C++ and MFC are languages/frameworks. So is VB, and C#. You use the
> language that makes
> sense in your application domain. Worrying about issues like this is
> pointless.
Not entirely. Some of us would like to maintain and develop MFC-based code
for quite a number of years to come. We're rather fond of (and use
extensively) C++ features which would only be available in unmanaged code,
and do not relish the extra work involved in completely redesigning the
foundations of a large application to suit the latest fashionable framework
every time one comes along. It would be reassuring to know that Microsoft
plan to maintain and develop MFC. Not that we actually *expect* any
reassurannce.
> Learn C#, it is a cool language.
I'm sure it is. But not necessarily a pleasant one to translate existing
applications into.
>.... You use what makes technical sense in the context of
> your company, your project, and your goals. To do anything else is a
> waste of time.
And what makes commercial sense. And that may well depend on what is going
to happen to MFC over the next few years. It *is* relevant. Though it may
be futile to try and predict.
Dave
--
David Webber
Author MOZART the music processor for Windows -
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mzusers/mailinglist.htm
Mihai N.
> plan to maintain and develop MFC. Not that we actually *expect* any
> reassurannce.
MS not only maintains, but also keeps developing MFC.
Really, you will see.
--
Mihai Nita [Microsoft MVP, Windows - SDK]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email
Joseph M. Newcomer
because language B is the latest cool language is simply stupid. There have to be
compelling reasons to change languages within a corporation for any reason, and whimsical
"let's use the latest cool technology" should be grounds for dismissal of whomever
suggests it. The technology has to be assessed in terms of its advantages and costs, and
a decision has to be made on the tradeoffs. In some cases, certain transitions make
sense, e.g., replacing Java Server Pages with something like .NET-based pages for future
new development often is a good decision, but each decision has to be made in context.
That's why I object to the "is MFC dead?" class of questions. The question in and of
itself makes no sense whatsoever, and I worry about people who even think it is worth
asking. Technology is technology, and you choose the best to solve your problem; you
don't just say "C# is cool, let's translate everything to C#". As I say, someone who
makes that decision on such a basis should find their dismissal notice on their desk
within hours of the announcement.
I've done a couple C# apps, and they are fun to do. It is a nice language. But I
certainly don't have the facility with C# that I do with MFC, and for serious apps I use
MFC. Cost/benefit analysis: it's cheaper to have me write 100K lines of MFC than 20K
lines of C#, as much fun as C# is, I can write MFC code at least an order of magnitude
faster than C# code.
Microsoft has been fairly agressive about their plans to support MFC into the indefinite
future. They may change this, but the risk of alienating a couple billion lines of code
is very high for them.
joe
Joseph M. Newcomer
Would you, could you, you will see.
I do not eat green eggs and ham,
I do not eat them, Sam-I-am.
(At some point I will post my "Green Bits on LAN" parody)
joe
On Mon, 27 Nov 2006 00:18:27 -0800, "Mihai N." <nmihai_y...@yahoo.com> wrote:
>> It would be reassuring to know that Microsoft
>> plan to maintain and develop MFC. Not that we actually *expect* any
>> reassurannce.
>
>MS not only maintains, but also keeps developing MFC.
>Really, you will see.
Ajay Kalra
> Would you, could you, you will see.
> I do not eat green eggs and ham,
> I do not eat them, Sam-I-am.
Yet another talent. Perhpas you want to post these on your web site as
well.
---
Ajay
Joseph M. Newcomer
Did you see my McGrew's View poem (which is reachable from my MVP Tips page...)
joe
Ajay Kalra
I havent been there for a while. Will check it out.
---
Ajay
David Ching
> I've done a couple C# apps, and they are fun to do. It is a nice
> language. But I
> certainly don't have the facility with C# that I do with MFC, and for
> serious apps I use
> MFC. Cost/benefit analysis: it's cheaper to have me write 100K lines of
> MFC than 20K
> lines of C#, as much fun as C# is, I can write MFC code at least an order
> of magnitude
> faster than C# code.
>
This is the second most important reason I've used for holding off on .NET
until now --- WinForms is too RAD compared to MFC and does not provide the
structure I like. The first most important reason is that the performance,
redist size, potential for reboots during install, etc. all conspired
against .NET being very deployable.
Fast forward to 2006. Deployment is no longer an issue, because a 20-ish MB
redist file isn't out of the question, and reboots aren't required on Win2K
and later (Win9x platforms don't have to be supported in more and more
cases). In fact, Vista comes with both .NET 2.0 and 3.0 built-in. PC's and
memory have gotten faster and cheaper such that .NET apps are only slightly
sluggish and not overwhelmingly so.
And, the kicker is, you need to use C# to create XAML UI's. Not even
C++/CLI will create XAML apps because it doesn't support partial classes.
This really sucks and basically relegates C++/CLI back to being a
second-class .NET citizen just like when VC++ didn't come with a WinForms
designer. But XAML requires .NET. This is the must-have reason for
learning .NET now.
I guess we are having another discussion after all. :-)
-- David
Ajay Kalra
> And, the kicker is, you need to use C# to create XAML UI's. Not even
> C++/CLI will create XAML apps because it doesn't support partial classes.
> This really sucks and basically relegates C++/CLI back to being a
> second-class .NET citizen just like when VC++ didn't come with a WinForms
> designer. But XAML requires .NET. This is the must-have reason for
> learning .NET now.
>
MSFT sent a clear signal several years ago that .Net is the preferred
platform for all development. IMO, C++ is now a second class
language/plaform wrt .Net and the languages it supports. All major
initiatives are going to be .Net based. MFC is not going to die but the
direction of the market(forced by MSFT) is clearly .Net.
---
Ajay
Joseph M. Newcomer
initiatives require learning .NET. As far as I can tell, there is little technical excuse
for NOT learning NET technology; I work on it as time permits. Excuses of lack of time
are, alas, all too prevalent (and is the reason I don't know more about .NET). But that
wasn't the question. The question was whether MFC is dead.
The future of MFC is not the same question as the future of .NET, and the two questions
should not be confused.
I find the lack of doc/view in C# is a real pain. The lack of STRINGTABLE, MESSAGETABLE,
and dialog template resources seems insane. But the ToString concept (and reflection in
general) is powerful. I haven't looked at the new C# but it appears to fix a number of
serious defects of the first release (particularly generics). So I learn it as I can,
because someday some customer is going to come to me with a .NET need and I'd better be
prepared enough to not make a complete fool of myself.
joe
Mihai N.
it is definitely better than the nothing in .NET :-)
> The lack of STRINGTABLE, MESSAGETABLE,
> and dialog template resources seems insane.
Wow, you just put the finger on the finger on the worst part.
The resource model is a total crap!
I don't even want to get started on this one!
> But the ToString concept (and reflection in
> general) is powerful.
I am a bit bothered by ToString, because (more often than not) it encourages
bad internationalization.
I have seen enums for colors, week day, months, used directly in the UI by
just calling ToString. A mess!
David Webber
> The concept of translating....
First let me say I agree completely with just about everything you say.
Many moons ago, I used to write in C for Windows 3 using the native API.
Then as the advantages of C++ became clear (in particular encapsulation an
its effect in facilitating maintenance) I started writing in C++ (for my own
classes) but still using the underlying Windows API for the presentation.
The first version of my music software was completed in 1994 - using the
Borland C++ compiler.
MFC was for me a decision prompted by Win95. To get there I rewrote the
program for Windows 3.1 using MFC and then used the relatively smooth
transition path which this provided for increasing the size of the WPARAM
etc. The fact that most of MFC was a thin wrapper on the native API was a
big plus. Even though I had qualms about its "object-disorientation" :-)
My program (now on v9) is now BIG and I couldn't translate it into C# or
even managed C++ easily. Too much multiple inheritance (about which I
have never had any religious problems) and, in particular, too many classes
with bit fields.
MFC is fine. Like you, I am by now far more conversant with it than other
ways of programming Windows.
But, when one is selling software, one becomes aware that people like it to
look and feel "up-to-date". MFC's 16-colour toolbar buttons are one case
in point (though I have printed and filed the article on how to get round
that which someone here pointed me to).
> That's why I object to the "is MFC dead?" class of questions. The
> question in and of
> itself makes no sense whatsoever,...
Except, I still argue, for those of us maintaining and developing large
applications already written with it.
> Microsoft has been fairly agressive about their plans to support MFC into
> the indefinite
> future. They may change this, but the risk of alienating a couple billion
> lines of code
> is very high for them.
I have been banking on this.
[Otherwise there's always the underlying Windows API again. It would be
awful if that became the option which made most commercial sense!]
David Ching
news:etBlsPtE...@TK2MSFTNGP02.phx.gbl...
>
> [Otherwise there's always the underlying Windows API again. It would be
> awful if that became the option which made most commercial sense!]
>
That's been the fallback strategy, to always go to the Windows API when the
framework fails. But now our strategy must evolve to using .NET when that
is the only API available... for example, with XAML. The good news is MS
has provided us a way to easily extend our native C++ apps by dropping into,
not the Windows API as before, but into .NET. But this means the need to
learn .NET just got a whole lot more compelling. Whereas before, it was
optional, now it is not.
-- David
David Ching
news:1164682743....@h54g2000cwb.googlegroups.com...
>
> MSFT sent a clear signal several years ago that .Net is the preferred
> platform for all development. IMO, C++ is now a second class
> language/plaform wrt .Net and the languages it supports. All major
> initiatives are going to be .Net based. MFC is not going to die but the
> direction of the market(forced by MSFT) is clearly .Net.
>
Well, I'm not sure how clear the signal was, since they make many
announcements that fizzle out after a time. I remember when p-code was
supposed to be the next best thing in Microsoft C, that there would be no
HWND in Longhorn, etc. For a developer with lots of experience with Win32
and MFC, .NET was an alternative universe that had a nicer object model but
in the end was a thicker wrapper around the native API we'd been efficiently
programming to for years. For developers like us, there was no .NET story
that made sense until C++/CLI appeared in VC2005. The Managed C++
extensions were universally recognized as being not very usable. P/Invoke
is way too tedious. I love Nish's blog that is an excellent read for us
native programmers who have found that .NET is NOT the preferred platform to
do the things we've been doing for years, yet want to put it in our toolbox
in the aspect. For me, now the sweet spot of .NET is just beginning.
Several years ago? .NET was still an impractical Microsoft pipe dream.
-- David
David Webber
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:icWah.198$Ga1...@newssvr12.news.prodigy.net...
I was starting to feel this might be true, which means I'll have to find
some time.
BTW - what's XAML ? (Forgive me if I'm living out in the sticks here - my
??ML concerns currently centre around MusicXML and importing it.)
David Ching
>
> BTW - what's XAML ? (Forgive me if I'm living out in the sticks here -
> my ??ML concerns currently centre around MusicXML and importing it.)
>
XAML is the way to program WinFX (Windows Presentation Foundation) which
replaces HWNDs and uses DirectX to show all UI. Instead of .rc file, you
edit a ".xaml" file which is an XML file. The idea is for a graphic artist
to create the .xaml file specifying the UI (perhaps using a graphic
studio-like tool such as Acryllic, which is now in Beta on MSDN), and for
the developer to write the handlers in a C# file. It's cool because the
graphic artist can play with the UI even without the handlers and know how
exactly the UI will look before the code is written, as opposed to now where
typically the graphic artist mocks up the UI in Photoshop files and
developers need to re-create them in code. Here, the artist supplies the
actual resources used in the project. And XAML is implemented using vector
graphics so that everything is scalable, as opposed to targetting specific
app sizes based on fixed bitmap dimensions.
WinFX is part of .NET 3.0, which is a proper superset of .NET 2.0 and is
included with Vista and is a redistributable component in WinXP SP2. If you
have MSDN, there is a free 2-hour online tutorial that is pretty
enlightening.
I'm learning the basics of .NET using WinForms and C++/CLI, then will ease
into WinFX. I'm sold on C++/CLI, because you can just call Win32 API's as
usual, e.g. GetWindowText(), then with a simple marshal call can convert the
result into a .NET "string" for use with the rest of the .NET program. It
will be much easier to ease into .NET if we can drop back into the familiar
Win32 API instead of searching tediously for .NET equivalent; and some API's
still have no equivalent, which would otherwise require tedious prototyping
for P/Invoke.
-- David
Ajay Kalra
> usual, e.g. GetWindowText(), then with a simple marshal call can convert the
> result into a .NET "string" for use with the rest of the .NET program. It
> will be much easier to ease into .NET if we can drop back into the familiar
> Win32 API instead of searching tediously for .NET equivalent; and some API's
> still have no equivalent, which would otherwise require tedious prototyping
> for P/Invoke.
>
I wouldnt touch Win32 API unless absolutely needed(usually you wouldnt
need it at all). Doing it because of habit is really no reason. As for
PInvoke, there is PInvoke.Net which does all the signature inserting
for you:
http://blogs.msdn.com/adam_nathan/archive/2004/05/06/127403.aspx
---
Ajay
David Wilkinson
> This is the second most important reason I've used for holding off on
> .NET until now --- WinForms is too RAD compared to MFC and does not
> provide the structure I like. The first most important reason is that
> the performance, redist size, potential for reboots during install, etc.
> all conspired against .NET being very deployable.
>
> Fast forward to 2006. Deployment is no longer an issue, because a
> 20-ish MB redist file isn't out of the question, and reboots aren't
> required on Win2K and later (Win9x platforms don't have to be supported
> in more and more cases). In fact, Vista comes with both .NET 2.0 and
> 3.0 built-in. PC's and memory have gotten faster and cheaper such that
> .NET apps are only slightly sluggish and not overwhelmingly so.
>
> And, the kicker is, you need to use C# to create XAML UI's. Not even
> C++/CLI will create XAML apps because it doesn't support partial
> classes. This really sucks and basically relegates C++/CLI back to being
> a second-class .NET citizen just like when VC++ didn't come with a
> WinForms designer. But XAML requires .NET. This is the must-have
> reason for learning .NET now.
>
> I guess we are having another discussion after all. :-)
>
Hi David:
I am not sure I agree with either of your justifications for moving to
.NET at this time.
1. For me, a 20MB redist file will still upset some of my customers, and
there may still be some who do not want .NET on their computers.
2. Why is XAML a must-have? I don't know much about it, but I don't
think it's a must-have for me. Did you see Petzold's April 1 spoof of
XAML? That's kind of how I feel about it.
The thing I do like about .NET is that the object model is much cleaner,
particularly the GUI library. But when you slam this object model into
C++/CLI you end up with something that is really rather messy (IMHO),
despite the great improvements from MC++.
I already have the back end of my main app pretty much isolated into
ANSI standard C++, and my long term plan for moving to .NET is to wrap
this back-end into managed code, and then rewrite the GUI in C#. Do you
think this is a good plan? If not, no matter, because I haven't started
yet! Yes, too busy.
David Wilkinson
Ajay Kalra
> The thing I do like about .NET is that the object model is much cleaner,
> particularly the GUI library. But when you slam this object model into
> C++/CLI you end up with something that is really rather messy (IMHO),
> despite the great improvements from MC++.
>
This is precisely how I feel. I personally would not advocate using C++
and .Net unless there is some justification for it(performance etc).
Our product is very performance centric and our new .net app is all
C#.
---
Ajay
David Webber
> XAML is the way to program WinFX (Windows Presentation Foundation)...
Thank you for the explanation.
David Ching
"David Wilkinson" <no-r...@effisols.com> wrote in message
news:evO%23aLwEH...@TK2MSFTNGP02.phx.gbl...
> David Ching wrote:
>
> I am not sure I agree with either of your justifications for moving to
> .NET at this time.
>
> 1. For me, a 20MB redist file will still upset some of my customers, and
> there may still be some who do not want .NET on their computers.
>
That's true for me as well. I work with a number of apps that are
distributed on a USB flash drive, and for these obviously .NET is not an
option. Similarly I work with apps that are distributed with hardware, and
the customers don't necessarily want to install .NET just to run the
hardware. But it's also true that for most desktop apps, .NET is not an
unovercomable burdan that it used to be, as net connections are faster now
(more than 50% are on broadband) and .NET is more and more likely to already
be installed.
For example, I plan to offer a desktop app with a "collector" module that is
statically linked to MFC so it can run anywhere. But the "analyzer" module
will require .NET. It seems to fit the mindset of most people. Collect
data anywhere, analyze on a specific computer with .NET installed. This is
my own app which I'm writing for sale, but really is a learning experience
for .NET for me. Plus it is what is qualifying me for the Microsoft Empower
ISV program which grants MSDN license at a drastically reduced price.
> 2. Why is XAML a must-have? I don't know much about it, but I don't think
> it's a must-have for me. Did you see Petzold's April 1 spoof of XAML?
> That's kind of how I feel about it.
>
It's not a must-have, but it may quickly become so as users get addicted to
the live content update so prevelant in Vista (where even the task switcher
thumbnails update in real time to reflect the changing windows contents).
The point is, in the past if customers demanded these features, we could
always do it in Win32/MFC, but now that isn't an option. So the time to
learn .NET is now, before the pressure is on to deliver this.
> The thing I do like about .NET is that the object model is much cleaner,
> particularly the GUI library. But when you slam this object model into
> C++/CLI you end up with something that is really rather messy (IMHO),
> despite the great improvements from MC++.
>
AFAIK, C++/CLI translates into 1:1 syntax with C#, although for a given
line, the C# line is usually shorter and contains less punctuation
characters. IMHO, what makes a language easy to read is less punctuation
characters, so therefore I can see how you can say C# is "cleaner". But C#
has the disadvantage of looking strange to a C++ programmer, as Nish says in
his blog. I disagree that C++/CLI messes up the object model, it just may
be a little harder to read for those not used to C++.
> I already have the back end of my main app pretty much isolated into ANSI
> standard C++, and my long term plan for moving to .NET is to wrap this
> back-end into managed code, and then rewrite the GUI in C#. Do you think
> this is a good plan? If not, no matter, because I haven't started yet!
> Yes, too busy.
>
Sounds good to me. I am planning to start with C++/CLI and drop into C#
when I need to (e.g. to use prewritten components or XAML). I don't have
experience to know whether C++/CLI is a long-term replacement for C# or just
a crutch to getting there. But if your back-end contains lots of classes
which the GUI needs to interface with, it's far easier in C++/CLI where your
managed code can call your native back-end with normal C++ calls. At least
that's what I know today! :-)
-- David
Joseph M. Newcomer
On Mon, 27 Nov 2006 23:09:32 -0800, "Mihai N." <nmihai_y...@yahoo.com> wrote:
>> I find the lack of doc/view in C# is a real pain.
>Although I don't really find the MFC implementation of Doc/View too clean,
>it is definitely better than the nothing in .NET :-)
>
>> The lack of STRINGTABLE, MESSAGETABLE,
>> and dialog template resources seems insane.
>Wow, you just put the finger on the finger on the worst part.
>The resource model is a total crap!
>I don't even want to get started on this one!
****
Do you mean the traditional use of resources is crap, or the absence of resources in C# is
crap...?
****
>
>> But the ToString concept (and reflection in
>> general) is powerful.
>I am a bit bothered by ToString, because (more often than not) it encourages
>bad internationalization.
>I have seen enums for colors, week day, months, used directly in the UI by
>just calling ToString. A mess!
*****
I'd be interested in discussing this. I'd rather not do bad internationalization if I can
help it. What are the issues?
joe
****
Joseph M. Newcomer
have to drop down to the raw API to do things that have no C++/MFC interface, but
otherwise I rarely see it. But are we talking about the same thing here with respect to
the "native API"?
joe
Ajay Kalra
> have to drop down to the raw API to do things that have no C++/MFC interface, but
> otherwise I rarely see it.
> But are we talking about the same thing here with respect to
> the "native API"?
Yes. Generally you wouldnt use Win32API directly. But there are cases
where FCL does not suffice and then you have to use PInvoke to access
Win32API.
---
Ajay
Tom Serface
I would, I could, you see; indeed.
But I do not like green eggs and ham,
I had them once and they sort of didn't taste good and I didn't like the
color and I thought the hairy guy Sam looked nasty and...
So... I should keep my day job.
Tom
"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:1d7mm2ljt78u5l9ov...@4ax.com...
Tom Serface
trying to position their new paradigms. I've never heard anyone at MSFT say
that one environment is preferred over the other. In fact, I think they are
careful not to be too specific. I think each of the tools and languages
should be evaluated and, perhaps, used depending on the need. I think it's
going to take a while for CLI/CLR to live up to it's promise and be included
enough in the OS to make distribution of applications a lot easier, but I
suspect that will eventually happen. I remember back in the mid 80's
hearing people say that Windows 3.1 was too slow and DOS applications were
the way to go since they were easy distribute and nice and small and fast.
I don't know too many people distributing DOS applications any more all
these many years later.
It's also much easier for Microsoft to control C# as compared to all the
hoops they have to jump through to keep C++ up to date. Thus, I'd guess C#
is always going to support more cooler features and tools of .NET even
though C++ will likely continue to improve it's support.
The one major advantage I see with C++ is you can do either native or
managed using nearly the same environment and almost the same code. This
could help the transition to .NET in the long run.
If MSFT would do MFC.NET I think they could encourage a lot more people to
use it... but I don't know that we'll ever see that happening :o)
Tom
"Ajay Kalra" <ajay...@yahoo.com> wrote in message
news:1164682743....@h54g2000cwb.googlegroups.com...
>
Ajay Kalra
> going to take a while for CLI/CLR to live up to it's promise and be included
> enough in the OS to make distribution of applications a lot easier, but I
> suspect that will eventually happen.
Compare to C#/VB.Net, there is hardly any market for it. New .Net only
projects are very unlikely candiadate with CLI. It has only meaning to
existing C++ base. This base is very likely to be native rather than
managed.
> The one major advantage I see with C++ is you can do either native or
> managed using nearly the same environment and almost the same code. This
> could help the transition to .NET in the long run.
Thats true. And thats only valid with existing C++ base. In our
existing project we chose to completely rewrite the product in C#
rather than use C++/MC++ (at that time). It few millions LOC, so it
wasnt an easy decision.
> If MSFT would do MFC.NET I think they could encourage a lot more people to
> use it... but I don't know that we'll ever see that happening :o)
Not going to happen. C++ just doesnt fit in there. Making MFC.net will
tick a lot of existing base which is vehemently anti .net.
---
Ajay
Tom Serface
"Ajay Kalra" <ajay...@yahoo.com> wrote in message
news:1164747421....@j44g2000cwa.googlegroups.com...
> Compare to C#/VB.Net, there is hardly any market for it. New .Net only
> projects are very unlikely candiadate with CLI. It has only meaning to
> existing C++ base. This base is very likely to be native rather than
> managed.
Actually, it's true of C# as well since there are lots of components that
.NET needs regardless of the language you use to develop.
> Thats true. And thats only valid with existing C++ base. In our
> existing project we chose to completely rewrite the product in C#
> rather than use C++/MC++ (at that time). It few millions LOC, so it
> wasnt an easy decision.
It does sound like a lot of work, but I guess you'd have to evaluate the
cost/worth for each project. New projects are easier to make the
determination.
> Not going to happen. C++ just doesnt fit in there. Making MFC.net will
> tick a lot of existing base which is vehemently anti .net.
I disagree with that. I know a lot of people that use MFC simply because
.NET doesn't have a doc/view model yet and because they already know the
classes after years of use. I think having something like this would entice
some of the die-hard MFC fans to give it a try. MFC would be difficult to
encapsulate in .NET though because of some of the original design decisions.
Tom
BobF
> I think the C# group ...
<$.02US>
I think MSFT is trying to save their azz from the OS tools. By creating a
new language, and migrating core functionality to require it (XAML), they
keep us locked in buying their proprietary tools.
Oh, and compete with Java ... :-)
</$.02US>
Ajay Kalra
> encapsulate in .NET though because of some of the original design decisions.
Regardless of its design (which is poor by today's standards), if MFC
goes pure .Net, I would suspect you would be able to count number of
people using it in your single hand. PM who advocates this idea would
probably never find a job again. Not only does it not make any
financial sense(for microsoft and its users), it limits the audience to
C++ only. In managed world, thats suicidal.
---
Ajay
Tom Serface
:o)
Tom
"BobF" <rNfOrS...@charter.net> wrote in message
news:mluhprki1zr5.obelrtqtdqn$.dlg@40tude.net...
Tom Serface
though, but I hardly think it would cost anyone their job. Also, I assume
any assemblies with C++ would work with other .NET languages too just like
other .NET components.
Tom
"Ajay Kalra" <ajay...@yahoo.com> wrote in message
news:1164750406.9...@j44g2000cwa.googlegroups.com...
Joseph M. Newcomer
locked into their proprietary tools.
And all those versions of Unix, with names that ended in -ix but which couldn't call
themselves "Unix" because of the AT&T licensing, and with their various different and
incompatible C compilers, shells, and utilities, made sure we couldn't move from Apollo to
Sun to HP, but that was OK because it was Unix, which Can Do No Wrong.
I guess none of you ever worked on IBM mainframes, where the lockin was fairly strong. Or
used RCA, Burroughs, NCR, or any other vendor.
There are more Windows boxes out there now than the sum of ALL computers made by ALL
previous vendors since the first computer was built. This is "lock-in"? I can buy a
computer computer which is orders of magnitude faster than a mainframe for less than I
used to pay for a single disk pack (which held 40MB. The drive the pack was mounted on
was about $35,000. We had eight drives. I signed the purchase order). So if I'm "locked
in" to a product that costs me less per year than the old mainframes cost in electricity
per month (our DEC-20, about a 286-power machine, cost us $1900/month just in electricity!
In 1981 dollars...).
My entire capital outlay for 12 machines (three of them laptops), a superfast B&W laser
printer, a superfast color laser printer, two scanners, three UPS units, networking
support, wireless LAN, a terabyte of online memory, tape backup units, and three massive
flat-screen displays would not have bought a single 40MB disk drive in 1980. What do I
care about lockin? Yet there are people who seem to think this matters. It doesn't, in
nearly all cases. There are exceptions, but we are talking about a few tens of thousands
of cases compared to about a billion installed computers. People treat this as if it
matters, but it rarely matters. In fact, WIndows has done more for portability than any
operating system in history (I recall one organization I worked for that had a "portable"
product, with so many #ifdefs in it that the code was nearly unreadable, and most of them
to get around fatal compiler bugs in the 30 different Unix platforms we were supporting)
By comparison, WIndows is a remarkably uniform concept.
Everyone talks about "proprietary lock-in" as if it matters any longer. It doesn't matter
in the slightest. This reflects an attitude that made sense only when hardware and
software cost money. The difference between the cost of Windows and the cost of Linux is
nonexistent; effectively, both are free, but Windows utlimately costs less. (I don't use
free open-source software because I can't afford it).
Let's see: its OK to be locked into Linux, but not OK to be locked into Windows? What
have I missed here? The hardware is nearly free, the software is nearly free... (and
don't talk to me about purchase price; I'm talking about TCO), so what does it matter? If
you want to work in an environment that represents the best thinking of 1965, by all
means, feel free to use Linux. I lived in Unix for 15 years and nothing made me happier
than to never have to see it again.
Let's see: it's OK to be locked into Java but not into MFC? Don't tell me about
portability; most portability of Java has little, if anything, to do with the choice of
platform.
Oh, yes, and we know that open architectures are moral and right and closed architectures
are evil. And Microsoft is evil and Apple is good. Have you ever tried to create a
third-party backplane device for a Macintosh? Which bus did you choose? And what was its
lifetime? I spent a couple years programming Macintoshes, and one of the things I
learned was that everyone who said how great they were had never programmed one. Those of
us who were trying to program them recognized they were years behind Microsoft's MS-DOS
environment in terms of developer support. And you couldn't build portable apps on the
Mac.
A friend who used to do Java applets said they could only program in a very limited subset
of Java 1.0 because otherwise the applets wouldn't run on the client machines. Yet I can
compile a well-written 16-bit MFC program and it runs immediately in Win32 (providing the
programmer didn't do anything brain-dead like store two handles in a DWORD), but I can't
compile a correctly-written Java program from the previous release in the current release
because there are so many incompatible changes. But Sun is Good and Microsoft is Evil. I
guess I have a lot of trouble understanding this.
Oh, yes, it's OK for Apple to steal from Xerox, but evil for Microsoft to steal from
Xerox, and it is *definitely* OK for X-Windows to steal from Xerox and KDE and Gnome to
steal from Apple and Microsoft. I find this all a bit confusing...
There are some topics that I react badly to, and the issue of "lock-in" is more than silly
these days.
I guess I've seen so many of these things come and go that I just cannot get excited about
the issue any longer.
joe
David Ching
Well, I don't see Eclipse or anything else coming close to the Microsoft
IDE's in terms of developer productivity, so locked in or not, I would
choose MS IDE's in a heartbeat.
-- David
David Ching
> I wouldnt touch Win32 API unless absolutely needed(usually you wouldnt
> need it at all). Doing it because of habit is really no reason.
I think that is the same philosophy Joe has about avoiding GetDlgItem() in
MFC programs because it's not object oriented. I'm not a purist. I'm a
minimalist. Whichever will get the job done with the least typing is the
best for me. If I'm going to access the dialog item once, I'm not going to
create a DDX control variable, taking up space in the .h and .cpp file
message maps to do it, just because it is more object oriented. I will just
call GetDlgItem() once and be done with it.
I suspect I'll use the same methodology regarding whether to call native
API's vs. using whatever .NET abstractions are there. If it's less typing
to call native API's then that's what I'll do. I'll not use .NET
abstractions that are more inconvenient just because they are .NET (although
from what I've seen the .NET abstractions are actually easier to use and
thus are more convenient). Still, the API coverage of .NET is nowhere near
100% from what I've heard.
I honestly don't know why you like C# so much, given your extensive native
background. C# appeals to Java programmers who are used to sandboxes and
limitations, not to us hardcore C++ programmers who are used to the power of
having the full system under our control. C++/CLI lets us retain that
power, and C# doesn't.
> As for
> PInvoke, there is PInvoke.Net which does all the signature inserting
> for you:
>
> http://blogs.msdn.com/adam_nathan/archive/2004/05/06/127403.aspx
>
That's a nice plug-in he wrote, and it should make PInvoke.Net much more
approachable, but see here for why avoiding these problems in the first
place is even better: http://www.codeproject.com/managedcpp/whycppcli.asp
-- David
David Ching
news:OTwYF4yE...@TK2MSFTNGP03.phx.gbl...
> I've never heard anyone at MSFT say that one environment is preferred over
> the other. In fact, I think they are careful not to be too specific.
Well, here's one MS developer's opinion (he works on the Expression suite):
http://blogs.msdn.com/jeremykuhne/archive/2005/06/11/428363.aspx
-- David
Ajay Kalra
David Ching wrote:
> "Ajay Kalra" <ajay...@yahoo.com> wrote in message
> news:1164727852.1...@80g2000cwy.googlegroups.com...
> > I wouldnt touch Win32 API unless absolutely needed(usually you wouldnt
> > need it at all). Doing it because of habit is really no reason.
>
> I think that is the same philosophy Joe has about avoiding GetDlgItem() in
> MFC programs because it's not object oriented. I'm not a purist. I'm a
> minimalist. Whichever will get the job done with the least typing is the
> best for me.
No, its not the same as GetDlgItem discussion .Net provides access to
caption of a form/control. Instead of using it you prefer to use
GetWindowText because its MFCish.Least typing is not to use
GetWindowText. I really dont know why you want to use .Net. It appears
you want to avoid it.
>
> That's a nice plug-in he wrote, and it should make PInvoke.Net much more
> approachable, but see here for why avoiding these problems in the first
> place is even better: http://www.codeproject.com/managedcpp/whycppcli.asp
>
Sorry, no CLI for me.
---
Ajay
Joseph M. Newcomer
On Wed, 29 Nov 2006 02:58:17 GMT, "David Ching" <d...@remove-this.dcsoft.com> wrote:
>"Ajay Kalra" <ajay...@yahoo.com> wrote in message
>news:1164727852.1...@80g2000cwy.googlegroups.com...
>> I wouldnt touch Win32 API unless absolutely needed(usually you wouldnt
>> need it at all). Doing it because of habit is really no reason.
>
>I think that is the same philosophy Joe has about avoiding GetDlgItem() in
>MFC programs because it's not object oriented. I'm not a purist. I'm a
>minimalist. Whichever will get the job done with the least typing is the
>best for me.
****
I have found that "least typing" is about the single worst excuse I've had to deal with in
terms of bad program practice. Typing is not the real cost, and minimizing it is
irrelevant.
****
> If I'm going to access the dialog item once, I'm not going to
>create a DDX control variable, taking up space in the .h and .cpp file
>message maps to do it, just because it is more object oriented. I will just
>call GetDlgItem() once and be done with it.
****
Wow! TAKING UP SPACE! That is ALMOST as lame an excuse as "minimal typing". Especially
because creating control variables doesn't take up any space in the message map. And wow!
It MIGHT ACTUALLY TAKE UP SPACE IN THE HEADER FILE! Oh, dearie me, whatever shall I do?
These are insane reasons! Space has NEVER been the issue for trivial data structures like
a class variable for a window. If you are going to "optimize" something, at least have
some rational justification for the "optimization". These are not optimizations; they
merely allow you to have two different ways of accomplishing the same thing, one easy to
use (binding control variables), one hard to use (GetDlgItem with casting). Choose the
easy, object-oriented method and use it uniformly.
These are the kinds of programs I make money repairing...
*****
>
>I suspect I'll use the same methodology regarding whether to call native
>API's vs. using whatever .NET abstractions are there. If it's less typing
>to call native API's then that's what I'll do.
****
If the right way is to use the raw API, use it. If the right way is the .NET way, use it.
But for goodness sake, don't use completely silly reasons such as the amount of typing as
justification! This is how we got a lot of one-letter program names in Unix! It didn't
make sense in Unix, it never made sense in any context, and it certainly doesn't make any
sense today.
The number of Really Bad Programs I've had to deal with over the years (largely in Unix)
where the justification was always "the fewest number of keystrokes", has been awesome.
I remember one classic, "Well, if you give it a bad command line, it crashes. So what?
You shouldn't give it a bad command line. What do you expect me to do, write code to
detect that you gave a bad command line? That takes too much typing!"
Another classic was someone who, to avoid two assigment statements, did the equivalent of
overlapping two 16-bit pointers with a single 32-bit pointer which he could set to 0, thus
creating two NULL pointer assignments in one assignment. Of course, when we converted to
the equivalen of the 32-bit world, one of the two fields wasn't nulled out, and it took me
a week of debugging to find it. All because he didn't want to type an extra assignment
statement. In addition to less typing, he explained "It also makes the program run faster
because a single double-wide assignment takes one fewer instructions". In the creation of
a data structure, which happened perhaps three times in the program. I pointed out that
the CPU time wasted finding his bug meant that if we ran the program continuously,
restarting it each time it stopped, we would break even in about 14 years.
But the worst one was a situation in which the president of the company would not allow a
necessary incompatible change to occur because he wanted to minimize his typing. He also
refused to accept my offer to retype the code for him. A year after six of us had
expended a massive effort to avoid his doing any retyping, I was analyzing the program and
discovered that there were TWO STATEMENTS out of about 100K source lines that would have
had to change. It cost the company about three man-years' effort because of this. Just
to minimize his typing.
"Minimizing typing" is one of my hot buttons. It is ALWAYS a poor justification for
writing bad code.
****
> I'll not use .NET
>abstractions that are more inconvenient just because they are .NET (although
>from what I've seen the .NET abstractions are actually easier to use and
>thus are more convenient). Still, the API coverage of .NET is nowhere near
>100% from what I've heard.
>
>I honestly don't know why you like C# so much, given your extensive native
>background. C# appeals to Java programmers who are used to sandboxes and
>limitations, not to us hardcore C++ programmers who are used to the power of
>having the full system under our control. C++/CLI lets us retain that
>power, and C# doesn't.
>
****
I am less interested in power and more interested in writing robust code that is clear and
easy to maintain. C# provides a great deal of the power I need; in fact, my one major C#
application had no need for native code at all (it did take me a while to discover how to
do couple things, but what I needed was actually there). It's not like VB, which is
virtually unusable by a serious programmer.
Functionality matters, robustness matters, readability matters, time-to-market matters,
and maintainability matters. Minimizing typing is not even worthy of discussion, it is so
bogus. C# does pretty well in these areas. It's just another language, with some
reasonably cool features. If it had doc/view, I think my customer base would find it more
acceptable.
****
>
>> As for
>> PInvoke, there is PInvoke.Net which does all the signature inserting
>> for you:
>>
>> http://blogs.msdn.com/adam_nathan/archive/2004/05/06/127403.aspx
>>
>
>That's a nice plug-in he wrote, and it should make PInvoke.Net much more
>approachable, but see here for why avoiding these problems in the first
>place is even better: http://www.codeproject.com/managedcpp/whycppcli.asp
>
>-- David
>
>
>
>
Joseph M. Newcomer
paradigm "write once, debug everywhere". It was designed to lock people into a single
vendor who exercised absolute control over every aspect of its development, and allowed no
deviation from Sun's concept of Purity of Essence (the infamous Sun-Microsoft lawsuit.
Apparently if Microsoft came out with a version that had the slightest incompatibility,
this was Evil, but if Sun broke every existing Java application with their next release,
this was Desirable Product Enhancement and was therefore Good. I lived through this
several times before I gave up on it; by the time I was teaching a Java course, the
current version of Java would not compile any examples from the textbooks which were only
a few months old!)
Now it is Open Source, and it will be interesting to see what happens to it. It now has a
very slight chance of becoming a reasonable language. At least if Sun keeps out of its
development (they have consistently been Java's worst enemy)
joe
David Ching
>
> No, its not the same as GetDlgItem discussion .Net provides access to
> caption of a form/control. Instead of using it you prefer to use
> GetWindowText because its MFCish.Least typing is not to use
> GetWindowText. I really dont know why you want to use .Net. It appears
> you want to avoid it.
>
That's just an example of CLI vs. P/Invoke. I've no idea how good .NET's
access is to window text. I've said over and over the reason to use .NET
is because it is the only way to access certain Windows subsystems.
> Sorry, no CLI for me.
>
Fine, mroe for the rest of us then. ;)
-- David
David Ching
> I have found that "least typing" is about the single worst excuse I've had
> to deal with in
> terms of bad program practice. Typing is not the real cost, and
> minimizing it is
> irrelevant.
Well, it should be obvious that the less typing I do, the less code you have
to read and digest, and the faster you will comprehend it. I'm not talking
about one character variable names.
> Wow! TAKING UP SPACE! That is ALMOST as lame an excuse as "minimal
> typing". Especially
> because creating control variables doesn't take up any space in the
> message map. And wow!
> It MIGHT ACTUALLY TAKE UP SPACE IN THE HEADER FILE! Oh, dearie me,
> whatever shall I do?
>
Calm down. We both want code readability. Do you honestly think the
overhead of a member variable is worth saving one call to GetDlgItem() that
does not require any member cast, as in
GetDlgItem(IDC_BUTTON_BROWSE)->EnableWindow(FALSE);
This is very readable.
Excuse me, the member variable goes into the DDX section, not the message
map. I could make up some lame excuse of how busy I am or how hard it is to
go across the room and look up a book as some people here do, but I won't.
> These are insane reasons! Space has NEVER been the issue for trivial data
> structures like
> a class variable for a window. If you are going to "optimize" something,
> at least have
> some rational justification for the "optimization". These are not
> optimizations; they
> merely allow you to have two different ways of accomplishing the same
> thing, one easy to
> use (binding control variables), one hard to use (GetDlgItem with
> casting). Choose the
> easy, object-oriented method and use it uniformly.
>
> These are the kinds of programs I make money repairing...
(rolling eyes) I could say I make money fixing non-statically linked
programs written with a philosophy that an installer is absolutely necessary
and taking up unnecessary megabytes of redistributables, but what's the use?
> If the right way is to use the raw API, use it. If the right way is the
> .NET way, use it.
> But for goodness sake, don't use completely silly reasons such as the
> amount of typing as
> justification! This is how we got a lot of one-letter program names in
> Unix! It didn't
> make sense in Unix, it never made sense in any context, and it certainly
> doesn't make any
> sense today.
>
[long unnecssary anecode snipped]
I honestly think you go out of your way to give people a really hard time
when if you stop and READ what they're saying, you will know they're not
saying what you're going off on a tangent about.
> "Minimizing typing" is one of my hot buttons. It is ALWAYS a poor
> justification for
> writing bad code.
No it's not. It can be when taken to an extreme, but we are both
professionals that don't do that. At least I think not. And I hope that
you don't overreact to your hot button by choosing 40 character variable
names like IfThisIsTheFirstTimeInTheLoop as I've seen people who have the
same hot button have done.
> I am less interested in power and more interested in writing robust code
> that is clear and
> easy to maintain. C# provides a great deal of the power I need; in fact,
> my one major C#
> application had no need for native code at all (it did take me a while to
> discover how to
> do couple things, but what I needed was actually there). It's not like
> VB, which is
> virtually unusable by a serious programmer.
>
> Functionality matters, robustness matters, readability matters,
> time-to-market matters,
> and maintainability matters. Minimizing typing is not even worthy of
> discussion, it is so
> bogus. C# does pretty well in these areas. It's just another language,
> with some
> reasonably cool features. If it had doc/view, I think my customer base
> would find it more
> acceptable.
Fine, no argument with the above. It's your misapplication to what I say
that I object to. You treat your peers (I have just as much Windows
experience as you do, maybe your years of punch cards makes you feel
superior) as students in your intro classes.
-- David
Mihai N.
> resources in C# is crap...?
I am not sure what you mean by absence of resources.
I think in fact has two resource types: resx (xml based) and properties
(key=value, Java-like, but UTf-8, not Java-escaped).
I call crap the resx format and the fact that one is forced to use two
different types of resources.
MS recomends to store strings in .properties, and it stores the forms stuff
in resx files.
But!
1. there is no obvious IDE way to add/build .properties files (it is
possible)
2. there is no obvious IDE way to add strings, images, menus, etc. outside a
form
3. there is one form / resx file. So an application with 400 dialogs (I have
seen this) ends up with 400 resx files / language
4. WinRes (provided by MS) "damages" the resx files, so that a file edited by
WinRes cannot be opened in VS anymore
5. the resx format itself is a mess
1-3 are pretty much the VB design, which was also very bad for localization.
4 is just a crappy tool.
Here is an example for item 5:
=================================
<data name="lblNumber.Text" xml:space="preserve">
<value>Number:</value>
</data>
<data name=">>lblNumber.Name" xml:space="preserve">
<value>lblNumber</value>
</data>
<data name=">>lblNumber.Type" xml:space="preserve">
<value>System.Windows.Forms.Label, System.Windows.Forms, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
</data>
<data name=">>lblNumber.Parent" xml:space="preserve">
<value>tableLayoutPanel1</value>
</data>
<data name=">>lblNumber.ZOrder" xml:space="preserve">
<value>0</value>
</data>
<data name="lblCurrISO.Anchor" type="System.Windows.Forms.AnchorStyles,
System.Windows.Forms">
<value>Left</value>
</data>
<data name="lblCurrISO.AutoSize" type="System.Boolean, mscorlib">
<value>True</value>
</data>
<data name="lblCurrISO.Location" type="System.Drawing.Point,
System.Drawing">
<value>3, 32</value>
</data>
=================================
There is no reliable way to tell what is localizable and what is not.
Sometimes value is translatable ("Number:"), sometimes can be changed by
localization, but with predefined vaules (alignment, coord, color, font,
etc.) and sometimes you are not allowed to touch it ("lblNumber")
It is basically no structure: name,type,value, and sometimes the value is
localizable. You can say "the stuff in the Id, after dot, will tell you if
this is localizable." Nope! Because I can have custom objects, with custom
properties.
Can be a tab-delimited or a comma separated file, no need of xml:
lblNumber.Text=Number:
lblNumber.Name=lblNumber
lblNumber.Type=System.Windows.Forms.Label, System.Windows.Forms,...
lblNumber.Parent=tableLayoutPanel1
lblNumber.ZOrder=0
lblCurrISO.AutoSize{System.Boolean, mscorlib}=True
lblCurrISO.Location{System.Drawing.Point, System.Drawing}=3, 32
And lblNumber.Parent to show ownership?
One of the main things for XML is that it can store structure.
The resx does not take any advantage of it.
What about this:
<Dialogs>
<Dialog id="idd_about" Text="About example">
<Rect x="0" y="0" width="200" height="400" />
<LayoutPanel id="tableLayoutPanel1">
<Label id="lblNumber" Text="Number:" Anchor="Left" AutoSize="True">
<Rect x="3" y="32" width="80" height="20" />
</Label>
</LayoutPanel>
</Dialog>
...
</Dialogs>
<Strings>
<String id="idsError" Text="Try again tomorrow!" />
...
</Strings>
Isn't this better?
Oups!
It looks a bit like mxml (Macromedia/Adobe Flex)!
Or like Qt resources. Or like the Mac nib files. Or like the wxWidgets
resource files.
Or like xaml (WPF)!
It seems like (at least in some areas) MS still needs version 3 to get
something right :-)
>>I have seen enums for colors, week day, months, used directly in the UI by
>>just calling ToString. A mess!
> *****
> I'd be interested in discussing this. I'd rather not do bad
> internationalization if I can help it. What are the issues?
> ****
People are tempted to do things like this:
enum DayOfWeek
{
Sunday,
Monday,
Tuesday,
Wednesday,
Thursday,
Friday,
Saturday
};
...
listBox1.Items.Add(Colors.Red);
listBox1.Items.Add(Colors.Green);
listBox1.Items.Add(Colors.Blue);
listBox1.Items.Add(Colors.White);
listBox1.Items.Add(Colors.Black);
Or this:
listBox1.Items.Add(System.Drawing.Color.Red);
listBox1.Items.Add(System.Drawing.Color.Green);
listBox1.Items.Add(System.Drawing.Color.Blue);
listBox1.Items.Add(System.Drawing.Color.White);
listBox1.Items.Add(System.Drawing.Color.Black);
...
panel1.BackColor = (System.Drawing.Color)listBox1.SelectedItem;
Looks elegant, but is just another form of hard-coding.
In my experience, ToString is not good for much more than debugging.
Except maybe for the DateTime object, and very-very few others.
But even the DateTime.ToString is easy to misuse, because very often
developers pass a format string, and that is not in resources.
And even if it is, it is separate from the main string format:
"File updated at {0}"
"dd/mm/YYYY"
vs. (for example):
"File updated at {0=dateTime:dd/mm/YYYY}"
I find the second form better.
You can see the enum thing showing up quite often:
http://msdn.microsoft.com/chats/transcripts/vstudio/05_1006_csharpide.aspx
(note that the answer is "if you're at the point where you need customized
behavior for this enumerated type, then it's time that you wrote a class for
that purpose instead")
http://www.thescripts.com/forum/thread245727.html
--
Mihai Nita [Microsoft MVP, Windows - SDK]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email
Mihai N.
> to deal with in terms of bad program practice. Typing is not the real
> cost, and minimizing it is irrelevant.
<just_kidding>
I think saving typing is a good way to increase productivity!
For this I recomend creating a header file with aliases to the most used
APIs:
#define MB(m,t,b) MessageBox(NULL,m,t,b)
#define LS(id) LoadString(g_hInst,id)
#define MBL(m,t,b) MessageBox(NULL,LS(m),LS(t),b)
...
Then you can do cool stuff like:
#include "mini.h"
MBL(msgID,titleID,MB_OK);
And (of course), not indent and no new lines.
For a normal application you can get up to 15% less typing if you don't use
CR or TAB.
</just_kidding>
Tom Serface
Tom
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:xh7bh.16779$9v5....@newssvr29.news.prodigy.net...
MrAsm
<nmihai_y...@yahoo.com> wrote:
><just_kidding>
>
>I think saving typing is a good way to increase productivity!
Folks: Microsoft helps us with IntelliSense/IntelliType, what's the
problem with the type-saving? ;)
MrAsm
MrAsm
<d...@remove-this.dcsoft.com> wrote:
>Calm down. We both want code readability. Do you honestly think the
>overhead of a member variable is worth saving one call to GetDlgItem() that
>does not require any member cast, as in
>
> GetDlgItem(IDC_BUTTON_BROWSE)->EnableWindow(FALSE);
>
>This is very readable.
I agree. And IMHO it is also good if there are several controls and we
need some iteration on them.
>names like IfThisIsTheFirstTimeInTheLoop as I've seen people who have the
>same hot button have done.
"In medio stat virtus" (Latin)
:-)
"FirstIteration" could be a good name, and "fi" or "frstitr" no; I
think all of us agree on this :)
MrAsm
BobF
I agree. However, CodeBlocks is getting close. The point is that MSFT has
created a new language that only serves one purpose; keep it proprietary.
Tom Serface
typing if used wisely. I tend to type faster than I can think (not always a
benefit) so the typing thing doesn't bother me much. I think anyone who
wants a career as a programmer should learn to be a touch typist. I can
certainly type faster than I can write. I always tell people when they want
me to fill out forms to send them on email, "I don't do analog".
Tom
"MrAsm" <inv...@invalid.com> wrote in message
news:d2oqm25g8vlja6g7i...@4ax.com...
Tom Serface
anything besides the functions of CWnd that morph through. Also, to be
technically correct you should check the return on GetDlgItem() to ensure
that it is not NULL before calling a function. The HWND returned could be
NULL.
I tend to use this function sparingly and try to use control variables
instead, but there are times when this is useful none the less.
Tom
"MrAsm" <inv...@invalid.com> wrote in message
news:ecoqm29l6aq357p8a...@4ax.com...
Tom Serface
I don't think that was the "only" reason C# was created. I took a class in
it and have done some programming and I find it much easier to do simple
tasks so I think there is some benefit as a direction of an "easier" to use
syntax. There is nothing keeping it proprietary to Windows either. I
believe you could write a CLR for any OS and MSFT would allow others to do a
port of C# e.g., http://www.mono-project.com/Main_Page.
I'm not sure how well that will catch on, but it certainly leaves things
open ended.
That said, MSFT C, C++, [insert here] has always had special stuff for
Windows developement. To be fair, so did Borland C++ and Symantec C++, and
others.
All of that said, I fully believe that MSFT would love to lock people into
Windows and I can't blame them. Every programmer wants to do things in
their code that encourage their users not to go elsewhere.
Tom
"BobF" <rNfOrS...@charter.net> wrote in message
news:n32ns81z3alr$.1ipu05qilumgu$.dlg@40tude.net...
MrAsm
wrote:
>IntelliSense is great when it works and you are correct, it does save some
>typing if used wisely. I tend to type faster than I can think (not always a
>benefit) so the typing thing doesn't bother me much. I think anyone who
>wants a career as a programmer should learn to be a touch typist.
>I can
>certainly type faster than I can write.
Me, too! :)
>I always tell people when they want
>me to fill out forms to send them on email, "I don't do analog".
:)
MrAsm
MrAsm
wrote:
>The problem with this, of course, is you would have to cast it if you wanted
>anything besides the functions of CWnd that morph through.
I see no problem about casting...
>Also, to be
>technically correct you should check the return on GetDlgItem() to ensure
>that it is not NULL before calling a function. The HWND returned could be
>NULL.
Hmm... yes, you're right about this! The code that does not check for
GetDlgItem() returning NULL is not very robust...
Thanks for this hint!
MrAsm
Joseph M. Newcomer
On Wed, 29 Nov 2006 05:25:33 GMT, "David Ching" <d...@remove-this.dcsoft.com> wrote:
>"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
>news:7k1qm2944cukieqbb...@4ax.com...
>
>> I have found that "least typing" is about the single worst excuse I've had
>> to deal with in
>> terms of bad program practice. Typing is not the real cost, and
>> minimizing it is
>> irrelevant.
>
>Well, it should be obvious that the less typing I do, the less code you have
>to read and digest, and the faster you will comprehend it. I'm not talking
>about one character variable names.
****
Clear code does not imply small code. Years of trying to decrypt small code has convinced
me of this
****
>
>
>> Wow! TAKING UP SPACE! That is ALMOST as lame an excuse as "minimal
>> typing". Especially
>> because creating control variables doesn't take up any space in the
>> message map. And wow!
>> It MIGHT ACTUALLY TAKE UP SPACE IN THE HEADER FILE! Oh, dearie me,
>> whatever shall I do?
>>
>
>Calm down. We both want code readability. Do you honestly think the
>overhead of a member variable is worth saving one call to GetDlgItem() that
>does not require any member cast, as in
>
> GetDlgItem(IDC_BUTTON_BROWSE)->EnableWindow(FALSE);
>
>This is very readable.
****
But, if youa re into typing optimization
c_Browse.EnableWindow(FALSE);
takes even less typing, so you aren't even being consistent! The overhead of a member
variable is so infinitesimal that even talking about it as if it matters in the slightest
makes me worry.
****
>
>Excuse me, the member variable goes into the DDX section, not the message
>map. I could make up some lame excuse of how busy I am or how hard it is to
>go across the room and look up a book as some people here do, but I won't.
****
And wow, one line in the DDX section! How could the program ever recover from such
profligate use of code space? Get real. If I have 20 lines, or 21 lines, in my DDX
section isn't even a measurable difference in most programs (too many decimal places
required to express its percentage increase in program size). Again, this isn't even
worthy of consideration. It's just a line of code, executed ONCE per instantiation of the
dialog template!
****
>
>
>> These are insane reasons! Space has NEVER been the issue for trivial data
>> structures like
>> a class variable for a window. If you are going to "optimize" something,
>> at least have
>> some rational justification for the "optimization". These are not
>> optimizations; they
>> merely allow you to have two different ways of accomplishing the same
>> thing, one easy to
>> use (binding control variables), one hard to use (GetDlgItem with
>> casting). Choose the
>> easy, object-oriented method and use it uniformly.
>>
>> These are the kinds of programs I make money repairing...
>
>(rolling eyes) I could say I make money fixing non-statically linked
>programs written with a philosophy that an installer is absolutely necessary
>and taking up unnecessary megabytes of redistributables, but what's the use?
*****
Ah, but these programs aren't broken. The ones I have to fix don't actually
work...usually because of the complexity the "optimizations" have created, which, over
time, lead to change here breaking behavior there.
****
>
>
>> If the right way is to use the raw API, use it. If the right way is the
>> .NET way, use it.
>> But for goodness sake, don't use completely silly reasons such as the
>> amount of typing as
>> justification! This is how we got a lot of one-letter program names in
>> Unix! It didn't
>> make sense in Unix, it never made sense in any context, and it certainly
>> doesn't make any
>> sense today.
>>
>
>[long unnecssary anecode snipped]
>
>I honestly think you go out of your way to give people a really hard time
>when if you stop and READ what they're saying, you will know they're not
>saying what you're going off on a tangent about.
>
>
>> "Minimizing typing" is one of my hot buttons. It is ALWAYS a poor
>> justification for
>> writing bad code.
>
>No it's not. It can be when taken to an extreme, but we are both
>professionals that don't do that. At least I think not. And I hope that
>you don't overreact to your hot button by choosing 40 character variable
>names like IfThisIsTheFirstTimeInTheLoop as I've seen people who have the
>same hot button have done.
****
Simple variable names with local scope suffice. COmplexity of variable names arises when
too many are needed. This is rarely appropriate. In fact, one-character names often
work; it is not uncommon to see, in my code
{ /* create caption */
CString s;
s.Format(...);
dosomethingwith(s);
} /* create caption */
I just create the scopes as needed. The code is easily written, read, and is easily
maintained because the scope of the name is only a few lines, and within that scope its
purpose is obvious. Variables with class extent tend to have more meaningful names; the
rare global variable usually has a highly descriptive name, perhaps 8-10 characters in
length, although occasionally longer if appropriate.
Consistent usage of paradigms is important. If someplace you use GetDlgItem and someplace
you use a member variable, you now have to remember which paradigm you used. This adds
gratuitous complexity to a simple task. Since, under maintenance, things get added, you
now have to keep this sorted out. And where you first thought you were going to use it
just once, you find that over time you use it just-once-more (why create a member
variable? It's just once more!) and soon you have a blend where some variables are used
lots of times, but with GetDlgItem, and others are used only a few times (with member
variables). The decision is lost in history (see my bridge-color-problem essay), and to
the next maintainer, it is very confusing.
I rarely maintain my code; it is handed off to the paying client, and it will be
maintained by their staff most of the time, and I have to do things in a completely
consistent fashion or I will only confuse them, and the result can be catastrophe. So
I've learned to be absolutely consistent in my usage of any paradigm, so as to minimize
unpleasant surprises for the next maintainer.
*****
>
>
>
>> I am less interested in power and more interested in writing robust code
>> that is clear and
>> easy to maintain. C# provides a great deal of the power I need; in fact,
>> my one major C#
>> application had no need for native code at all (it did take me a while to
>> discover how to
>> do couple things, but what I needed was actually there). It's not like
>> VB, which is
>> virtually unusable by a serious programmer.
>>
>> Functionality matters, robustness matters, readability matters,
>> time-to-market matters,
>> and maintainability matters. Minimizing typing is not even worthy of
>> discussion, it is so
>> bogus. C# does pretty well in these areas. It's just another language,
>> with some
>> reasonably cool features. If it had doc/view, I think my customer base
>> would find it more
>> acceptable.
>
>Fine, no argument with the above. It's your misapplication to what I say
>that I object to. You treat your peers (I have just as much Windows
>experience as you do, maybe your years of punch cards makes you feel
>superior) as students in your intro classes.
****
Say something silly and I will jump on it. Especially something which I know has led to
problems in the past. One of the ways I've learned to not make mistakes is by making a
lot of them myself, and learning to regret them, and making sure I don't make them a
second time. Adding gratuitous complexity to a program by introducing alternative
paradigms for accomplishing the same task ranks high on my list of things I don't do any
longer because I've learned the hard way that adding unnecessary complexity is always a
losing idea. To misquote Einstein, a program should be as complex as necessary, but not
more so.
****
Joseph M. Newcomer
>On Wed, 29 Nov 2006 05:25:33 GMT, "David Ching"
><d...@remove-this.dcsoft.com> wrote:
>
>>Calm down. We both want code readability. Do you honestly think the
>>overhead of a member variable is worth saving one call to GetDlgItem() that
>>does not require any member cast, as in
>>
>> GetDlgItem(IDC_BUTTON_BROWSE)->EnableWindow(FALSE);
>>
>>This is very readable.
>
>I agree. And IMHO it is also good if there are several controls and we
>need some iteration on them.
****
As soon as you say "the overhead of..." in a context in which the overhead is so
overwhelmingly irrelevant, you lose. The myth of "overhead" is vastly overplayed. Let me
say it emphatically: THERE IS NO ISSUE OF OVERHEAD TO CREATE A MEMBER VARIABLE. To even
talk about "overhead" in this context means you are focusing on the wrong problem!
****
>
>
>>names like IfThisIsTheFirstTimeInTheLoop as I've seen people who have the
>>same hot button have done.
>
>"In medio stat virtus" (Latin)
>:-)
>
>"FirstIteration" could be a good name, and "fi" or "frstitr" no; I
>think all of us agree on this :)
>
>MrAsm
Joseph M. Newcomer
joe
On Tue, 28 Nov 2006 22:24:33 -0800, "Mihai N." <nmihai_y...@yahoo.com> wrote:
>> I have found that "least typing" is about the single worst excuse I've had
>> to deal with in terms of bad program practice. Typing is not the real
>> cost, and minimizing it is irrelevant.
>
><just_kidding>
>
>I think saving typing is a good way to increase productivity!
>
>For this I recomend creating a header file with aliases to the most used
>APIs:
>
>#define MB(m,t,b) MessageBox(NULL,m,t,b)
>#define LS(id) LoadString(g_hInst,id)
>#define MBL(m,t,b) MessageBox(NULL,LS(m),LS(t),b)
>...
>
>Then you can do cool stuff like:
>
>#include "mini.h"
>MBL(msgID,titleID,MB_OK);
>
>And (of course), not indent and no new lines.
>For a normal application you can get up to 15% less typing if you don't use
>CR or TAB.
>
></just_kidding>
Joseph M. Newcomer
joe
Joseph M. Newcomer
****
Then I agree with you: I've found the same problems, and can't understand how they could
have messed up such a simple concept so badly. This is one of my serious frustrations
with the C# environment---that it looks a lot like something from the 1980s, say, before
we had a resource editor. Does anyone else remember editing resource.h, string tables,
icons, bitmaps, etc. by hand prior to VS? It was no fun, and I keep feeling like I've
gone through a time warp back to that time.
*****
****
Absolutely. Fortunately, I didn't have to deal with internationalization in my one major
C# product, but I didn't do anything like the above, for the same reason you cite.
****
>
>In my experience, ToString is not good for much more than debugging.
***
One other context: serialization of data in and out, where the actual text of the enum
doesn't matter, but being able to convert it from an external to an internal
representation does. The external representation is not visible to the end user, so
interationalization is less critical.
****
>Except maybe for the DateTime object, and very-very few others.
>But even the DateTime.ToString is easy to misuse, because very often
>developers pass a format string, and that is not in resources.
>And even if it is, it is separate from the main string format:
> "File updated at {0}"
> "dd/mm/YYYY"
>vs. (for example):
> "File updated at {0=dateTime:dd/mm/YYYY}"
>I find the second form better.
>
>You can see the enum thing showing up quite often:
>
>http://msdn.microsoft.com/chats/transcripts/vstudio/05_1006_csharpide.aspx
>(note that the answer is "if you're at the point where you need customized
>behavior for this enumerated type, then it's time that you wrote a class for
>that purpose instead")
>
>http://www.thescripts.com/forum/thread245727.html
****
Thanks for the pointers.
joe
****
Alexander Grigoriev
with punch card input (no, I'm not that old, that's what Soviet had in
1982). To prepare the cards, one had to hand-write the code on math squared
paper and hand it to the punch-typists. That helped me to develop neat and
fast (analog) form-filling skill! Later (in 1984), our lab got a soviet
PDP11/23 clone (Electronica 100/25), with punched tape input.
"Tom Serface" <tser...@msn.com> wrote in message
news:%23$HPpx8EH...@TK2MSFTNGP02.phx.gbl...
David Ching
> The problem with this, of course, is you would have to cast it if you
> wanted anything besides the functions of CWnd that morph through. Also,
> to be technically correct you should check the return on GetDlgItem() to
> ensure that it is not NULL before calling a function. The HWND returned
> could be NULL.
>
> I tend to use this function sparingly and try to use control variables
> instead, but there are times when this is useful none the less.
>
Yes, as you say. FWIW, if GetDlgItem() crashes because of a NULL pointer,
the DDX control variable would be toast also... GetDlgItem() NULL pointers
are quickly found in debug sessions as it crashes right away if the control
isn't there, and it's one of those return values I feel I can safely ignore.
Yes it saves time, yes it saves typing, yes it makes the code more readable,
and no, my code is not more unstable because of it.
If I find I have to cast GetDlgItem() at that time I'll create a DDX control
variable instead, because at that point the code would be more readable with
a DDX variable. The whole thing is code maintainability, which
conicidentally has a lot in common with less typing.
-- David
David Ching
> Say something silly and I will jump on it. Especially something which I
> know has led to
> problems in the past. One of the ways I've learned to not make mistakes
> is by making a
> lot of them myself, and learning to regret them, and making sure I don't
> make them a
> second time. Adding gratuitous complexity to a program by introducing
> alternative
> paradigms for accomplishing the same task ranks high on my list of things
> I don't do any
> longer because I've learned the hard way that adding unnecessary
> complexity is always a
> losing idea. To misquote Einstein, a program should be as complex as
> necessary, but not
> more so.
I think our code is a lot more similar than our arguments would have one
believe. When it comes down to what code we actually type in, our code
looks similar, but our philosophies are different. Given that, I just don't
feel the need to lecture highly qualified programmers as if they are infants
as you do because I give them the benefit of the doubt that they will figure
it out, and ridiculing them as you do serves no good purpose. Since you do
though, you can be sure I'll continue to put it in your face whenever you
say things that are plain "silly" as you put it. You have a lot of
experience, but you are just one person, and I think sometimes you forget
that. I think you're just used to no one questioning you, and that's not a
good thing for your attitude or the environment of this newsgroup.
-- David
Tom Serface
encountered"). I have seen times where the NULL is returned during a
runtime session in release mode, but I have to admit they are rare. Most of
the time (like allocating memory) it just works. I don't ignore it often,
but I don't know that I want to die on that hill either :o)
I'm stll confused (unless I'm just reading it wrong) why you think that is
easier to type than hooking into a control variable? Do you find it
cumbersome to set up the control variables? I have trouble remembering
either the IDC_ ID's or the control variable names, but at least I can type
something like "this." and get a list of my member variables so I don't have
to remember that name (so long as my memory is working well enough to
recognize it when it sees it again).
The typing thing, as mentioned, is not a huge issue with me. I can type
GetDlgItem() pretty quickly.
Tom
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:8Tibh.16882$9v5....@newssvr29.news.prodigy.net...
![Doug Harrison [MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjVvzhOQGbT9K0Re6Qg-OU4VGuHq0tAdTu01YlmIjUGm6t_o8g=s40-c)
Doug Harrison [MVP]
wrote:
>Do you honestly think the
>overhead of a member variable is worth saving one call to GetDlgItem() that
>does not require any member cast, as in
>
> GetDlgItem(IDC_BUTTON_BROWSE)->EnableWindow(FALSE);
>
>This is very readable.
Questions of readability aside, there are some problems with that:
1. CWnd::GetDlgItem throws an exception if it fails, so delaying the
binding of HWND to CWnd until first use introduces an exception safety
issue into code that uses this technique.
2. Frequently, that "one call" becomes two or more, so you have to go back
and change the usage (or not, sometimes people forget/overlook it).
3. All too often, people follow the bad MSDN examples and cast the
GetDlgItem result in bogus ways.
These problems are avoided by associating member variables with the
controls; the exception safety issue of (1) is folded into the initial
DoDataExchange, and downcasting works right in all cases for (3), for those
rare times when you actually need to use GetDlgItem. If you just plain like
to use GetDlgItem, I'd recommend using ::GetDlgItem for those controls that
you haven't bound to member variables. This avoids the problem with (1),
and since you can't cast an HWND to (say) a CMyButton*, you won't be
tempted to perform a bogus cast.
--
Doug Harrison
Visual C++ MVP
Doug Harrison [MVP]
wrote:
><just_kidding>
>
>I think saving typing is a good way to increase productivity!
>
>For this I recomend creating a header file with aliases to the most used
>APIs:
>
>#define MB(m,t,b) MessageBox(NULL,m,t,b)
>#define LS(id) LoadString(g_hInst,id)
>#define MBL(m,t,b) MessageBox(NULL,LS(m),LS(t),b)
>...
>
>Then you can do cool stuff like:
>
>#include "mini.h"
>MBL(msgID,titleID,MB_OK);
>
>And (of course), not indent and no new lines.
>For a normal application you can get up to 15% less typing if you don't use
>CR or TAB.
>
></just_kidding>
To give sort of the contrary view, but in the same spirit, here's something
I ran across a long time ago and saved. Hope you like it... (Obligatory
quiz: What about it is illegal?)
From: Poul_Cost
Date: Thursday, July 27, 1995 5:25 PM
To: Developer to Developer BBS
Subject: Writing Cool C
Writing Cool C !
Just wanted to check out that you gnarly dudes are using the latest and
greatest software technology fer yer rad code to make it easy for the
dudes who have to read it. The hip new way to write readable C code
involves the use of a few simple defines.
#define like {
#define man ;}
#define an ;
#define SayBro /*
#define CheckItOut */
SayBro like, this is some rad program, so CheckItOut
like
a = b
an
c = d
man
SayBro , like who needs help from them compiler choads anyway?
THIS is the way to write CLEAR code. I mean really! CheckItOut
like SayBro this is ShellSort straight out of the white book, but in
a readable form.
CheckItOut man
#define YoDude for(
#define OK )
#define is =
#define AND &&
#define as
#define Do
#define long
#define some
#define make
#define garbage
#define FAROUT
shell(v, n) SayBro sort v[0]...v[n-1] into increasing order CheckItOut
int v[], n;
like int gap, i, j, temp;
YoDude gap is n/2 an as long as gap > 0 Do some garbage an make gap /=2 OK
YoDude i is gap an as long as i < n Do some garbage an make i++ OK
YoDude j is i - gap an as long as j >= 0 AND v[j] > v[j+gap] Do
some
garbage an make j -= gap OK
like
temp is v[j] an
v[j] is v[j+gap] an
v[j+gap] is temp
man
FAROUT man
Doug Harrison [MVP]
wrote:
>If I find I have to cast GetDlgItem() at that time I'll create a DDX control
>variable instead, because at that point the code would be more readable with
>a DDX variable.
That's an issue of correctness, not readability.
David Ching
> Good point about DDX not working either (you get a dumb message like
> "error encountered"). I have seen times where the NULL is returned during
> a runtime session in release mode, but I have to admit they are rare.
> Most of the time (like allocating memory) it just works. I don't ignore
> it often, but I don't know that I want to die on that hill either :o)
>
Yeah, how much to check for errors like this and how to handle them is an
art. I am rigorous in reusable libraries and low-level routines, less so in
UI things. If small memory allocations fail, then Windows is hosed and my
app crashing is the least of the user's problems, as Windows is probably
going down. At any rate, detection is one thing, recovery is another. To
me, even if you save your app from crashing, the fact that the operation is
not successfully performed still means the user is screwed, the system is
still screwed, so even things like trying to save the data file and exiting
cleanly will probably fail. Given all this, cluttering up the code with a
lot of if() to detect and recover (if that is even possible) doesn't seem
worth it some cases.
> I'm stll confused (unless I'm just reading it wrong) why you think that is
> easier to type than hooking into a control variable? Do you find it
> cumbersome to set up the control variables? I have trouble remembering
> either the IDC_ ID's or the control variable names, but at least I can
> type something like "this." and get a list of my member variables so I
> don't have to remember that name (so long as my memory is working well
> enough to recognize it when it sees it again).
>
> The typing thing, as mentioned, is not a huge issue with me. I can type
> GetDlgItem() pretty quickly.
>
No, it's not cumbersome to set up DDX variables, and I often do so if I need
to access the controls a lot. But, to use the example of enabling/disabling
various child controls depending on some state, if all you're doing with
those controls is enabling and disabling them, then creating a DDX variable
for each one just for that purpose seems a waste. Even more so with the
IDE's past VC6 which due a total braindead job adding DDX variables. It
puts a new public: section in the header file and adds the variable at the
bottom of the class, it doesn't even try to keep all the DDX variables
together. I have to constantly re-arrange those by hand.
-- David
David Ching
news:nqfrm2tnegrh5o4if...@4ax.com...
>
> 1. CWnd::GetDlgItem throws an exception if it fails, so delaying the
> binding of HWND to CWnd until first use introduces an exception safety
> issue into code that uses this technique.
>
That's a good point and one that I didn't consider, but doesn't DDX throw
the same exception? I really don't consider GetDlgItem() a dangerous method
to constantly be worried about failing, because essentially the only time it
will fail is if your control doesn't exist, and the error will be quickly
exposed in development (i.e. your window won't work right immediately).
> 2. Frequently, that "one call" becomes two or more, so you have to go back
> and change the usage (or not, sometimes people forget/overlook it).
>
Yes, this is an issue. OTOH, if you're talking about maintaining other
people's code, it's just as easy for them to name the DDX variable something
obscure, forcing you to go to the DDX map and seeing what IDC_ control it
maps to, then going to the dialog and seeing what control that really is.
Using GetDlgItem() eliminates having to worry about how the DDX variable is
named. So this whole thing about DDX essentially having no overhead is not
really true. There is some overhead that must be balanced with the
benefits.
> 3. All too often, people follow the bad MSDN examples and cast the
> GetDlgItem result in bogus ways.
>
Like #1, I don't see this as a huge issue. The control is not going to
change type at runtime. It is always going to be a static, edit, or
whatever it was created as, so if you miscast it, the problem will be easily
reproducable and probably will show itself immediately during debug
sessions. Also, the same errors can occur if you change the control type in
the dialog and forget to update the DDX variable.
Thanks,
David
David Ching
I don't see how. If I know the dialog control that I put there is an Edit
box, casting GetDlgItem() to a (CEdit *) seems fine to me. That's what
casting is all about... if we know more than the compiler about the type,
then it's OK to cast. At least that's my interpretation of it.
-- David
Tom Serface
Years ago I used to work on porting the Bourne Shell under Unix and much of
the code was written with macros like this (well not as hip). The C code
looked like shell script. Steve Bourne was one guy who really got into his
own syntax.
Tom
"Doug Harrison [MVP]" <d...@mvps.org> wrote in message
news:7jgrm25im0p69atri...@4ax.com...
Joseph M. Newcomer
As someone who once spent days fighting ` characters, I grew to despise all Unix shells.
(Of course, since they were standardized, there were so many incompatible ones to choose
from...)
joe
Joseph M. Newcomer
>On Wed, 29 Nov 2006 07:41:11 -0800, "Tom Serface" <tser...@msn.com>
>wrote:
>
>>The problem with this, of course, is you would have to cast it if you wanted
>>anything besides the functions of CWnd that morph through.
>
>I see no problem about casting...
****
Until someone changes the control type and all the casting sites have to be re-coded. With
a control variable, it only has to be changed in one place, the declaration of the
variable.
****
>
>>Also, to be
>>technically correct you should check the return on GetDlgItem() to ensure
>>that it is not NULL before calling a function. The HWND returned could be
>>NULL.
>
>Hmm... yes, you're right about this! The code that does not check for
>GetDlgItem() returning NULL is not very robust...
>Thanks for this hint!
>
>MrAsm
Joseph M. Newcomer
open-source-is-God's-Gift-To-Mankind types) friends who were forced to move into the C#
managed-code server-side-applet area have told me (grudgingly) that "C# is Java done
right". I find this interesting, because these are people who were previously convinced
that NOTHING that came from Microsoft was worthy of consideration.
joe
Ian Semmel
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:hR8bh.1160$Py2...@newssvr27.news.prodigy.net...
> "Joseph M. Newcomer" <newc...@flounder.com> wrote in message
> news:7k1qm2944cukieqbb...@4ax.com...
>
>> I have found that "least typing" is about the single worst excuse I've
>> had to deal with in
>> terms of bad program practice. Typing is not the real cost, and
>> minimizing it is
>> irrelevant.
>
> Well, it should be obvious that the less typing I do, the less code you
> have to read and digest, and the faster you will comprehend it. I'm not
> talking about one character variable names.
>
>
As one who has spent decades doing maintenance programming, I can tell you
that this is a fundamental mistake.
One of the things about the advent of pcs and microcomputers, was that
thousands of untrained programmers appeared on the scene who wrote code with
no understanding of the fact that people would have to come along later and
clean it up. They confused the number of source lines in a text file with
what would actually be executed after compilation.
One of the worst practices was using #define to define macros that spread
over multiple (often many) lines instead of using a procedure. The source
code of the program would look really compact, but was impossible to debug.
Many aspects of the "C" programming language lent themselves to encouraging
these "one-liners". Things like 'if (a = b)', one of the most pointless and
error-prone constructs ever devised.
Program code should be clear and "pretty", easily understood by reading it,
not having to go through deciphering complex expressions parenthesized to
some large depth. In many cases I have seen, complex expressions like this
introduce side effects in the middle of them (like post-increment) making it
even harder to understand. And you can't put a breakpoint in the middle of a
source line.
Alexander Grigoriev
at all.
Though some pre-standard compilers might have allowed defining SayBro as an
opening comment.
"Doug Harrison [MVP]" <d...@mvps.org> wrote in message
news:7jgrm25im0p69atri...@4ax.com...
>
Mihai N.
> of the enum doesn't matter, but being able to convert it from an external
> to an internal representation does. The external representation is not
> visible to the end user, so interationalization is less critical.
> ****
should be locale-independent to begin with).
(see also http://www.mihai-nita.net/20051025a.shtml)
--
Mihai Nita [Microsoft MVP, Windows - SDK]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email
Doug Harrison [MVP]
wrote:
>"Doug Harrison [MVP]" <d...@mvps.org> wrote in message
>news:vhhrm2lq412l6tjs1...@4ax.com...
>> That's an issue of correctness, not readability.
>>
>
>I don't see how. If I know the dialog control that I put there is an Edit
>box, casting GetDlgItem() to a (CEdit *) seems fine to me. That's what
>casting is all about... if we know more than the compiler about the type,
>then it's OK to cast. At least that's my interpretation of it.
The thing is, unless the control is bound to a CEdit member variable,
GetDlgItem will create a temporary CWnd and return a pointer to it. Casting
this result to CEdit* is illegal, and this bogus casting works only to the
extent the types are layout-compatible (including vtbls, typeinfo, etc) WRT
your usage.
Doug Harrison [MVP]
wrote:
>"Doug Harrison [MVP]" <d...@mvps.org> wrote in message
>news:nqfrm2tnegrh5o4if...@4ax.com...
>>
>> 1. CWnd::GetDlgItem throws an exception if it fails, so delaying the
>> binding of HWND to CWnd until first use introduces an exception safety
>> issue into code that uses this technique.
>>
>
>That's a good point and one that I didn't consider, but doesn't DDX throw
>the same exception?
Yes, but all the DDX subclassing is done very early in OnInitDialog,
instead of being distributed in time and space.
>I really don't consider GetDlgItem() a dangerous method
>to constantly be worried about failing, because essentially the only time it
>will fail is if your control doesn't exist, and the error will be quickly
>exposed in development (i.e. your window won't work right immediately).
That assumes you have complete code coverage, which of course you ought to
have anyway, but it might not be the case that you have it "immediately"
for GetDlgItem distributed in time and space. Note that GetDlgItem can also
throw CMemoryException, which is a true run-time error, an error that is
not the programmer's fault, which is the case for calling GetDlgItem on a
non-existent control. Certainly, CMemoryException is rare, if not unheard
of on desktop machines, but when I have a choice, I prefer not to entertain
its possibility, because if I know a line of code can throw an exception, I
will have to program accordingly.
>> 2. Frequently, that "one call" becomes two or more, so you have to go back
>> and change the usage (or not, sometimes people forget/overlook it).
>>
>
>Yes, this is an issue. OTOH, if you're talking about maintaining other
>people's code, it's just as easy for them to name the DDX variable something
>obscure, forcing you to go to the DDX map and seeing what IDC_ control it
>maps to, then going to the dialog and seeing what control that really is.
I don't think the answer to that is to (in effect) name the control
GetDlgItem(IDC_WHATEVER). I don't think it's a real problem. Even SDK-style
code uses hWndWhatever for frequently accessed controls. This is easily
coped with.
>Using GetDlgItem() eliminates having to worry about how the DDX variable is
>named. So this whole thing about DDX essentially having no overhead is not
>really true. There is some overhead that must be balanced with the
>benefits.
>
>
>> 3. All too often, people follow the bad MSDN examples and cast the
>> GetDlgItem result in bogus ways.
>>
>
>Like #1, I don't see this as a huge issue.
Judging by another post, it appears you're unaware that when you call
GetDlgItem on (say) an EDIT control that is not bound to a CEdit (or any
other MFC control), you get a pointer to a temporary CWnd, not a CEdit*.
Casting this result to CEdit* is bogus, at best a fragile practice.
>The control is not going to
>change type at runtime. It is always going to be a static, edit, or
>whatever it was created as, so if you miscast it, the problem will be easily
>reproducable and probably will show itself immediately during debug
>sessions.
The problem is, what passes for "correct casting" is actually the "bogus
casting" I'm talking about.
>Also, the same errors can occur if you change the control type in
>the dialog and forget to update the DDX variable.
But at least it didn't start out wrong. :)
Mihai N.
> I can certainly type faster than I can write.
I think this has to do with being in USA, not with being a programmer.
Kids here don't learn how to write, they learn how to type.
cursive writing is teached late, and not exercised enough.
Going thru University and hand-writing thousands of pages,
directly from the teacher's speach, I can definitely write faster than
I type, even if I do type fast enough
(sometimes faster than I can think, as you are saying :-)
Mihai N.
Way cool bro!
But joking aside, this reminds me of something I did some long-long
time ago, while I was in school.
We had a PDP-11, and we had to do our homework on a terminal (serial),
competing for processor time with other 20 guys.
Typing was slow, if someone was in a compiling or linking, you could
have a 3-5 seconds gap between the key-press and the character showing
on screen.
So I had a text file, with escape sequences, redefining the functional keys.
At the beginning of the session you would dump the file to the terminal,
and after that you could have shortcuts (F1=printf, F2=scanf, F3=while,
and so on).
But I did not think to use defines for shorter keywords :-)
(and I would have done that, my grade would have plumeted :-)
David Ching
> The thing is, unless the control is bound to a CEdit member variable,
> GetDlgItem will create a temporary CWnd and return a pointer to it.
> Casting
> this result to CEdit* is illegal, and this bogus casting works only to the
> extent the types are layout-compatible (including vtbls, typeinfo, etc)
> WRT
> your usage.
>
I still don't see the difference between casting a temporary CWnd vs.
casting a "permanent CWnd". The temporary and permanent both have the same
layouts in memory, so casting a pointer to either one yields the same
results. Of course a CEdit * is layout compatible with a CWnd * due to it's
being derived from it. Given this, how is casting in one case "illegal" yet
not the other?
Thanks,
David
David Ching
news:%232$tO7%23EHH...@TK2MSFTNGP02.phx.gbl...
>
> Program code should be clear and "pretty", easily understood by reading
> it, not having to go through deciphering complex expressions parenthesized
> to some large depth. In many cases I have seen, complex expressions like
> this introduce side effects in the middle of them (like post-increment)
> making it even harder to understand. And you can't put a breakpoint in the
> middle of a source line.
>
>
I agree. I'm not talking about humanly obfuscating source code by doing all
the "tricks" you mentioned. I'm talking about not gratuitously using DDX
member variables for no purpose other than it increases object orientation,
as if that were an end unto itself. It's not. It's the means to more
maintainable code, but sometimes it increases maintenance overall.
I'm talking about not checking for NULL from GetDlgItem() because that
decreases maintainable code by cluttering it with if() that will not matter
in the release version.
I'm talking about a general class of error checks that, if the situation
does occur, the Windows is so screwed up that it's unrecoverable anyway, so
don't clutter the source code in a futile attempt to be more correct.
I'm talking about not cluttering up the source code with numerous P/Invoke
declarations when C++/CLI makes them unnecessary.
I don't understand how people can think I'm talking about code obfuscation
when I'm advocating increased code maintainability, not less.
-- David
David Ching
>> Until someone changes the control type and all the casting sites have to
>> be re-coded. With
>> a control variable, it only has to be changed in one place, the
>> declaration of the
>> variable.
>
the control variable is used, unless you only access CWnd class members,
because the usage will most likely be based on the characteristics of the
old control type. Using a DDX variable doesn't buy you anything here.
-- David
BobF
> And Java wasn't proprietary for all those years? Have you ever actually DEALT with Sun?
> joe
>
At least it ran on different vendor's platforms. *If* the vendor chose to
implement the jvm to spec.
I used it a lot. Sun and HP flavors of *nix. I'm not doing much java
these days.
> On Wed, 29 Nov 2006 07:35:52 -0600, BobF <rNfOrS...@charter.net> wrote:
>
>>On Wed, 29 Nov 2006 02:16:13 GMT, David Ching wrote:
>>
>>> "BobF" <rNfOrS...@charter.net> wrote in message
>>> news:mluhprki1zr5.obelrtqtdqn$.dlg@40tude.net...
>>>> On Tue, 28 Nov 2006 12:44:32 -0800, Tom Serface wrote:
>>>>
>>>>> I think the C# group ...
>>>>
>>>> <$.02US>
>>>>
>>>> I think MSFT is trying to save their azz from the OS tools. By creating a
>>>> new language, and migrating core functionality to require it (XAML), they
>>>> keep us locked in buying their proprietary tools.
>>>>
>>>> Oh, and compete with Java ... :-)
>>>>
>>>> </$.02US>
>>>
>>>
>>> Well, I don't see Eclipse or anything else coming close to the Microsoft
>>> IDE's in terms of developer productivity, so locked in or not, I would
>>> choose MS IDE's in a heartbeat.
>>>
>>> -- David
BobF
> Hi Bob,
>
> I don't think that was the "only" reason C# was created. I took a class in
> it and have done some programming and I find it much easier to do simple
> tasks so I think there is some benefit as a direction of an "easier" to use
> syntax. There is nothing keeping it proprietary to Windows either. I
> believe you could write a CLR for any OS and MSFT would allow others to do a
> port of C# e.g., http://www.mono-project.com/Main_Page.
>
Its a matter of timing.
Please don't mistake my comments re: c# to imply I'm an OS bigot. I write
for Windows with MSFT tools.
> I'm not sure how well that will catch on, but it certainly leaves things
> open ended.
>
> That said, MSFT C, C++, [insert here] has always had special stuff for
> Windows developement. To be fair, so did Borland C++ and Symantec C++, and
> others.
>
> All of that said, I fully believe that MSFT would love to lock people into
> Windows and I can't blame them. Every programmer wants to do things in
> their code that encourage their users not to go elsewhere.
>
> Tom
>
> "BobF" <rNfOrS...@charter.net> wrote in message
> news:n32ns81z3alr$.1ipu05qilumgu$.dlg@40tude.net...
BobF
> I used to characterize Java as "C++ done right". A number of (fairly vocal anti-Microsoft
> open-source-is-God's-Gift-To-Mankind types) friends who were forced to move into the C#
> managed-code server-side-applet area have told me (grudgingly) that "C# is Java done
> right". I find this interesting, because these are people who were previously convinced
> that NOTHING that came from Microsoft was worthy of consideration.
> joe
>
I'm not one of those anti-MSFT people. I just don't see the appeal. Maybe
I will once I'm forced into it :)
My frustration is with the forced change to new, multiple languages to get
the same job done. It would be a lot easier for developers to transition
to an improved/fixed Win32/MFC version than to abandon them altogether for
a completely new set of tools.
Tom Serface
Thanks for the culturaly perspective. I hadn't thought of that.
Maybe I just think faster than I think I think.
Tom
"Mihai N." <nmihai_y...@yahoo.com> wrote in message
news:Xns988ADEFA...@207.46.248.16...
Tom Serface
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:O4TfTcHF...@TK2MSFTNGP06.phx.gbl...
> No, if you change a control type, you need to change it in all places
> where
> the control variable is used, unless you only access CWnd class members,
> because the usage will most likely be based on the characteristics of the
> old control type. Using a DDX variable doesn't buy you anything here.
Of course, with the DDX approach you can simple delete the line from the
dialog source and variable from the header file and then re-add it using the
wizard to get the appropriate new value. However, you'll have to be careful
to use the same variable name or you will have to change it elsewhere.
Tom
Tom Serface
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:OP2fwcHF...@TK2MSFTNGP05.phx.gbl...
> I don't understand how people can think I'm talking about code obfuscation
> when I'm advocating increased code maintainability, not less.
Come on, own up, you're just trying to secure your job like the rest of us
:o)
Tom
Tom Serface
successful at having OS momentum for years and certainly providing tools
that help encourage people to stay in a Windows enviroment has added to that
momentum.
Tom
"BobF" <rNfOrS...@charter.net> wrote in message
news:npgnkbhf43ft.l...@40tude.net...
Tom Serface
"BobF" <rNfOrS...@charter.net> wrote in message
news:1ddteubcskgs5.m...@40tude.net...
> I'm not one of those anti-MSFT people. I just don't see the appeal.
> Maybe
> I will once I'm forced into it :)
I'm not sure anyone is trying to force you. MSFT has improved C++ to
include, at least, most of the .NET functionality that C# has at this point.
> My frustration is with the forced change to new, multiple languages to get
> the same job done. It would be a lot easier for developers to transition
> to an improved/fixed Win32/MFC version than to abandon them altogether for
> a completely new set of tools.
I can't argue with that one for even a second. I like a lot of things
about .NET, but I have a huge investment in using MFC so anything they do to
improve that improves my paradigm.
Tom
Doug Harrison [MVP]
wrote:
>"Doug Harrison [MVP]" <d...@mvps.org> wrote in message
For a CEdit bound to an edit control, GetDlgItem returns a pointer to the
CWnd part of that CEdit object. For an unbound edit control, GetDlgItem
returns a pointer to a plain old CWnd, which isn't part of a CEdit. Casting
the latter to CEdit* is undefined; it amounts to this:
CWnd wnd;
CEdit* p = static_cast<CEdit*>(&wnd);
// Now use p as if it were a CEdit. This is undefined, but it "works"
// to the extent the types are layout-compatible (including vtbls,
// typeinfo, etc) WRT your usage. Actually, the C++ typeinfo is
// different, and using it would likely expose the "fraud".
Note also that at the Windows message level, this plain old CWnd
masquerading as a CEdit has no edit control behavior beyond that embodied
in DefWindowProc. This is another reason downcasting unbound controls can
work only for a very small subset of controls, namely those controls whose
corresponding MFC classes are pure wrappers that have no message handlers.
David Ching
> For a CEdit bound to an edit control, GetDlgItem returns a pointer to the
> CWnd part of that CEdit object. For an unbound edit control, GetDlgItem
> returns a pointer to a plain old CWnd, which isn't part of a CEdit.
> Casting
> the latter to CEdit* is undefined; it amounts to this:
>
> CWnd wnd;
> CEdit* p = static_cast<CEdit*>(&wnd);
> // Now use p as if it were a CEdit. This is undefined, but it "works"
> // to the extent the types are layout-compatible (including vtbls,
> // typeinfo, etc) WRT your usage. Actually, the C++ typeinfo is
> // different, and using it would likely expose the "fraud".
>
> Note also that at the Windows message level, this plain old CWnd
> masquerading as a CEdit has no edit control behavior beyond that embodied
> in DefWindowProc. This is another reason downcasting unbound controls can
> work only for a very small subset of controls, namely those controls whose
> corresponding MFC classes are pure wrappers that have no message handlers.
>
Got it, thank you for the explanation. I'll either use the ::GetDlgItem()
or else not cast the CWnd::GetDlgItem() then.
-- David
MrAsm
<nmihai_y...@yahoo.com> wrote:
>> I can certainly type faster than I can write.
>
>I think this has to do with being in USA, not with being a programmer.
>
>Kids here don't learn how to write, they learn how to type.
>cursive writing is teached late, and not exercised enough.
This problem is not only USA-specific, the same is in Italy. Some days
ago there was an article about that on an important Italian newspaper!
:)
MrAsm
Ajay Kalra
> or else not cast the CWnd::GetDlgItem() then.
Yet another reason for Joe.
---
Ajay
David Ching
news:1164910852.1...@l39g2000cwd.googlegroups.com...
>
> Yet another reason for Joe.
>
What, you're keeping score? :-O
-- David
Joseph M. Newcomer
cursive script, and can barely read it (one of the great joys of high school was that they
no longer required cursive handwriting, and I reverted to printed letters rather than
cursive script). The problem is that my handwriting is largely illegible even to me. (We
have taken to sending each other emails in the same house, from her office to my office or
vice-versa, because that way we know the other will be able to read whatever is intended!)
joe
Tom Serface
Tom
"Ajay Kalra" <ajay...@yahoo.com> wrote in message
news:1164910852.1...@l39g2000cwd.googlegroups.com...