http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Best way to search through STL maps? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/7a79fbddf985eea2?hl=en
* I don't have to tell you... - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/f615b948e5cca45b?hl=en
* Best practices for forward declaring a template function - 3 messages, 2
authors
http://groups.google.com/group/comp.lang.c++/t/9bcbaf09fcb855b8?hl=en
* Segmentation fault but now errors when running Valgrind - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/245ee50d3f1cbab8?hl=en
* fastest way to get a double from a string - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/d15c629d71fd2efc?hl=en
==============================================================================
TOPIC: Best way to search through STL maps?
http://groups.google.com/group/comp.lang.c++/t/7a79fbddf985eea2?hl=en
==============================================================================
== 1 of 2 ==
Date: Sun, Nov 29 2009 2:28 pm
From: Steve
On 29 Nov, 19:37, er <erwann.rog...@gmail.com> wrote:
> Does the question boil down to finding whether
>
> [the] [cat] [sat] [on] [the] [mat]
>
> matches
>
> [the] [cat] [sat] [?] [the] [mat]
>
> where each of the above n-grams are represented by a collection of
> strings and symbol ? is not a question mark but a wildcard?
Yes, succinctly put.
== 2 of 2 ==
Date: Sun, Nov 29 2009 3:00 pm
From: er
On Nov 29, 5:28 pm, Steve <petertwoca...@googlemail.com> wrote:
> On 29 Nov, 19:37, er <erwann.rog...@gmail.com> wrote:
>
> > Does the question boil down to finding whether
>
> > [the] [cat] [sat] [on] [the] [mat]
>
> > matches
>
> > [the] [cat] [sat] [?] [the] [mat]
>
> > where each of the above n-grams are represented by a collection of
> > strings and symbol ? is not a question mark but a wildcard?
>
> Yes, succinctly put.
I have a feeling (yes, nothing more reliable than that as I don't deal
text processing) that working with strings might be easier than
breaking them into tokens that are held by a STL container. And do so
using C++ I would look into Boost.Regex. But probably you already
thought of this and have a good reason to use tokens.
==============================================================================
TOPIC: I don't have to tell you...
http://groups.google.com/group/comp.lang.c++/t/f615b948e5cca45b?hl=en
==============================================================================
== 1 of 3 ==
Date: Sun, Nov 29 2009 2:48 pm
From: Howard Beale
Joshua Maurice wrote:
> At this point, I think your opinions are rather irrelevant because
> you're attacking all of OOP, not just this one small aspect of C++.
> You're saying that X sucks because of some inherent quality of X.
What? Why would that make an argument irrelevant? Getting-shot-in-the-
face sucks because of the inherent quality of getting-shot-in-the-face
that it makes you dead. If something sucks, it sucks. I'm not the
first person in the world to think OOP sucks, and the arguments made
here (against it) are really some of the least original.
> In other words, I now see this as not really an attack on constructor
> destructor order. Any sane OOP requires this constructor destructor
> order. You just dislike OOP in general.
>
> I still think you're wrong, but at least you're not longer acting as
> if blatantly trolling. Your arguments have been much more civil and
> reasonable.
Well fuck that. I won't let that happen again.
> To reply to this specific point:
>
>> For example, have the compiler
>> only call the most-derived class's constructor/destructor and allow
>> the programmer to call bases classes' constructors/destructors if and
>> when needed, in whatever order is safe.
>
> My succinct reply is that I find automatic calling of sub-object
> constructors to be a very useful syntactic sugar which saves typing
> time and bugs (from not having to remember to construct my base class
> sub-objects).
It doesn't save much typing. And it encourages just as many bugs as it
prevents, probably more. And it's inconsistent -- with any other
virtual method, the programmer must choose to call the base class
version if he wants it to be executed, but constructors and destructors
get this special treatment.
> In my years of programming I have never once found
> myself wishing "If only I could delay construction of a sub-object for
> just a little longer"
Yeah, I find it annoying far more often in destructors than in
constructors.
> So, do you really want to allow calling functions on uninitialized or
> de-initialized objects? Again, it breaks all of the standard idioms
> and practices of C++, those which say you're only allowed to operate
> on a "live" object.
Yes, because that's the spirit of C++. If the programmer wants to shoot
himself in the foot, then he should be allowed.
For example, I remember running into the oh-so-popular "OnInitDialog"
bug. For anyone who hasn't seen it before, it's a textbook example of
the behavior we're talking about. The function OnInitDialog() is a
method in the MFC's CDialog class. You're expected to override the
function and initialize your own dialog's controls there. And just
about everyone runs into this weird assertion that looks something like
this:
ASSERT(::IsWindow(m_hWnd))
I mean seriously, EVERY SINGLE newbie EVER hits this bug on their first
foray into MFC. The reason for the assertion is that you've done this:
BOOL MyDialogClass::OnInitDialog()
{
my_control_1.do_something();
my_contril_2.set_something("string");
return CDialog::OnInitDialog();
}
You need to call the base class version *before* doing anything with the
controls. But you're free to do other things (setup data structures, or
whatever) before. That's the nature of the beast. You need to
understand what the base class does before you go deriving your own
class from it. Constructors and destructors don't need to be any
different. Hitting an ASSERT() is good if it encourages the newbie to
understand what the code he's using is actually doing.
== 2 of 3 ==
Date: Sun, Nov 29 2009 3:06 pm
From: Howard Beale
Krice wrote:
> try some other language. I have no difficulties with
> C++, but then again I'm a genius, far superior than
> average people.
I already know this well. I could tell instantly from the eloquence of
your posts that you are "far superior than average people." You are
preaching to the choir, my man. I also suspect that you ARE one of the
creators of C++, and probably many other languages. I have brought great
shame to myself and my entire family by speaking out against C++. But in
my defense, I did so only before I knew that YOU were the primary driving
force behind its creation. Please be merciful in your judgement of me.
== 3 of 3 ==
Date: Sun, Nov 29 2009 6:49 pm
From: "Balog Pal"
"Howard Beale"
> For example, I remember running into the oh-so-popular "OnInitDialog"
> bug. For anyone who hasn't seen it before, it's a textbook example of
> the behavior we're talking about. The function OnInitDialog() is a
> method in the MFC's CDialog class. You're expected to override the
> function and initialize your own dialog's controls there. And just
> about everyone runs into this weird assertion that looks something like
> this:
>
> ASSERT(::IsWindow(m_hWnd))
>
> I mean seriously, EVERY SINGLE newbie EVER hits this bug on their first
> foray into MFC. The reason for the assertion is that you've done this:
Ah, more lies. I was a newbie, I used MFC (a lot), never had a problem
wioth that.
Maybe I read the MFC dox? Maybe I used it as intended by creators: click the
message to create the handler -- then put my code where it said
//TODO: insert your code here
? That was certainly *after* the call of the original?
> BOOL MyDialogClass::OnInitDialog()
> {
> my_control_1.do_something();
> my_contril_2.set_something("string");
>
> return CDialog::OnInitDialog();
> }
Quite obviously your control objects are bound wo UI objects in that last
call. MFC uses two-phase setup for many things.
Guess saying
CFile file;
file.Read(....);
is as surprizing -- who woud think to Open the frelling file? By either
calling Open, or using the ctor version that does that.
Or newbie is defined as 'I never RTFM, and have the right to troll if
something will not work as I just hack around random code'?
> You need to call the base class version *before* doing anything with the
> controls.
More precisely, you have to Attach() or use some similar 2nd phase init call
on your controls, directly or indirectly. And in general, have a clue about
both windows and the framework to do anything sensible. If so, work can be
done -- and having the bonus of hitting sensible asserts in *debug* builds
is good, when you do some clear nonsense.
Dereference a NULL pointer or sending message to a unknown window qualifies
fine.
> But you're free to do other things (setup data structures, or
> whatever) before. That's the nature of the beast. You need to
> understand what the base class does before you go deriving your own
> class from it. Constructors and destructors don't need to be any
> different.
And they aren't. Actually nothing fobids an implementation to add turn the
language into a kindergarten, and generate code with asserts on a whim...
Or generate warnings like that.
The mentioned VC does it too -- using this in the member init list triggers
a warning. One that would make sense to those trying to use it right away,
and annoying to those who just store it for later. Same could be done for
any other use case, maybe it would make the build time explode, or annoy
more users who actuallt did RTFM and know what they do -- or just use other
more straightforward means to detect traps as testing. TANSTAAFL. Decision
to just leave it can be is as reasonable, or more so.
There are open source compilers, you can do it yourself, or convince other
developers how cool your way would be -- real life compilers come with cool
extensions.
Sure actual work is hard, while whining is cheap.
==============================================================================
TOPIC: Best practices for forward declaring a template function
http://groups.google.com/group/comp.lang.c++/t/9bcbaf09fcb855b8?hl=en
==============================================================================
== 1 of 3 ==
Date: Sun, Nov 29 2009 2:48 pm
From: er
After reading the FAQ on code that does not work I'm starting from an
minimal example that I actually tested on XCode 3.2 (Mac OS X). But
before I get too carried away could Alf say if Koenif lookup is what
prompted this question
> What's the point?
Back to the example:
#ifndef HEADER1_HPP
#define HEADER1_HPP
namespace n1
{
struct A{ typedef double value_type; };
struct B{ typedef double value_type; };
A::value_type foo(const A& a){ return A::value_type(); }
B::value_type foo(const B& b){ return B::value_type(); }
}
No comments:
Post a Comment