Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #72763 > unrolled thread

Help needed

Back to article view | Back to comp.lang.c++

Contents

  Help needed Gerry Wolff <gerrywolff65@gmail.com> - 2020-04-03 09:56 -0700
    Re: Help needed Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-04-03 18:18 +0100
      Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-03 12:57 -0500
        Re: Help needed Melzzzzz <Melzzzzz@zzzzz.com> - 2020-04-03 18:17 +0000
          Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-03 16:41 -0500
        Re: Help needed James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-03 14:58 -0400
          Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-03 16:45 -0500
            Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-03 17:52 -0500
        Re: Help needed Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-04-03 20:05 +0000
          Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-03 16:58 -0500
            Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-03 17:50 -0500
            Re: Help needed James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-04 00:15 -0400
              Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-03 23:58 -0500
                Re: Help needed Ian Collins <ian-news@hotmail.com> - 2020-04-04 18:06 +1300
                  Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-04 00:35 -0500
                    Re: Help needed Ian Collins <ian-news@hotmail.com> - 2020-04-04 19:54 +1300
                      Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-04 02:22 -0500
                        Re: Help needed Bo Persson <bo@bo-persson.se> - 2020-04-04 10:33 +0200
                          Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-04 04:55 -0500
                            Re: Help needed David Brown <david.brown@hesbynett.no> - 2020-04-04 13:02 +0200
                              Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-04 07:15 -0500
                                Re: Help needed David Brown <david.brown@hesbynett.no> - 2020-04-04 16:49 +0200
                                  Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-05 04:10 -0500
                                    Re: Help needed Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-04-05 16:31 +0100
                                      Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-05 11:37 -0500
                              Re: Help needed Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-04 14:19 +0200
                                Re: Help needed David Brown <david.brown@hesbynett.no> - 2020-04-04 16:57 +0200
                        Re: Help needed James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-04 10:51 -0400
                    Re: Help needed James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-04 10:44 -0400
                      Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-05 04:06 -0500
                        Re: Help needed James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-05 11:04 -0400
                          Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-05 11:31 -0500
                            Re: Help needed James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-05 16:59 -0400
                              Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-05 21:38 -0500
                Re: Help needed "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-04-04 13:51 +0200
                  Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-04 08:33 -0500
                    Re: Help needed Ian Collins <ian-news@hotmail.com> - 2020-04-05 07:35 +1200
                      Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-05 04:19 -0500
                        Re: Help needed James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-05 11:27 -0400
                    Re: Help needed James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-04 22:27 -0400
                  Re: Help needed Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-04-04 14:50 +0100
                Re: Help needed James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-04 10:27 -0400
                  Re: Help needed Ian Collins <ian-news@hotmail.com> - 2020-04-05 07:37 +1200
                  Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-05 03:45 -0500
            Re: Help needed Paavo Helde <myfirstname@osa.pri.ee> - 2020-04-04 09:02 +0300
              Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-04 01:20 -0500
                Re: Help needed Ian Collins <ian-news@hotmail.com> - 2020-04-04 19:43 +1300
                  Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-04 02:10 -0500
                    Re: Help needed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-04 01:58 -0700
                      Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-04 05:04 -0500
                    Re: Help needed Paavo Helde <myfirstname@osa.pri.ee> - 2020-04-04 14:37 +0300
                      Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-04 07:25 -0500
                        Re: Help needed Paavo Helde <eesnimi@osa.pri.ee> - 2020-04-04 17:39 +0300
                          Re: Help needed Ned Latham <nedlatham@woden.valhalla.oz> - 2020-04-05 04:02 -0500
    Re: Help needed Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-03 19:35 +0200
      Re: Help needed Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-03 20:01 +0200
        Re: Help needed Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-04 16:16 +0200
          Re: Help needed Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-04 18:58 +0200
      Re: Help needed Christian Gollwitzer <auriocus@gmx.de> - 2020-04-03 22:01 +0200
        Re: Help needed Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-04-03 21:05 +0100
          Re: Help needed Bo Persson <bo@bo-persson.se> - 2020-04-04 02:10 +0200
        Re: Help needed Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-04-04 08:19 +0000
        Re: Help needed Gerry Wolff <gerrywolff65@gmail.com> - 2020-04-05 02:56 -0700
      Re: Help needed Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-04 01:14 +0100
      Re: Help needed Gerry Wolff <gerrywolff65@gmail.com> - 2020-04-05 02:49 -0700
    Re: Help needed Sam <sam@email-scan.com> - 2020-04-04 16:30 -0400
      Re: Help needed Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-04-05 05:58 +0100
      Re: Help needed Gerry Wolff <gerrywolff65@gmail.com> - 2020-04-05 03:21 -0700
        Re: Help needed Juha Nieminen <nospam@thanks.invalid> - 2020-04-07 06:33 +0000
          Re: Help needed Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-04-07 10:39 +0000

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#72798

