Friday, March 13, 2015

Digest for comp.lang.c++@googlegroups.com - 25 updates in 7 topics

Luca Risolia <luca.risolia@linux-projects.org>: Mar 06 10:32PM +0100

Il 06/03/2015 18:06, Christopher Pisz ha scritto:
> definition intended?)" and cannot seem to use the string afterward
> without compiler errors that claim it isn't a compatible type. I don't
> follow.
 
According to the language rules "std::istream_iterator<char>()" is a
declaration of "function taking no arguments returning
istream_iterator<char>". To force the compiler to treat the construct as
an expression surround it with extra parentheses:
 
std::string
textToParse(std::istream_iterator<char>(file),(std::istream_iterator<char>()));
Christopher Pisz <nospam@notanaddress.com>: Mar 06 11:06AM -0600

On 3/6/2015 10:54 AM, Christopher Pisz wrote:
> Method 1 :0.012716
> Method 2 :0.361421
> Method 3 :0.141371
 
I take it back, something is fruity with Juha's suggestion. I see a
warning "warning C4930: 'std::string
textToParse(std::istream_iterator<_Ty>,std::istream_iterator<_Ty>
(__cdecl *)(void))': prototyped function not called (was a variable
definition intended?)" and cannot seem to use the string afterward
without compiler errors that claim it isn't a compatible type. I don't
follow. Using msvc 2012.
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
Victor Bazarov <v.bazarov@comcast.invalid>: Mar 06 10:00AM -0500

On 3/5/2015 8:11 PM, Christopher Pisz wrote:
> do similar.
 
> It is fairly often I'd want to copy the contents of one stream to a
> string or to another stream.
 
I took your code and changed it a bit so I could time it on Windows. It
didn't have the ~14-fold difference like in your example, only about
1.5-fold (the iterator method taking longer by ~50%). Run your test
after building it in release (with optimization) and ensure that the
text file has been placed in the file cache (by running a couple times
and only noting the last run). Or swap the methods (call the 2 before
calling 1), just to be sure.
 
The operation is very quick on Windows with shorter files, so profiling
here doesn't make much sense. I would venture to point out, though that
the iterator method makes more function calls, probably.
 
And, after all, it's QoI of the library, of course.
 
V
--
I do not respond to top-posted replies, please don't ask
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Mar 06 01:29PM

On 6 Mar 2015 12:17:09 GMT
> to merge them into a single statement.
> So, the requirement of »one statement«
> really is no requirement.
 
Well at least Christopher does not take the approach of answering a
question where the intent is obvious but the wording slightly amiss
with a pedantically correct but completely useless answer.
 
I think it is generally better to be helpful than to try to be "clever".
 
Chris
Juha Nieminen <nospam@thanks.invalid>: Mar 06 08:19AM

> std::copy(std::istream_iterator<char>(file),
> std::istream_iterator<char>(),
> std::inserter(textToParse, textToParse.begin()));
 
What's the problem with
 
std::string textToParse(std::istream_iterator<char>(file),
std::istream_iterator<char>());
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
bleachbot <bleachbot@httrack.com>: Mar 08 04:04AM +0100

ram@zedat.fu-berlin.de (Stefan Ram): Mar 06 01:59PM

>I think it is generally better to be helpful than to try to be "clever".
 
When one does not know the meaning of words like
»line« or »statement«, it is better to learn it
(when posting into a technical programming newsgroup),
than to accuse others.
ram@zedat.fu-berlin.de (Stefan Ram): Mar 06 12:17PM

>>it's simple, because the rest of the program can always be written
>>in a single line
>Statement. One statement.
 
Whenever one has multiple statements,
one can use a compound statement (block)
to merge them into a single statement.
So, the requirement of »one statement«
really is no requirement.
ram@zedat.fu-berlin.de (Stefan Ram): Mar 06 01:54PM

>Well at least Christopher does not take the approach of answering a
>question where the intent is obvious but the wording slightly amiss
>with a pedantically correct but completely useless answer.
 
If the intent is obvious, then maybe someone can write it down?
 
»While sloppy writing does not invariably mean sloppy
thinking, we've generally found the correlation to be
strong -- and we have no use for sloppy thinkers.
If you can't yet write competently, learn to.«
 
