Sunday, January 15, 2017

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

Jeff-Relf.Me <@.>: Jan 14 08:56PM -0800

Jeff-Relf.Me <@.>: Jan 15 06:11AM -0800

Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 15 05:50PM

On 15/01/2017 04:56, Jeff-Relf.Me wrote:
> Reading HTTP, NNTP, IMAP, SMTP, NTP etc.; UTF 8|16 or binary:
[vomit puddle snipped]
 
Your coding style including the use of the "goto" keyword is egregious
mate. Please stop spamming your shit to this newsgroup.
 
/Flibble
woodbrian77@gmail.com: Jan 15 12:12PM -0800

On Sunday, January 15, 2017 at 11:50:25 AM UTC-6, Mr Flibble wrote:
 
Please don't swear here.
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 15 09:10PM

> On Sunday, January 15, 2017 at 11:50:25 AM UTC-6, Mr Flibble wrote:
 
> Please don't swear here.
 
Fuck off you annoying cunt.
kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Jan 15 02:39AM -0800

thanx a lot :-) i will try this approach and post if there is any problem further
kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Jan 15 02:40AM -0800

but when i am storing it in vector for later use will this approach work still?
jt@toerring.de (Jens Thoms Toerring): Jan 15 08:08PM

> but when i am storing it in vector for later use will this approach work
> still?
 
It's not clear which "approach" you mean here. If you store
pointers to memory you allocated with 'new' in the array then
you have to do a 'delete on each of them once you're done with
them to avoid memory leaks. That's completely independent of
were you store them. If you instead use an array of objects
(instead of pointers to objects) then you didn't call 'new'
and thus you also don't call 'delete' - they will vanisch
together with the array. Nor do you have to deallocate me-
mory when you put objects created using std::make_unique()
into the array - you didn't call 'new' yourself, so you
neither call 'delete'.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 15 12:34AM

> better than returning 0. It really doesn't matter what the function
> is, or what it does - it's just a function that is unspecified for
> some inputs.
 
You specified an input for which there is an obviously right answer.
You then asked if one would prefer the right answer or the wrong answer
to be used for ordering coke. That does not illustrate your point
because your point only applies when there is no obviously right answer.
 
--
Ben.
JiiPee <no@notvalid.com>: Jan 15 01:01AM

On 14/01/2017 23:16, David Brown wrote:
> better than returning 0. It really doesn't matter what the function
> is, or what it does - it's just a function that is unspecified for
> some inputs.
 
It depends on how the function is used. If the function tells a HUMAN
how much coke he needs to order, then surely 999999999 if best answer if
the average() function fails (or gets invalid data in). In this case 0
asnwer would be deceiving and might lead to wrong actions (as the human
WOULD follow it because 0 is normal-sounding number).
 
so it depends...
but yes, I cannot say 99999999999 is the best return value in ALL
situations. But in many situations I think it is... especially if its
about showing a human what to do and a human is acting according to that
asnwer.
 
David Brown <david.brown@hesbynett.no>: Jan 15 04:57PM +0100

On 15/01/17 02:01, JiiPee wrote:
> situations. But in many situations I think it is... especially if its
> about showing a human what to do and a human is acting according to that
> asnwer.
 
If you are writing a function and you know how it will be used (such as
passing the result onto a human), then there may be a "best" answer for
invalid input. But if you do not know who will use the function, or how
it will be used, then there is /no/ "best return value" for invalid
input. There is not even a "good" or "usually helpful" return value.
Any value you pick will always be bad for some users. Any effort spent
trying to think of a "good return value" is wasted - it is far better to
spend the effort documenting the function better, naming the function
better, or otherwise making it less likely that your function will be
used incorrectly.
JiiPee <no@notvalid.com>: Jan 15 05:17PM

On 15/01/2017 15:57, David Brown wrote:
> is far better to spend the effort documenting the function better,
> naming the function better, or otherwise making it less likely that
> your function will be used incorrectly.
 
 
How about that exception-options? You would not throw an exception?
 