David Brown wrote:
> Ned Latham wrote:
> > Bo Persson wrote:

----snip----

> > > cout will only throw those exceptions you have explicitly enabled by
> > > calling cout.exceptions(exception_mask). So just don't.
> > 
> > I don't. But that's because I don't use *any* C++ libraries.
> > 
> > > https://en.cppreference.com/w/cpp/io/basic_ios/exceptions
> > 
> > Really? An incomplete section?
> > 
> > It shows how to set an exception mask. There's nothing there about
> > *disabling* exceptions. There's nothing there to say that they're
> > disbled without explicit enablement.
> > 
> > Similar with with the gcc man page. Plenty of options for exception
> > types, nothing about disabling them.
>
> <https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fexceptions>
>
> Use "-fno-exceptions", and gcc will compile your C++ code as though the 
> language did not have exception support.

I checked again. The nearest I can see is -mno-fp-exceptions. Different
versions, I suppose.

>                                           It is a commonly used feature 
> - exceptions are good for some kinds of programming, less good for other 
> kinds.

Frankly, I can't see *any* use for it. It's nowhere near as context-
sensitive as making the object report the error to the caller.

But thanks for the info anyway. Indeed, thanx to all who contributed
to this subthread.

[toc] | [prev] | [next] | [standalone]

#72807

On 04/04/2020 14:15, Ned Latham wrote:
> David Brown wrote:
>> Ned Latham wrote:
>>> Bo Persson wrote:
> 
> ----snip----
> 
>>>> cout will only throw those exceptions you have explicitly enabled by
>>>> calling cout.exceptions(exception_mask). So just don't.
>>>
>>> I don't. But that's because I don't use *any* C++ libraries.
>>>
>>>> https://en.cppreference.com/w/cpp/io/basic_ios/exceptions
>>>
>>> Really? An incomplete section?
>>>
>>> It shows how to set an exception mask. There's nothing there about
>>> *disabling* exceptions. There's nothing there to say that they're
>>> disbled without explicit enablement.
>>>
>>> Similar with with the gcc man page. Plenty of options for exception
>>> types, nothing about disabling them.
>>
>> <https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fexceptions>
>>
>> Use "-fno-exceptions", and gcc will compile your C++ code as though the
>> language did not have exception support.
> 
> I checked again. The nearest I can see is -mno-fp-exceptions. Different
> versions, I suppose.

Perhaps along with your pre-standard C++ from the early nineties, you 
are using a compiler of that age.  Either that, or you don't know how 
options in gcc work.  (If that's just lack of knowledge, it is easily 
solved - follow the link I gave you.)

> 
>>                                            It is a commonly used feature
>> - exceptions are good for some kinds of programming, less good for other
>> kinds.
> 
> Frankly, I can't see *any* use for it. It's nowhere near as context-
> sensitive as making the object report the error to the caller.
> 

Do you assume that you know all the uses other people might have for 
features in a language?  You seem to be parading your ignorance and 
self-centred views as though they were something to be proud of.  The 
C++ language, C++ programmers, and the programming world in general has 
moved on in the last 25 years.  You can stay in the past if you want, 
but insulting and condemning everyone who has moved on is completely 
inappropriate.

It is certainly the case that for most decisions and features there will 
be some people who like them and find them useful, some who don't use 
them but see no harm in them, and some who think they are a bad idea or 
find them a problem.  No one is suggesting that you have to adopt all 
the new features of C++.

> But thanks for the info anyway. Indeed, thanx to all who contributed
> to this subthread.
> 

[toc] | [prev] | [next] | [standalone]

#72821

David Brown wrote:
> Ned Latham wrote:
> > David Brown wrote:

----snip----

> > > It is a commonly used feature - exceptions are good for some kinds
> > > of programming, less good for other kinds.
> >
> > Frankly, I can't see *any* use for it. It's nowhere near as context-
> > sensitive as making the object report the error to the caller.
> >
>
> Do you assume that you know all the uses other people might have for
> features in a language?

Straw man. I know what exceptions are. And I repeat: it's nowhere near
as context-sensitive as making the object report the error to the caller.

----snip----

[toc] | [prev] | [next] | [standalone]

#72829

On 05/04/2020 10:10, Ned Latham wrote:
> David Brown wrote:
>> Ned Latham wrote:
>>> David Brown wrote:
> 
> ----snip----
> 
>>>> It is a commonly used feature - exceptions are good for some kinds
>>>> of programming, less good for other kinds.
>>>
>>> Frankly, I can't see *any* use for it. It's nowhere near as context-
>>> sensitive as making the object report the error to the caller.
>>>
>>
>> Do you assume that you know all the uses other people might have for
>> features in a language?
> 
> Straw man. I know what exceptions are. And I repeat: it's nowhere near
> as context-sensitive as making the object report the error to the caller.

