Re: Nomenclature for interger size in C/C++
"Jerry Coffin" <jcoffin@taeus.com>
Wow, Jerry form FIDONET... ;-)
pasa@lib.hu says...
Not to mention the time it takes to get you accustomed to the new
compiler/IDE interface.
Come on, the interface is very similar, and if you're so addicted to the
old
it can be even recreated. But it is completely intuituve and usable
without
problem out of the box. And benefit from both the new features and the
compiler.
The new IDE is quite different, and a much worse design at that -- even
some of Microsoft's employees who work on it have admitted this.
Interesting... I had absolutely no problems with the IDE (2008, didn't try
the ones between) in the transition, except being unable to pause or
intellisense.
And it is mush more resource-hungry. And the help system sucks still (last
good was in vs97, already blown in vs6... )
The
newer compilers are definitely improved, but the newer IDEs,
unfortunately, are not. Even when one does become accustomed to them,
they are far less functional -- some things that VC6 makes quite easy
are next to impossible with any newer version of the IDE (in one case,
they seem to have gone out of their way to ensure against your being
able to do something that used to be quite trivial).
I'm just trying to think of something not doable, but fail. While
enhancements to navigation, browsing, debug info, hilighting are pretty
obvious.
However MFC is badly supported by new compilers that are oriented to
.NET
framework.
What you mean badly? Maybe badly comparing to their support of other
stuff,
but not worse than VC6.
Quite the contrary -- the newer IDEs do not support MFC nearly as well
as VC6 does. Let me give one really trivial example. In VC6, creating a
database front end is quite trivial: in the AppWizard you tell it you
want (for example) ODBC support. You pick out a data source at that
point. It creates a database form view for you by default. You can then
drag and drop controls onto that form, and (the important part) when you
do a control-click on them, it brings up the usual dialog for connecting
the control to a member function, BUT with one important difference from
the usual: it has a drop-down list box, where you can select a database
field for that control.
You're right here, I made it as part of tutorial example. And that is it.
IMO a nice wizard feature, but mostly irrelevant for production code, where
you reorganise the members enough so CLW will not find them anyway. (btw I
recall deleting .clw and .aps as the most frequent activity, also the first
thing to de beyond restarting IDE and clean on 'weird' behavior, those were
routinely messed up by VS.)
Well, then I very fast wrote my own 'wizard' that created structs and more
from all the tables, usable with templated CRecordset-derivate, and any UI
worked with those fields.
And DoDataExchange needed serious rearrangements -- also writing to the DB
make use transactions, etc, the existing model was IIRC not fit for the real
task anyway. I mean in its wizard-created form, I did use CLW as kickstart.
This allows you to write simple database browser type of applications
just about as quickly and easily in VC6 as using something like MS
Access (in fact, if you're going to use a different form layout than
Access does by default, VC6 may be even quicker and easier).
Sure it was neat as a starter, but after I saw the included DaoView
sample -- that works like the said browser without even writing code... I
proceeded along that line.
The newer versions of the IDE don't provide the drop-down list box to
allow you to select the database field. Worse, if you attempt to enter
the correct member variable manually, it'll give an error message and
stop you from using that name. After several attempts (and talking with
a couple of MS employees) it's become apparent that the only way to do
this with a newer IDE is to write all the code by hand.
What means inserting that one line of DDX_* or RFX_* with the ID and the
member? Or something more sophisticated?
Worse, you have
to prevent any of its wizard-like functionality from ever even trying to
parse that code, or it'll give you the same error and stop you from
doing your job.
That was the general case with VS6 too, any tweaked stuff had to be moved
out of the wiz section -- and it was pretty far from supporting all the
message map macros, etc. So I;d think any serious use would need a fair
knowledge of the macros, and being able to read/write them regardless of the
wizard use. Possibly the decision on not caring about some functionality
was based on such thinking...
Sure I agree if someone got exactly what he needed from the old wiz and that
very feature for nuked or spread to unintuitive places, it hurts.
Ah, my merory starts ticking. You had to 'create' a recordset with CLV for
every of your tables, that defaulted to distinct .h and .cpp files. (I put
them all in one, but my collegaues polluted like hell.) And then if the DB
changed there was no sensible way for update... And if you didn't nuke the
..CLW file really bad things followed...