Eric Raymond
 
http://www.catb.org/~esr/faqs/hacker-howto.html#skills4
 
»I have never, ever, ever seen a great software developer
who does not have amazing attention to detail.«
 
http://www.softwarebyrob.com/articles/Personality_Traits_of_the_Best_Software_Developers.aspx
JiiPee <no@notvalid.com>: Mar 08 11:58PM

On 08/03/2015 23:50, Mr Flibble wrote:
 
> Sorry mate but you are my wife now.
 
> Sausages.
 
> /Flibble
 
but yes, that visitor works cool ..... going to implement it to real
code soon
but .... again... its a bit luck that got selected.. there was other
options as well. but difficult to implement in my case
JiiPee <no@notvalid.com>: Mar 08 01:47PM

On 08/03/2015 13:16, Paavo Helde wrote:
> Öö Tiib meant by using the visitor pattern.
 
> hth
> Paavo
 
Well, this one works... just tested:
struct AnimalValues
{
int* intVal;
std::string* strVal;
 
void visit(Dog<int>* dog) { intVal = &dog->m_whatToSpeak; }
void visit(Dog<std::string>* dog) { strVal = &dog->m_whatToSpeak; }
};
...
main:
AnimalValues vals;
farm.getAnimal(0)->accept(&vals);
// now *vals.intVal contains the integer value (5)
farm.getAnimal(1)->accept(&vals);
// now *vals.strVal contains the string value (Willy)
 
 
Well, I am pretty happy for this solution :). Thanks guys (the
suggestion about Visitor helped here)....I think I might go for this
solution (if it just works also with my real project which is a bit more
complex... but it should) this time, its close to my old solution also
so just an improvement.
 
This seems to work best with my real project as well currently.
JiiPee <no@notvalid.com>: Mar 08 01:14PM

On 08/03/2015 13:12, JiiPee wrote:
> farm.getAnimal(0)->accept(&data);
 
> and this data capture the value to intValue or stringValue depending
> what type it is?
 
I would be quite happy for this approach if it works and is the
recommended way.
JiiPee <no@notvalid.com>: Mar 08 01:23PM

On 08/03/2015 13:16, Paavo Helde wrote:
> a compile-time feature, i.e. a template. In other words, the function
> returning Dog must be a template, and it must be instantiated with the
> Dog type, again at compile-time.
 
I see. So something like:
if(farm.animal[0].type == DOG)
Dog* dog = farm.getAnimal<Dog>[0];
 
so must ask it via template argument.
 
JiiPee <no@notvalid.com>: Mar 08 11:45PM

On 08/03/2015 20:40, Mr Flibble wrote:
 
>> I think you just guessed... and were lucky.. heh
 
> In your dreams mate.
 
> /Flibble
 
but, you know even other people they suggested other ways.. so there was
not only one way
JiiPee <no@notvalid.com>: Mar 07 06:46PM

On 07/03/2015 18:37, Marcel Mueller wrote:
> expression.
 
> Probably you are looking for typeid.
 
> Marcel
 
oh you mean using typeid to find out which type it is (with if-blocks)
and the return casted pointer? That might work, but I was thinking is it
doable without if-sections (because there might be 10 different types
later on)?
Marcel Mueller <news.5.maazl@spamgourmet.org>: Mar 07 07:37PM +0100

On 07.03.15 19.29, JiiPee wrote:
> auto foo2()->decltype(a) { return a; }
 
> But it just returns Base type pointer (not the real type).
 
Well, it works as designed. Decltype returns the *declared* type of an
expression.
 
Probably you are looking for typeid.
 
 
Marcel
Richard Damon <Richard@Damon-Family.org>: Mar 07 06:17PM -0500

I see two basic ways to solve you problem.
 
One, is to have all version of speak as overloads in the AnimalBase
class (as virtuals, so the derived classes can redefine, which means it
can't be a template) with run time handling of using a version that
isn't supported for this type of animal. This gives your run time binding.
 
Two, is to have different versions of getAnimal for each type of animal,
which returns the right type of pointer for that animal. This gives you
compile time binding. If might make sense for getAnimal to be a template
function, with an explicitly specified type, and you have the cast in
the template. This seems to be what you are looking for.
 
The issue is that you can't overload on return type or make the static
return type of a function determined at run time.
JiiPee <no@notvalid.com>: Mar 08 01:52PM

On 07/03/2015 20:39, Mr Flibble wrote:
 
> Have a look at the visitor pattern.
 
> /Flibble
 
ye you were right this time :). After long thinking I chose to use it.
How did you know?
Richard Damon <Richard@Damon-Family.org>: Mar 07 10:41PM -0500