I nearly always check error and convert it into an exception: this is the correct thing to do as attempting to manually propagate errors up the call stack is tedious, antiquated and fucktarded.

/Flibble

-- 
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin

“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."

[toc] | [prev] | [next] | [standalone]

#72831

Mr Flibble wrote:
> Ned Latham wrote:
> > David Brown wrote:
> > > Ned Latham wrote:
> > > > David Brown wrote:
> > 
> > ----snip----
> > 
> > > > > It is a commonly used feature - exceptions are good for some kinds
> > > > > of programming, less good for other kinds.
> > > >
> > > > Frankly, I can't see *any* use for it. It's nowhere near as context-
> > > > sensitive as making the object report the error to the caller.
> > >
> > > Do you assume that you know all the uses other people might have for
> > > features in a language?
> > 
> > Straw man. I know what exceptions are. And I repeat: it's nowhere near
> > as context-sensitive as making the object report the error to the caller.
>
> I nearly always check error and convert it into an exception: this is the
> correct thing to do as attempting to manually propagate errors up the call
> stack is tedious,

One level is all it takes.

>                   antiquated

So's breathing. So what?

>                              and fucktarded.

You can always try Flubbing it.

[toc] | [prev] | [next] | [standalone]

#72799

> Use "-fno-exceptions", and gcc will compile your C++ code as though the 
> language did not have exception support.  It is a commonly used feature 
> - ...
It's not a "commonly used feature" since nearly the whole standard
-library throws exceptions.

[toc] | [prev] | [next] | [standalone]

#72809

On 04/04/2020 14:19, Bonita Montero wrote:
>> Use "-fno-exceptions", and gcc will compile your C++ code as though 
>> the language did not have exception support.  It is a commonly used 
>> feature - ...
> It's not a "commonly used feature" since nearly the whole standard
> -library throws exceptions.

It is a commonly used feature, since many C++ programming standards, 
many C++ projects, and many companies do not use exceptions in their C++ 
code.  A prime example is Google, whose coding standard disallows 
exceptions.  Another is the small embedded systems programming world 
(roughly speaking, systems where the processor runs a single program 
rather than an OS supporting multiple programs) where disabling 
exceptions and RTTI is the norm.  You will also find exceptions to be 
disabled in many high-performance coding tasks, such as games.

Exceptions are definitely useful for many purposes, but equally 
definitely not ideal in all systems.  It is not a surprise that various 
"error return" mechanisms such as "expected" and "optional" are on the 
uptake.  The proposals for a more lightweight and deterministic 
exception mechanism may turn out to be a better compromise between 
different error-handling solutions.

[toc] | [prev] | [next] | [standalone]

#72808

On 4/4/20 3:22 AM, Ned Latham wrote:
> Ian Collins wrote:
>> Ned Latham wrote:
>>> Ian Collins wrote:
>>>> Ned Latham wrote:
...
>>> You use cout, you risk an exception.
>>
>> Do you?
> 
> You wanna tell me how you don't?

try { } catch{};

>>> How do they prevent them from occurring?
>>
>> Compile with exceptions disabled.
> 
> How?

Disabling exceptions renders an implementation non-conforming. How to do
it is therefore outside the scope of the C++ standard, and is
implementation-specific. If your preferred implementation doesn't
provide such a method, your complaint is with the implementors, not with
the C++ language.

...
>>>> Namespaces where introduced in the origin 1998 C++ standard, the one
>>>> described in Stroustrup's third edition.
>>>>
>>>>> Now, it seems, its use is compulsory.
>>>>
>>>> Says who?
>>>
>>> I do.
>>
>> Ah, so it isn't "compulsory".  Good to know.
> 
> What part of "it seems" did you fail to understand?

The part where it represents anything other than a misconception on your
part.

> 
>>>>>> Could you identify what you consider to be defective about C++'s
>>>>>> post-increment semantic?
>>>>>
>>>>> It doesn't work with non-native types.
>>>>> Post-decrement too, of course.
>>>>
>>>> How so?
>>>
>>> I just told you. It doesn't work.
>>
>> Yeah right, very helpful.
> 
> Get a clue. Increment has only one action, and I didn't mention
> pre-increment. That leaves only one possibility.

Yes, but most of us have no trouble applying post-increment to
user-defined types that have an appropriate operator overload defined,
and see no reason to want to apply post-increment to a type that doesn't
define such an overload. Therefore, the fact that you want to apply
post-increment to a type where you can't apply post-increment is an
anomaly that calls for an more detailed explanation.

[toc] | [prev] | [next] | [standalone]

#72806

On 4/4/20 1:35 AM, Ned Latham wrote:
> Ian Collins wrote:
>> Ned Latham wrote:
>>> James Kuyper wrote:
...
> You use cout, you risk an exception.

