http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Nomenclature for interger size in C/C++ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/d94de8ebc4095151?hl=en
* Confusion between this and *this on website -- possible error - 2 messages,
2 authors
http://groups.google.com/group/comp.lang.c++/t/76d7c1b69e76fd1d?hl=en
* operator overloading simple question - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/f176f1743eb21cb4?hl=en
* changing istream default delimiter - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/e6d874483e11ae85?hl=en
* STL set lower_bound - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/aa077da047c4f4a1?hl=en
==============================================================================
TOPIC: Nomenclature for interger size in C/C++
http://groups.google.com/group/comp.lang.c++/t/d94de8ebc4095151?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Mar 29 2009 5:43 pm
From: "Balog Pal"
"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...
==============================================================================
TOPIC: Confusion between this and *this on website -- possible error
http://groups.google.com/group/comp.lang.c++/t/76d7c1b69e76fd1d?hl=en
==============================================================================
== 1 of 2 ==
Date: Sun, Mar 29 2009 5:53 pm
From: "Alf P. Steinbach"
* pauldepstein@att.net:
> Below is pasted from a website:
>
> QUOTE BEGINS HERE
>
> HOWTO: Covariant Return Types in C++
> 20060406T0140
>
> Covariant return types are a useful feature of the C++ language that
> could save you from doing some extra, unnecessary work in a few com
> mon situations. They can also make the intended purpose of your
> functions more clear. This HOWTO explains what they are, how to use
> them, a nd gives some common sample applications.
>
> Consider a simple inheritance hierarchy such as that shown here:
>
> Base
> |
> v
> Derived
>
> Often, the derived class has a polymorphic function which returns a
> more specific (i.e. more derived) type than the base class. This is
> per fectly legal, since the pointer is automatically downcast to the
> base class type.
>
> A common use of this (but by no means the only one) is a clone()
> method:
>
> class Base {
> public:
> virtual Base* clone() const
> {
> return new Base(this);
> }
> };
>
> class Derived : public Base {
> public:
> virtual Base* clone() const
> {
> return new Derived(this);
> }
> };
>
> QUOTE ENDS HERE
>
> I would expect to see new Derived(*this) and
> new Base(*this)
Right.
> Is the website in error or am I in error?
The website.
Also the use of the word "downcast" is incorrect and so harebrained that one
suspects the above of being from Microsoft's documentation.
Checking...
No, not Microsoft. But anyways, the author got the "up" and "down" directions
wrong (in C++ "up" is towards Base, "down" is towards Derived).
However, in the author's defense, even Donald Knuth once got the "up" and "down"
directions wrong for drawing tree structures (but in fairness, the convention of
root up was not firmly established when Knuth first wrote the first tome of
TAOCP), and the 'this' instead of '*this' could be a repeato-typo thing.
Cheers & hth.,
- Alf
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!
== 2 of 2 ==
Date: Sun, Mar 29 2009 6:56 pm
From: red floyd
Alf P. Steinbach wrote:
> * pauldepstein@att.net:
>> Below is pasted from a website:
>>
>> QUOTE BEGINS HERE
>>
>> HOWTO: Covariant Return Types in C++
>> 20060406T0140
>>
>> Covariant return types are a useful feature of the C++ language that
>> could save you from doing some extra, unnecessary work in a few com
>> mon situations. They can also make the intended purpose of your
>> functions more clear. This HOWTO explains what they are, how to use
>> them, a nd gives some common sample applications.
>>
>> Consider a simple inheritance hierarchy such as that shown here:
>>
>> Base
>> |
>> v
>> Derived
>>
>> Often, the derived class has a polymorphic function which returns a
>> more specific (i.e. more derived) type than the base class. This is
>> per fectly legal, since the pointer is automatically downcast to the
>> base class type.
>>
>> A common use of this (but by no means the only one) is a clone()
>> method:
>>
>> class Base {
>> public:
>> virtual Base* clone() const
>> {
>> return new Base(this);
>> }
>> };
>>
>> class Derived : public Base {
>> public:
>> virtual Base* clone() const
>> {
>> return new Derived(this);
>> }
>> };
>>
>> QUOTE ENDS HERE
>>
>> I would expect to see new Derived(*this) and
>> new Base(*this)
>
> Right.
>
>
>> Is the website in error or am I in error?
>
> The website.
>
On top of that, they're not even showing covariant return types.
They're showing simple virtual overriding.
It should be:
class Derived : public Base {
public:
virtual Derived* clone() const
{
return new Derived(*this);
}
};
==============================================================================
TOPIC: operator overloading simple question
http://groups.google.com/group/comp.lang.c++/t/f176f1743eb21cb4?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Mar 29 2009 7:14 pm
From: Sam Hu
Thank you so much for all your help,both!And now I have a better
understanding how come C++ is called the most complicated language in
the world!!And here I have one more questions:why we need both const &
non-const version ,and under what situation these 2 are mandatory and
what situation we can just pick one of the 2?
> bool isEqual(const graduate& rhs) const ;
> bool lessThan(const graduate& rhs);
Thanks and best regards,
Sam
==============================================================================
TOPIC: changing istream default delimiter
http://groups.google.com/group/comp.lang.c++/t/e6d874483e11ae85?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Mar 29 2009 7:50 pm
From: "Amadeus W.M."
Is it possible to change the space delimiter in an istream to, say, a
comma? I'm thinking facets, locales and imbue. I want to read a comma
separated file in the exact same way as if it were tab delimited.
If yes, how would I do that?
I know how to do it with get/getline and the like. Changing the delimiter
in the input string just seems more elegant.
Thanks!
==============================================================================
TOPIC: STL set lower_bound
http://groups.google.com/group/comp.lang.c++/t/aa077da047c4f4a1?hl=en
==============================================================================
== 1 of 2 ==
Date: Sun, Mar 29 2009 9:51 pm
From: Obnoxious User
On Sun, 29 Mar 2009 16:07:22 -0700, mattg wrote:
[snip]
>
> class node {
> private:
> int val;
> int val2;
> public:
> node(int v){
> val = v;
> val2 = 0;
> }
> int GetVal() const {
> return val;
> }
> int Do() {
> val2++;
> }
> bool operator<(const node& b) const {
> return val<b.val;
> }
>
> };
>
> and I try calling iter->Do() I get error
>
> test.cpp:80: error: passing 'const node' as 'this' argument of 'void
> node::Do()' discards qualifiers
>
> How would I work around this?
Using 'new' and store pointers.
--
OU
Remember 18th of June 2008, Democracy died that afternoon.
http://frapedia.se/wiki/Information_in_English
== 2 of 2 ==
Date: Sun, Mar 29 2009 11:13 pm
From: mattg
Alright yea, thanks thats probably the reason why I opted with the
messy pointer storage initially. Well, to close this topic up I'd
just like to say its really counter-intuitive to design a method
called lower_bound(x) that finds the y such that x<=y. Coming from a
math background we are very strict on our usage of these technical
terms, and this could probably win an award somewhere for abuse of
notation. As you all probably know a lower bound of a number x in the
reals should be a number y in the reals such that y<=x. Guess the guys
designing STL containers slept through these classes.
On Mar 29, 9:51 pm, Obnoxious User <O...@127.0.0.1> wrote:
> On Sun, 29 Mar 2009 16:07:22 -0700, mattg wrote:
>
> [snip]
>
>
>
>
>
> > class node {
> > private:
> > int val;
> > int val2;
> > public:
> > node(int v){
> > val = v;
> > val2 = 0;
> > }
> > int GetVal() const {
> > return val;
> > }
> > int Do() {
> > val2++;
> > }
> > bool operator<(const node& b) const {
> > return val<b.val;
> > }
>
> > };
>
> > and I try calling iter->Do() I get error
>
> > test.cpp:80: error: passing 'const node' as 'this' argument of 'void
> > node::Do()' discards qualifiers
>
> > How would I work around this?
>
> Using 'new' and store pointers.
>
> --
> OU
> Remember 18th of June 2008, Democracy died that afternoon.http://frapedia.se/wiki/Information_in_English
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en
To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
No comments:
Post a Comment