David Brown <david.brown@hesbynett.no>: Jan 15 07:13PM +0100

On 15/01/17 18:17, JiiPee wrote:
>> naming the function better, or otherwise making it less likely that
>> your function will be used incorrectly.
 
> How about that exception-options? You would not throw an exception?
 
I don't use exceptions in my programming, but certainly it is not
unreasonable to throw an exception when you get invalid input to the
function.
 
But we are just going round in circles - this was already mentioned long
ago, along with halting, logging an error message, giving the user an
error box, and any other way of handling errors.
 
/All/ methods will be bad in some cases. There are /no/ correct ways to
deal with invalid input. Garbage in /always/ gives garbage out. If you
think you can give a "good" error indication, you are wrong. If your
interviewer thinks there is a good solution, he/she is wrong.
 
The best you can do is make it as obvious as possible how the function
/should/ be used, by documentation or naming. You can also change the
specifications of the function (if you are allowed) - if you /specify/
the function to "return the average of a non-empty set, or 0 for empty
sets" or "return the average of a non-empty set, or throw an EmptySet
exception for empty sets", then there are no invalid inputs, and you can
always give the right answer.
 
Failing that, you can think about how it is /likely/ that your function
will be used, and find a way to make it easier for users of the function
to quickly find their error. But you will not succeed in finding a
method that works for /all/ users of your function.
 
 
And here ends this thread for me. Either you understand the point of
what I have written a dozen times, or you don't.
Paul <pepstein5@gmail.com>: Jan 15 04:57AM -0800

Is there ever a time when it is good practice to write
 
 
int main()
{
 
const someType& = // ....
}
 
or int main()
{
 
const int& x = 7;
}
 
I know through testing that the latter example compiles but I've never
seen this used.
 
Thanks,
 
Paul
Bo Persson <bop@gmb.dk>: Jan 15 07:10PM +0100

On 2017-01-15 13:57, Paul wrote:
> }
 
> I know through testing that the latter example compiles but I've never
> seen this used.
 
The first example might be useful if the someType object exist elsewhere
and you don't want to copy it.
 
Avoiding a copy for the value 7 though, seems less than useful.
 
 
 
Bo Persson
Paul <pepstein5@gmail.com>: Jan 15 04:59AM -0800

On Saturday, January 14, 2017 at 11:11:29 PM UTC, David Brown wrote:
 
...
> This is the kind of question you only have to ask if you are dealing
> with other people's code.
...
 
But I've never heard of a software role that doesn't involve "dealing with
other people's code."
 
Paul
David Brown <david.brown@hesbynett.no>: Jan 15 05:01PM +0100

On 15/01/17 13:59, Paul wrote:
> ...
 
> But I've never heard of a software role that doesn't involve "dealing with
> other people's code."
 
The extent to which you are dealing with other people's code can vary a
lot, but in some cases you don't have much interaction with source code
that you haven't written yourself.
 
But my point is that while you might come across code like "int x = 7, y
= f(x);" and therefore you would have to know what it means, it is not
something that (IMHO) you should write yourself.
banmefrom backedby <rothchild.banking.dynasty@gmail.com>: Jan 15 03:58AM -0800

On Sunday, January 8, 2017 at 1:27:12 PM UTC-5, banmefrom backedby wrote:
> i use a back office; and there are very strong indications that can not be denied that the:
> back office is at civil war.
https://sites.google.com/view/legalcounselknowsthatiamalure/home
 
> should i consider the impact on my real-time future?
 
thanks.
legalize+jeeves@mail.xmission.com (Richard): Jan 15 02:53AM

[Please do not mail me a copy of your followup]
 
"Asger Joergensen" <Junk@Asger-P.dk> spake the secret code
 
>> There is only one IDE that comes even close to VS productivity and
>> that is CLion.
 
>Don't forget C++Bulder
 
I forgot about it after having used it 15 years ago :)
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
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)