That hasn't changed - since shortly afer exceptions were first added to
the language, if you call a function that can throw an exception, and
don't catch the exception, your function will throw that exception.

> How do they prevent them from occurring?

try{ } catch{}.

>>> Namespace wasn't on the curriculum when I started learning C++.
>>> I don't know when it was introduced, but in his book (vol 3) Stroustrup
>>> seems to imply that it's a new thing. He discusses, for example,
>>> "transitioning" to it.
...
>>> Now, it seems, its use is compulsory.
>>
>> Says who?
> 
> I do.

If the only reason it's compulsory is because you said it, and you don't
like it being compulsory, then I recommend that you stop saying that
it's compulsory. There's no one else whose said anything to make
explicit use of namespaces compulsory.

Strictly speaking, if you don't declare something inside an explicitly
declared namespace, it is implicitly declared in a separate unnamed
namespace, which is a separate namespace for each translation unit. So
declaring something inside a namespace is technically unavoidable.
However, the concept of an unnamed namespace has no practical effect on
your code - being implicit, it never needs to be named. The concept only
exists because it makes it easier to word various rules concerning
namespaces.

And again, that's a feature of the language that has existed since
shortly after namespaces were first added to the language - it is not a
change.

>>>> Could you identify what you consider to be defective about C++'s
>>>> post-increment semantic?
>>>
>>> It doesn't work with non-native types.
>>> Post-decrement too, of course.
>>
>> How so?
> 
> I just told you. It doesn't work.

Unless you declare an applicable operator overload, in which case it
does work. Why would you want it to work on a user-defined type that
doesn't have such an overload? Why, for instance, should the standard
allow you to write myContainer++, and what in the world would you want
it to do if you did allow such a construct?

[toc] | [prev] | [next] | [standalone]

#72820

James Kuyper wrote:
> On 4/4/20 1:35 AM, Ned Latham wrote:
> > Ian Collins wrote:
> > > Ned Latham wrote:

----snip----

> > > > Now, it seems, its use is compulsory.
> > >
> > > Says who?
> > 
> > I do.
>
> If the only reason it's compulsory is because you said it,

I didn't. Try paying attention to what you read.

----snip----

[toc] | [prev] | [next] | [standalone]

#72827

On 4/5/20 5:06 AM, Ned Latham wrote:
> James Kuyper wrote:
>> On 4/4/20 1:35 AM, Ned Latham wrote:
>>> Ian Collins wrote:
>>>> Ned Latham wrote:
...
>>>>> Now, it seems, its use is compulsory.
>>>>
>>>> Says who?

As a response to that comment, "Says who" should be interpreted as a
short form for the question "Who says that it's use is compulsory?".

>>> I do.

Which, in context, should mean "I say that it's use is compulsory.",
which is technically correct, since you did in fact say that in the your
immediately previous question - the line where you say precisely that is
still quoted at the top of this message. It seems, however, from your
response below, that this is not what you actually meant to say.

That's fine, because that's not actually the kind of answer he was
looking for. You were clearly merely describing something that you
didn't approve of. What he should have asked is "Who's making it
compulsory?". He's asking that for a very simple reason - he's not aware
of anyone having done so. Neither am I. If someone who has the authority
to do so is going to make it compulsory for me to use namespaces, then I
want to know who it is, so I can start the process of removing them from
authority. So could you please identify who that is?

>> If the only reason it's compulsory is because you said it,
> 
> I didn't. ...

First you say "I do.", and now you're denying it?

On 4/4/20 12:58 AM, Ned Latham wrote:
> Namespace wasn't on the curriculum when I started learning C++.
> I don't know when it was introduced, but in his book (vol 3) Stroustrup
> seems to imply that it's a new thing. He discusses, for example,
> "transitioning" to it. Now, it seems, its use is compulsory.

And, as far as I know, that text, written by you, is the only text
anywhere that says that use of namespaces is compulsory. If I'm wrong
about that, please identify another piece of text that says so.

[toc] | [prev] | [next] | [standalone]

#72830

James Kuyper wrote:
> Ned Latham wrote:
> > James Kuyper wrote:
> > > Ned Latham wrote:
> > > > Ian Collins wrote:
> > > > > Ned Latham wrote:
> ...
> > > > > > Now, it seems, its use is compulsory.
> > > > >
> > > > > Says who?
>
> As a response to that comment, "Says who" should be interpreted as a
> short form for the question "Who says that it's use is compulsory?".

Wrong.

> > > > I do.
>
> Which, in context, should mean "I say that it's use is compulsory.",

Wrong.

----snip----

> > > If the only reason it's compulsory is because you said it,
> >
> > I didn't. ...
>
> First you say "I do.", and now you're denying it?