On 3/7/15 10:23 PM, JiiPee wrote:
> value (the visitor can use it but not return it). But I ll think about
> if I need it as a return value or not...maybe getting the value by
> reference parameter.
 
The answer to that is to use a setter function instead of directly
accessing the value to set. As to getting the values, do any non-member
function need to know this sort of detail? Remember that inside the
speak function, your this pointer is of the type of the object the
member function is a member of, not the base, so has full access to the
types.
 
Now, if you really are doing all of this work that is dependent on the
type of animal, you probably want the type specified get to return the
right type.
Robert Wessel <robertwessel2@yahoo.com>: Mar 05 09:33PM -0600

>> 969 years.
 
>Oldest human was Methuselah. They knew how to take
>care of themselves and others.
 
 
Even if you make the (rather big) assumption that the bible has
historical accuracy, it does not assert that Methuselah was the oldest
human, but he is the oldest it mentions, and perhaps the oldest in the
genealogy leading to Noah, although that's still something of a
stretch.
Robert Wessel <robertwessel2@yahoo.com>: Mar 06 02:45AM -0600

>> genealogy leading to Noah, although that's still something of a
>> stretch.
 
>OK, oldest documented human was Methuselah.
 
 
Nah.
 
Just hanging around the middle east...
 
En-men-lu-ana, a king of Sumar, reigned for 43,200 years. Presumably
he was alive during that time. There are a bunch of other Sumarian
kings who hung around a really long time.
 
Aži Dahaka ruled for a thousand years. Just ask the Zoroastrians.
David Brown <david.brown@hesbynett.no>: Mar 06 09:49AM +0100

>> genealogy leading to Noah, although that's still something of a
>> stretch.
 
> OK, oldest documented human was Methuselah.
 
There were equally well documented Sumerian kings who ruled for tens of
thousands of years each. The authors of the books of Moses took a lot
of inspiration from Sumerian stories and legends - they probably copied
the habit of exaggerating lifespans too.
 
Other old documented humans include some ancient Persian kings, as well
as many characters from India and the far east.
 
Remember, "documented" does not mean "true" !
Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 07 05:49PM

On Thu, 2015-03-05, Paavo Helde wrote:
>> look like an optional extra instead of being an essential part of the
>> cast.
 
> This just tells that you have not written enough templated C++ code yet.
 
In the sense that if you had, you'd see 'const_cast<LPTSTR>' as the
function, and 'text' as the parameter.
 
For me, C-style casts look uglier nowadays.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
David Brown <david.brown@hesbynett.no>: Mar 08 08:57PM +0100

On 07/03/15 20:44, Jorgen Grahn wrote:
> documentation format, but that's where the full compiler documentation
> is, so you need to have it and be able to navigate it.
 
> /Jorgen
 
I have never found "info" pages to be any use. The gcc manuals are fine:
 
<https://gcc.gnu.org/onlinedocs/>
 
Use the online html, html tarballs, or pdf files according to preference.
 
gcc also comes with a fairly good built in help (with "--help -v" as a
starting point) - recent versions let you get details of different
groups of command-line switches.
Johannes Bauer <dfnsonfsduifb@gmx.de>: Mar 12 10:23AM +0100

On 12.03.2015 10:18, Stefan Ram wrote:
>> And for resource constrained systems, templates are the aboulte worst
 
> Templates fit small-memory systems well when the
> programmer is knowing what he is doing.
 
But this is exactly the criticism about C++ in the original article: You
absolutely *have* to know the implications of what you're doing in
detail or you can introduce a vast array of problems by a single line or
reference (like std::string).
 
It's not transparent by any means what is efficient (and can maybe even
resolved at compile-time) and what will introduce tons of overhead. By
contrast in a language as simple as C it is simply not possible to
intruduce such overhead by seemingly subtle changes in code.
 
Cheers,
Johannes
 
--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)