Wrong.

> On 4/4/20 12:58 AM, Ned Latham wrote:
> > Namespace wasn't on the curriculum when I started learning C++.
> > I don't know when it was introduced, but in his book (vol 3) Stroustrup
> > seems to imply that it's a new thing. He discusses, for example,
> > "transitioning" to it. Now, it seems, its use is compulsory.
>
> And, as far as I know, that text, written by you, is the only text
> anywhere that says that use of namespaces is compulsory.

And you're wrong again.

>                                                          If I'm wrong
> about that, please identify another piece of text that says so.

That's not the only alternative to your idiot misinterpretation.

Learn to read.

[toc] | [prev] | [next] | [standalone]

#72832

On 4/5/20 12:31 PM, Ned Latham wrote:
> James Kuyper wrote:
>> Ned Latham wrote:
>>> James Kuyper wrote:
>>>> Ned Latham wrote:
>>>>> Ian Collins wrote:
>>>>>> Ned Latham wrote:
>> ...
>>>>>>> Now, it seems, its use is compulsory.
>>>>>>
>>>>>> Says who?
>>
>> As a response to that comment, "Says who" should be interpreted as a
>> short form for the question "Who says that it's use is compulsory?".
> 
> Wrong.

OK - so you've made it clear that you're misunderstanding ordinary
English sentences. However, that's not a particular useful response,
because it lacks an explanation. As a result, I have no idea which
misunderstanding of that sentence is the one you believe to be correct.

This is long overdue - Plonk.

[toc] | [prev] | [next] | [standalone]

#72833

James Kuyper wrote:
> Ned Latham wrote:
> > James Kuyper wrote:
> > > Ned Latham wrote:
> > > > James Kuyper wrote:
> > > > > Ned Latham wrote:
> > > > > > Ian Collins wrote:
> > > > > > > Ned Latham wrote:
> > > ...
> > > > > > > > Now, it seems, its use is compulsory.
> > > > > > >
> > > > > > > Says who?
> > >
> > > As a response to that comment, "Says who" should be interpreted as a
> > > short form for the question "Who says that it's use is compulsory?".
> > 
> > Wrong.
>
> OK - so you've made it clear that you're misunderstanding ordinary
> English sentences.

Wrong.

>                    However, that's not a particular useful response,
> because it lacks an explanation.

It doesn't need one.

>                                  As a result, I have no idea which
> misunderstanding of that sentence is the one you believe to be correct.

That's because you don't understand English.

> This is long overdue - Plonk.

The action of a moral coward.

[toc] | [prev] | [next] | [standalone]

#72797

On 04.04.2020 06:58, Ned Latham wrote:
> James Kuyper wrote:
>> Ned Latham wrote:
>>> Jorgen Grahn wrote:
>>>> Ned Latham wrote:
>>>> ...
>>>>> C++ has become a moving target and a profligate producer of
>>>>> maintenance nightmares. My own projects are okay so far, but
>>>>> I've had to make so many fatuous changes that I'm now actively
>>>>> looking for languages to port them to.
>>>>
>>>> Which changes would that be?  Between, say a decent version two
>>>> decades ago (C++98) and a well-supported one today (C++11)?
>>>
>>> Exception throwing: once an option, now the default.
>>> "namespace":        once an option, now a requirement.
>>
>> Could you identify the specific changes in the text of the standard that
>> you're referring to, and when they happened?
> 
> No. I don't geek around with committee standards. The only C++ standard
> that I know is Stroustrup's: "Programming in C++", vol 3, 1997.

At that time, close up to the first standardization in 1998, the /de 
facto/ standard was the Annotated Reference Manual, the "ARM", by Bjarne 
Stroustrup and Margaret Ellis, IIRC.


> Exception throwing was optional back then

The standard exception hierarchy wasn't finished until close up to 
standardization, I believe about the time of that book, anyway after 1995.

As I recall Microsoft's Visual C++ didn't implement the new hierarchy 
until some years after the standardization, I believe in Visual 
Studio.NET in 2003 or so.


>, which suits me fine, because
> one of my projects is a library, and that is no place for exceptions
> (frankly, I think they encourage sloppy programming, and I eschew them
> at all times, not just in libraries). At some point, which I haven't
> reached yet, it became the default. When I reach that point, I'll be
> dropping back to the previous compiler.
> 
> Namespace wasn't on the curriculum when I started learning C++.
> I don't know when it was introduced, but in his book (vol 3) Stroustrup
> seems to imply that it's a new thing. He discusses, for example,
> "transitioning" to it. Now, it seems, its use is compulsory.
> 
> I will not tolerate that either.

1990's tools and techniques are fine, just fine, just not as convenient 
as modern approach. Stick with what you know. However, you'll have to 
adjust some details because compilers now generally conform to the ISO 
standard and not the ARM, e.g. about lifetime of temporaries.


>> descriptions mean - every interpretation I've been able to come up with
>> is something that, as far as I know, either has never been true, or has
>> always been true - either way, there wasn't a change. However, I'm not
>> yet fully up-to-date on anything more recent than C++98. I'm fairly
>> up-to-date on C++2003, and understand many of the more recently added
>> features well enough to make use of them.
> 
> I'd rather put that learning curve into designing and implementing
> a well-thought-out language.
> 
>>> I suppose I should confess that the bugs in C(++) are also part of my
>>> problem with C++. They are the defective string definition in C, and
>>> the defective post-increment semenatic of C++.
>>
>> Could you identify what you consider to be defective about C++'s
>> post-increment semantic?
> 
> It doesn't work with non-native types.
> Post-decrement too, of course.

You just have to defined custom operators where you want custom 
operators and then, if properly defined, they work fine.

The post- operators take a dummy `int` argument, just to distinguish them.

Here's an example:


#include <iostream>
using namespace std;        // Do this to get roughly pre-standard behavior.

struct Non_native
{
     double amount;

     operator double() const { return amount; }

     void advance()
     {
         amount += 0.01;
     }

     Non_native operator++( int )
     {
         Non_native result = *this;
         advance();
         return result;
     }
};

int main()
{
     Non_native o = {3.14};

     cout << "Originally " << o++ << "." << endl;
     cout << "After: " << o << "." << endl;
}


- Alf

[toc] | [prev] | [next] | [standalone]

#72801

Alf P. Steinbach wrote:
> On 04.04.2020 06:58, Ned Latham wrote:
> > James Kuyper wrote:
> > > Ned Latham wrote:
> > > > Jorgen Grahn wrote:
> > > > > Ned Latham wrote:
> > > > > ...
> > > > > > C++ has become a moving target and a profligate producer of
> > > > > > maintenance nightmares. My own projects are okay so far, but
> > > > > > I've had to make so many fatuous changes that I'm now actively
> > > > > > looking for languages to port them to.
> > > > >
> > > > > Which changes would that be?  Between, say a decent version two
> > > > > decades ago (C++98) and a well-supported one today (C++11)?
> > > >
> > > > Exception throwing: once an option, now the default.
> > > > "namespace":        once an option, now a requirement.
> > >
> > > Could you identify the specific changes in the text of the standard that
> > > you're referring to, and when they happened?
> >
> > No. I don't geek around with committee standards. The only C++ standard
> > that I know is Stroustrup's: "Programming in C++", vol 3, 1997.
>
> At that time, close up to the first standardization in 1998, the /de
> facto/ standard was the Annotated Reference Manual, the "ARM", by Bjarne
> Stroustrup and Margaret Ellis, IIRC.

Sounds familiar, though I don't have it.

> > Exception throwing was optional back then
>
> The standard exception hierarchy wasn't finished until close up to
> standardization, I believe about the time of that book, anyway after
> 1995.
>
> As I recall Microsoft's Visual C++ didn't implement the new hierarchy
> until some years after the standardization, I believe in Visual
> Studio.NET in 2003 or so.

'Sfunny. I've been toying with the notion of developing a language
that gives the programmer complete control of all elements of code
generation, and one of the thoughts was that it might be a good
idea to put a minimal version it out there and get help enhancing it.

C++ shows pretty clearly that it's a bad idea. (Well, if it's done by
committee.)

----snip----

> 1990's tools and techniques are fine, just fine, just not as convenient
> as modern approach. Stick with what you know.

That's one option. Another is a stable language, with context-sensitive
error control.

>                                               However, you'll have to
> adjust some details because compilers now generally conform to the ISO
> standard and not the ARM,

I will not be doing that. Next time I hit a version that wants me to
alter my code, I'll dump it. Either downgrade or switch.

>                           e.g. about lifetime of temporaries.

I always regard those as lasting until their return.

With the declarations
# include <mclib.h>  // The library I referred to earlier.
and
StringC one("I'm "), two("outta here.");

the command
(one + two).Write(stderr);

puts "I'm outta here." on the error stream.
And it (the temporary) really is.

----snip----

> > > Could you identify what you consider to be defective about C++'s
> > > post-increment semantic?
> >
> > It doesn't work with non-native types.
> > Post-decrement too, of course.
>
> You just have to defined custom operators where you want custom
> operators and then, if properly defined, they work fine.

Nope. With non-native types passed to functions they pass the
incremented value to the function.

> The post- operators take a dummy `int` argument, just to distinguish them.

I know. I spent weeks hacking the post- operators in an index class
designed to provide random access to a list class. Trying to hack
correct working into them. Managed it, but the hacks were ugly and
inefficient and prevented the compiler from picking up errors.
So LixtC, the indexor to ListC, has preincrements, but not post.

> Here's an example:
>
>
> #include <iostream>
> using namespace std;        // Do this to get roughly pre-standard behavior.

Not me. Namespace is beyond the pale.

> struct Non_native
> {
>      double amount;
>
>      operator double() const { return amount; }

What's this for? It's not used, below.

>
>      void advance()
>      {
>          amount += 0.01;
>      }
>
>      Non_native operator++( int )

double is non-native?

>      {
>          Non_native result = *this;
>          advance();
>          return result;
>      }
> };
>
> int main()
> {
>      Non_native o = {3.14};
>
>      cout << "Originally " << o++ << "." << endl;
>      cout << "After: " << o << "." << endl;
> }

I'm not even going to try it, Alf, And I bet you haven't done so.
That code requires overload operators = and << for the struct.

[toc] | [prev] | [next] | [standalone]

#72811

On 05/04/2020 02:33, Ned Latham wrote:
> Alf P. Steinbach wrote:
> 
>> Here's an example:
>>
>>
>> #include <iostream>
>> using namespace std;        // Do this to get roughly pre-standard behavior.
> 
> Not me. Namespace is beyond the pale.
> 
>> struct Non_native
>> {
>>       double amount;
>>
>>       operator double() const { return amount; }
> 
> What's this for? It's not used, below.

It is.

>>
>>       void advance()
>>       {
>>           amount += 0.01;
>>       }
>>
>>       Non_native operator++( int )
> 
> double is non-native?
> 
>>       {
>>           Non_native result = *this;
>>           advance();
>>           return result;
>>       }
>> };
>>
>> int main()
>> {
>>       Non_native o = {3.14};
>>
>>       cout << "Originally " << o++ << "." << endl;
>>       cout << "After: " << o << "." << endl;
>> }
> 
> I'm not even going to try it, Alf, And I bet you haven't done so.
> That code requires overload operators = and << for the struct.
> 

No, it doesn't.  The code compiles and behaves exactly as intended and 
your inability to comprehend it clearly demonstrates what I thought all 
along, you are clueless.

-- 
Ian.

[toc] | [prev] | [next] | [standalone]

#72822

Ian Collins wrote:
> On 05/04/2020 02:33, Ned Latham wrote:
> > Alf P. Steinbach wrote:
> >
> > > Here's an example:
> > >
> > >
> > > #include <iostream>
> > > using namespace std;        // Do this to get roughly pre-standard behavior.
> >
> > Not me. Namespace is beyond the pale.
> >
> > > struct Non_native
> > > {
> > >       double amount;
> > >
> > >       operator double() const { return amount; }
> >
> > What's this for? It's not used, below.
>
> It is.

Liar.

> > >
> > >       void advance()
> > >       {
> > >           amount += 0.01;
> > >       }
> > >
> > >       Non_native operator++( int )
> > >       {
> > >           Non_native result = *this;
> > >           advance();
> > >           return result;
> > >       }
> > > };
> > >
> > > int main()
> > > {
> > >       Non_native o = {3.14};
> > >
> > >       cout << "Originally " << o++ << "." << endl;
> > >       cout << "After: " << o << "." << endl;
> > > }
> >
> > I'm not even going to try it, Alf, And I bet you haven't done so.
> > That code requires overload operators = and << for the struct.
>
> No, it doesn't.

Wrong.

>                  The code compiles and behaves exactly as intended

Your intention to produce defective code is noted.

>                                                                    and
> your inability to comprehend it clearly demonstrates what I thought all
> along, you are clueless.

Wrong pronoun, dimwit.

[toc] | [prev] | [next] | [standalone]

#72828

On 4/5/20 5:19 AM, Ned Latham wrote:
> Ian Collins wrote:
>> On 05/04/2020 02:33, Ned Latham wrote:
>>> Alf P. Steinbach wrote:
...
>>>>       operator double() const { return amount; }
>>>
>>> What's this for? It's not used, below.
>>
>> It is.
> 
> Liar.

Give it a try. Modify that definition to monitor calls to that function:

operator double() const {
    cout << endl << "Conversion from Non_native to double performed:"
        << amount << endl;
    return amount.
}

> 
>>>>
>>>>       void advance()
>>>>       {
>>>>           amount += 0.01;
>>>>       }
>>>>
>>>>       Non_native operator++( int )
>>>>       {
>>>>           Non_native result = *this;
>>>>           advance();
>>>>           return result;
>>>>       }
>>>> };
>>>>
>>>> int main()
>>>> {
>>>>       Non_native o = {3.14};
>>>>
>>>>       cout << "Originally " << o++ << "." << endl;
>>>>       cout << "After: " << o << "." << endl;
>>>> }
>>>
>>> I'm not even going to try it, Alf, And I bet you haven't done so.
>>> That code requires overload operators = and << for the struct.
>>
>> No, it doesn't.
> 
> Wrong.
> 
>>                  The code compiles and behaves exactly as intended

Give it a try. Try to compile it, and you'll find it will compile
without error messages, and it shouldn't trigger any warnings, either.
Try to link it, and you'll find that it will link. Try to execute it,
and it will execute and produce output showing that the return value of
operator++ is the value before the increment, while the value stored in
o is the value after the increment. And if you add the monitoring that I
recommended, you'll find that operator double() is called twice. Here's
the results when I do it:

~/Programming/C++/testprog(57) g++ -std=c++98 -pedantic -Wall
-Wpointer-arith -Wcast-align -fno-enforce-eh-specs -ffor-scope
-fno-gnu-keywords -fno-nonansi-builtins -Wctor-dtor-privacy
-Wnon-virtual-dtor -Wold-style-cast -Woverloaded-virtual -Wsign-promo
post-increment.cpp -o post-increment
~/Programming/C++/testprog(58) post-increment
Originally
Conversion from Non_native to double performed:3.14
3.14.
After:
Conversion from Non_native to double performed:3.15
3.15.

I used C++98, since you prefer old versions of C++, and that's the
oldest version gcc supports. It also produces the same results when
compiled using the latest version of C++ it supports.
Note that the other options I used are mainly to ensure that it produces
all of the warnings I consider reasonable - feel free to modify that
list. Let me know if you find an option whose addition or removal gives
you different results from mine.

> Your intention to produce defective code is noted.

That the above code has the behavior shown is guaranteed by the C++
standard (all versions).

[toc] | [prev] | [next] | [standalone]

#72816

On 4/4/20 9:33 AM, Ned Latham wrote:
> Alf P. Steinbach wrote:
>> On 04.04.2020 06:58, Ned Latham wrote:
>>> James Kuyper wrote:
>>>> Ned Latham wrote:
>>>>> Jorgen Grahn wrote:
>>>>>> Ned Latham wrote:
...
>>                           e.g. about lifetime of temporaries.
> 
> I always regard those as lasting until their return.

I have no idea what "their return" is supposed to mean. The general rule
is that temporaries last until the end of the full-expression that
contains them. There's three main exceptions, the most important of
which occurs when a temporary is bound to a reference.

>>>> Could you identify what you consider to be defective about C++'s
>>>> post-increment semantic?
>>>
>>> It doesn't work with non-native types.
>>> Post-decrement too, of course.
>>
>> You just have to defined custom operators where you want custom
>> operators and then, if properly defined, they work fine.
> 
> Nope. With non-native types passed to functions they pass the
> incremented value to the function.

Well, he did say "if properly defined". To reproduce behavior comparable
to that for the built-in types, you need merely declare the operator
overload as returning a value of the same type, and define the operator
overload to create a copy of the current object before incrementing it,
and to return that copy. You won't get the behavior you've described
above if you follow those rules.

>> struct Non_native
>> {
>>      double amount;
>>
>>      operator double() const { return amount; }
> 
> What's this for? It's not used, below.

That implements a conversion from Non-native to double, and it is used
below.

>>
>>      void advance()
>>      {
>>          amount += 0.01;
>>      }
>>
>>      Non_native operator++( int )
> 
> double is non-native?

No, but Non_native contains a double, and is implicitly convertible to a
double. I'm curious - how did you misinterpret the above code so as to
lead to that question?

>>      {
>>          Non_native result = *this;
>>          advance();
>>          return result;
>>      }
>> };
>>
>> int main()
>> {
>>      Non_native o = {3.14};
>>
>>      cout << "Originally " << o++ << "." << endl;

You said that operator double() was not used. It might help you
understand this code to realize that it's equivalent to the following:

    cout << "Originally " << o.operator++(1).operator double()
        << "." << endl;

If you don't understand why those two statements are equivalent, please
explain what part you do understand, and we can fill in the rest.

>>      cout << "After: " << o << "." << endl;

Similarly, that line is equivalent to:

    cout << "After: " << o.operator double() << "." << endl;

>> }
> 
> I'm not even going to try it, Alf, And I bet you haven't done so.
> That code requires overload operators = and << for the struct.

No, the rules of C++ cause operator double() to be called in each of the
relevant cases, and there are operators already defined for << working
on doubles. There's no need to declare or define operator=(); C++ rules
cause it to be implicitly declared and implicitly defined, and the
implicitly defined  operator=() does precise what is needed. That's not
a coincidence - those rule were created specifically to save developers
the trouble of defining operator=() explicitly. You only need to
explicitly declare or define it in circumstance the implicit
declaration/definition doesn't do what you want it to do.

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c++

csiph-web