comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Integer arithmetic when overflow exists - 15 messages, 5 authors
http://groups.google.com/group/comp.lang.c++/t/817dc36a142b4ac5?hl=en
* Shift elements of an array - 8 messages, 6 authors
http://groups.google.com/group/comp.lang.c++/t/c899bed9af911488?hl=en
* An Objective-C to C++ Translator - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/b6eb3a692e851453?hl=en
* test (ignore) - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/1c0575e71e422207?hl=en
==============================================================================
TOPIC: Integer arithmetic when overflow exists
http://groups.google.com/group/comp.lang.c++/t/817dc36a142b4ac5?hl=en
==============================================================================
== 1 of 15 ==
Date: Tues, Oct 8 2013 2:27 pm
From: Ian Collins
alf.p.steinbach@gmail.com wrote:
> On Tuesday, October 8, 2013 10:54:53 PM UTC+2, Scott Lurndal wrote:
>
>> And, of course, one can't ignore the Z-series, for which new software is
>> developed every day (albeit mostly COBOL) and for which packed decimal is
>> a standard machine datatype.
>
> Z-series, are you talking (before World War II) Konrad Zuse's Z1 etc. here?
You're several decades behind the times Alf!
http://en.wikipedia.org/wiki/IBM_System_z
--
Ian Collins
== 2 of 15 ==
Date: Tues, Oct 8 2013 2:29 pm
From: alf.p.steinbach@gmail.com
On Tuesday, October 8, 2013 10:50:06 PM UTC+2, Tobias Müller wrote:
> <alf.p.steinbach@gmail.com> wrote:
>
[snip]
> > You might google <<msdn c++ "void main">>.
>
> I just did and there was not even one example on the first 5 pages. I don't
> have the time for looking through dozens of search result pages.
>
> Please give me some concrete examples. But not for ancient versions.
http://msdn.microsoft.com/en-us/library/windows/desktop/bb773687%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/bb773745%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/bb773757%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/bb773739%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/bb773742%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/k204dhw5.aspx
http://msdn.microsoft.com/en-us/library/aa448695.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa446602%28v=vs.85%29.aspx
I'm stopping there, not for me to do Microsoft's cleaning job for them.
But as you can see, no shortage of "void main" usage in their docs, indicating a certain lack of competence at least on the part of the technical writers.
You're just wrong.
> > Sorry for not reading the rest, but, you know, time.
>
> This is just rude.
No seriously, I don't have time for reading pages of stuff after encountering active misrepresentation.
Cheers & hth.,
- Alf
== 3 of 15 ==
Date: Tues, Oct 8 2013 3:22 pm
From: David Brown
On 08/10/13 20:50, alf.p.steinbach@gmail.com wrote:
> On Tuesday, October 8, 2013 6:55:04 PM UTC+2, Paavo Helde wrote:
>> alf.p.steinbach@gmail.com wrote in
>> news:881daf99-67bf-4256-9f7b-d85779c9ab1f@googlegroups.com:
>>> On Tuesday, October 8, 2013 5:15:50 PM UTC+2, David Brown wrote:
>>>> On 08/10/13 15:22, alf.p.steinbach@gmail.com wrote:
>>
>>>> Most people assume "int" works like a mathematical integer -
>>>> not modular arithmetic.
>>
>>> Hm, don't know about "most people".
>>>
>>> A Python 3.x programmer might think so.
>>>
>>> However, no competent C or C++ programmer assumes that.
>>
>> Right, competent programmers know that overflow in signed
>> arithmetics is UB and do not rely on it in portable code. Even if
>> it appears to work in some particular way now and is not trapped,
>> nobody guarantees the same in the next version of gcc.
>
> It's good that there's agreement about something, now. :-)
If you are agree that competent programmers know that signed overflow is
undefined behaviour, why are you arguing that compilers should define it
in a specific way?
>
> David Brown and I have already expressed, in this thread, about the
> same sentiment about preferably using unsigned for modular
> arithmetic.
>
> Perhaps we have landed on that conclusion from slightly different
> rationales, but my rationale is that when it's not too much work to
> write standard-conforming code, then there is IMO no good reason to
> not do that.
So if your code is standard-conforming, you assume nothing about signed
overflow. Again, why are you complaining that a compiler agrees with you?
>
> However, the gcc default is that you can not rely on the expected
> behavior in other's code (other's code may not add the requisite
> casting to unsigned type, e.g. for use of Windows' GetTickCount API
> function), and the gcc default is that you cannot even rely on
> reasonable behavior for very system-specific code.
The gcc default is for no optimisation, thus no problem. It's default
treatment of optimising signed overflow is to accept that it is
undefined behaviour, and assume that the programmer does not make
mistakes leading to signed overflow. As far as I can tell, we already
agree that competent programmers will be happy here, as they know that
signed overflow is undefined, and they know how to use unsigned integers
when they need modular arithmetic overflow behaviour.
So maybe our disagreement is just about incompetent programmers. You
think incompetent programmers will assume signed integers are modular,
and therefore this should be the default. I think incompetent
programmers will assume that signed integers act like real-world
integers, and therefore undefined behaviour on overflow is fine (since
the compiler can't do any better).
Is that a fair summary of the argument?
>
> In short, it's unreliable. And due to the "optimizations" that it
> adds by default, that may wholesale remove parts of one's code, the
> effect of one's code (that may use others' libraries), with this
> compiler, is also unpredictable. Or perhaps that distinction is too
> subtle, too fine, but anyway, it's somewhere in the area of
> unreliable/unpredictable/arbitrary/impractical.
>
> But as I've also already remarked on, "Better the Devil that one
> knows": with regard to conformance to the core language parts of the
> standard, and support for those parts of the standard, g++ shines
> brightly. :)
>
> Cheers & hth.,
>
> - Alf
>
== 4 of 15 ==
Date: Tues, Oct 8 2013 3:25 pm
From: David Brown
On 08/10/13 18:22, alf.p.steinbach@gmail.com wrote:
> Along with writing "void main", which you will find in examples all over Microsoft's documentation.
>
"void main" is perfectly legal in freestanding (non-hosted) C, and is in
common usage in embedded systems of all sorts.
I can't say anything about MS's toolchains or documentation, as I've
never used them. But I agree it is an incorrect declaration of main()
in a hosted system.
== 5 of 15 ==
Date: Tues, Oct 8 2013 3:41 pm
From: alf.p.steinbach@gmail.com
On Wednesday, October 9, 2013 12:25:05 AM UTC+2, David Brown wrote:
> On 08/10/13 18:22, alf.p.steinbach@gmail.com wrote:
>
> > Along with writing "void main", which you will find in examples all over Microsoft's documentation.
>
> "void main" is perfectly legal in freestanding (non-hosted) C, and is in
> common usage in embedded systems of all sorts.
Well we're talking C++ here.
In C++ it's invalid, even in freestanding implementation.
C++11 §3.6.1/2 "[main] shall have a return type of type int, but otherwise its type is implementation-defined"
I don't know about C.
Cheers & hth.,
- Alf
== 6 of 15 ==
Date: Tues, Oct 8 2013 3:49 pm
From: alf.p.steinbach@gmail.com
On Wednesday, October 9, 2013 12:22:38 AM UTC+2, David Brown wrote:
>
> Is that a fair summary of the argument?
>
Nope.
A compiler that yields unpredictable (lack of) effects for ordinary code, is simply ... unpredictable.
Not a good thing, regardless of the users.
And let's face: not every C++ programmer is a language lawyer.
A compiler, such as g++, should not support only the best and brightest, but also ordinary programmers.
And the compiler should not only support the programmers who think those who use platform-specific functionality are incompetents.
The compiler should also support those, like myself and (I know from earlier clc++ discussions) Pete Becker, who penned the latest standard, who are comfortable with using platform-specific functionality where appropriate, regardless of formal UB. Not that he'd necessary completely share my point of view (I think most probably not!), but as authority arguments go, I think it's nice that by chance he has expressed, in clc++, views diametrically opposed to yours, in this matter.
:)
Cheers & hth.,
- Alf
Cheers & hth.,
- Alf
== 7 of 15 ==
Date: Tues, Oct 8 2013 4:55 pm
From: alf.p.steinbach@gmail.com
On Tuesday, October 8, 2013 11:27:02 PM UTC+2, Ian Collins wrote:
> alf.p.steinbach@gmail.com wrote:
>
> > Z-series, are you talking (before World War II) Konrad Zuse's Z1 etc. here?
>
> You're several decades behind the times Alf!
He he. :)
> http://en.wikipedia.org/wiki/IBM_System_z
Thanks.
I see no evidence or indication that it uses anything but two's complement for integers, but knowing IBM, it might just do that plus having a Hollerith card based system console and using EBCDIC through and through. Of course with a special Java adapter somewhere, so that Java can run there. Ow hell. :(
Cheers, & thanks!,
- Alf
== 8 of 15 ==
Date: Tues, Oct 8 2013 9:53 pm
From: Paavo Helde
Rupert Swarbrick <rswarbrick@gmail.com> wrote in news:l31n8t$34i$2
@speranza.aioe.org:
>
> Finally, back to my original point. Is signed addition invertible? Well,
> that depends on what the standard says about behaviour on overflow. For
> example, consider what happens if signed saturating addition is allowed.
C++ standard is very clear here, overflow in signed arithmetics is
undefined behaviour. So certainly it is not guaranteed to be invertible.
Cheers
Paavo
== 9 of 15 ==
Date: Wed, Oct 9 2013 4:29 am
From: David Brown
On 09/10/13 00:49, alf.p.steinbach@gmail.com wrote:
> On Wednesday, October 9, 2013 12:22:38 AM UTC+2, David Brown wrote:
>>
>> Is that a fair summary of the argument?
>>
>
> Nope.
>
> A compiler that yields unpredictable (lack of) effects for ordinary
> code, is simply ... unpredictable.
>
> Not a good thing, regardless of the users.
>
> And let's face: not every C++ programmer is a language lawyer.
>
A C or C++ programmer who writes code without a defined meaning, but
expects the compiler to read his mind for what he wants, has a lot to
learn. I don't want my tools to be limited to deal with that level of
ignorance. (I mean no disrespect to such programmers - you've got to
start somewhere. But if you don't understand the need to write correct
code according to the language, you have a long way yet to go.)
> A compiler, such as g++, should not support only the best and
> brightest, but also ordinary programmers.
We are back to (almost) my summary. All I need to do is change the word
"incompetent" to "ordinary" :
You think ordinary programmers will assume signed integers are modular,
and therefore this should be the default. I think ordinary programmers
will assume that signed integers act like real-world integers, and
therefore undefined behaviour on overflow is fine (since the compiler
can't do any better).
If you (or any other programmer - ordinary, incompetent, wizard, or
whatever) write code that has the possibility of integer overflow then
there is no way the compiler can generate code that is "correct",
because there is no meaning of "correct" here.
To one programmer, "correct" might mean "as modular arithmetic,
overflowing from +BIG to -BIG". To another it might mean "as modular
arithmetic, but obviously not changing the sign - +BIG overflows to 0".
Another will want saturation - "+BIG overflows to +BIG". Another will
want a trap, or exception. Many will want magic - "+BIG overflows to
+EVEN_BIGGER". And some will want "whatever makes the smallest and
fastest code, because the answer doesn't matter".
You cannot simply pick one of these and say "this is what ordinary
programmers expect" - just because it happens to coincide with what is
usually the easiest machine code. Consistency is good, but consistently
wrong is not significantly better than inconsistently wrong.
The only conceivable "correct" implementations of signed overflow is for
the compiler to give a warning about it (which gcc will do, when it can
spot such problems at compile time, if suitable warnings are enabled) or
for the compiler to generate run-time range checking code. Such code is
expensive, but sometimes useful and supported by some languages (such as
Ada).
>
> And the compiler should not only support the programmers who think
> those who use platform-specific functionality are incompetents.
I don't think those who use platform-specific functionality are
incompetent - as an embedded programmer, I use platform-specific
functionality all the time (and I view myself as "competent" :-) But I
do think that people who rely unnecessarily on /clearly/ undefined
behaviour /are/ incompetent - or at least ignorant. It is particularly
true with gcc, since if you actually want to rely on the effects of this
particular undefined behaviour you can use compiler switches to make it
defined - and therefore usable.
>
> The compiler should also support those, like myself and (I know from
> earlier clc++ discussions) Pete Becker, who penned the latest
> standard, who are comfortable with using platform-specific
> functionality where appropriate, regardless of formal UB. Not that
> he'd necessary completely share my point of view (I think most
> probably not!), but as authority arguments go, I think it's nice that
> by chance he has expressed, in clc++, views diametrically opposed to
> yours, in this matter.
>
No, this sounds like he expresses views exactly like mine regarding
platform-specific behaviour. I have no problem with using
platform-specific behaviour where it helps the code - usually code will
only ever run on one or a few platform types. If you want modular
effects on signed overflow, then stick to a platform that supports it -
such as gcc with the "-fwrapv" flag. And avoid platforms that don't
support it - that is every single C compiler in existence that does not
explicitly state that it has this behaviour. The worst thing you can
possibly do is have a couple of tests on a compiler and /assume/ it
defines the undefined behaviour in a way you /assume/ makes sense.
> :)
>
>
> Cheers & hth.,
>
> - Alf
>
>
>
>
>
>
> Cheers & hth.,
>
> - Alf
>
== 10 of 15 ==
Date: Wed, Oct 9 2013 4:50 am
From: alf.p.steinbach@gmail.com
On Wednesday, October 9, 2013 1:29:56 PM UTC+2, David Brown wrote:
> On 09/10/13 00:49, alf.p.steinbach@gmail.com wrote:
> > A compiler that yields unpredictable (lack of) effects for ordinary
> > code, is simply ... unpredictable.
> >
> > Not a good thing, regardless of the users.
> >
> > And let's face: not every C++ programmer is a language lawyer.
>
> A C or C++ programmer who writes code without a defined meaning, but
> expects the compiler to read his mind for what he wants, has a lot to
> learn.
That's totally irrelevant, a slur.
Do quote the alleged "code without a defined meaning".
[snipped pages of further misrepresentation and innuendo]
- Alf (annoyed)
== 11 of 15 ==
Date: Wed, Oct 9 2013 6:39 am
From: David Brown
On 09/10/13 13:50, alf.p.steinbach@gmail.com wrote:
> On Wednesday, October 9, 2013 1:29:56 PM UTC+2, David Brown wrote:
>> On 09/10/13 00:49, alf.p.steinbach@gmail.com wrote:
>>> A compiler that yields unpredictable (lack of) effects for ordinary
>>> code, is simply ... unpredictable.
>>>
>>> Not a good thing, regardless of the users.
>>>
>>> And let's face: not every C++ programmer is a language lawyer.
>>
>> A C or C++ programmer who writes code without a defined meaning, but
>> expects the compiler to read his mind for what he wants, has a lot to
>> learn.
>
> That's totally irrelevant, a slur.
>
> Do quote the alleged "code without a defined meaning".
>
>
> [snipped pages of further misrepresentation and innuendo]
>
> - Alf (annoyed)
>
My post was not meant to be a slur or to cause annoyance of any sort. I
am sorry you took it that way.
But like it or not, a lot of C and C++ behaviour has clear definitions,
and there is a lot that is legal to write in C or C++ but is documented
as "undefined behaviour". That is the way the language works - and no
amount of discussions of "what programmers expect" will change that.
Clearly people who are relatively new to the language will not be aware
of such situations - it is a learning process. Thus, people who write
code that relies on undefined behaviour have a lot to learn. That is
not a "slur", it is simple fact.
If you /know/ that such code has undefined behaviour (and are not able
to pin it down to "defined" by a choice of compiler and/or options, thus
becoming entirely usable "implementation defined behaviour"), and
/still/ write code that relies on it, then you are expecting the
compiler to read your mind and agree with you on how you think this
behaviour /should/ be defined. This is always wrong.
Again, I don't see how you interpret that as a slur.
mvh.,
David (confused about your annoyance)
== 12 of 15 ==
Date: Wed, Oct 9 2013 6:50 am
From: David Brown
On 08/10/13 21:49, alf.p.steinbach@gmail.com wrote:
> On Tuesday, October 8, 2013 9:27:29 PM UTC+2, Tobias Müller wrote:
>> <alf.p.steinbach@gmail.com> wrote:
>>
>>> [...] On Tuesday, October 8, 2013 5:15:50 PM UTC+2, David Brown
>>> wrote:
>>>> Most people assume "int" works like a mathematical integer -
>>>> not modular arithmetic.
>>>
>>> Hm, don't know about "most people".
>>>
>>> A Python 3.x programmer might think so.
>>>
>>> However, no competent C or C++ programmer assumes that.
>>>
>>> Making that assumption might even be used as a defining criterion
>>> for incompetence and/or newbieness.
>>
>> They way it is defined, it seems to be obvious that this was the
>> original intent. Why else should overflow be UB?
>
> C++ admits three possible representations of signed integers, namely
> magnitude-and-sign, one's complement, and two's complement. Only the
> last gives modulo arithmetic. At one time computers/systems using the
> first two, existed.
>
> This is the main reason, and it pertains to now archaic systems.
>
If the early creators of C (since this pre-dates and is inherited by
C++) and its standards thought that defining signed overflow as modular
behaviour were important, they would have defined it that way. At the
very least, they would have made it "implementation defined" rather than
"undefined".
But they specifically made it "undefined". This is not just for the
convenience of implementation on now-outdated computers. It is because
they did not think modular arithmetic was a sensible or obvious model
for signed computation - or at least, it is not the /only/ sensible
choice. Rather than picking one model, and forcing implementers and
users to follow it, they said that /no/ model of signed overflow is
considered correct in C.
Other languages have made different design decisions - in Java, signed
overflow is modular. In Python, attempting signed overflow results in
the type getting bigger to avoid overflow. You cannot say that one of
these is "correct".
The fact that the undefined behaviour of signed overflow in C can give
extra optimisation opportunities is a bonus - I doubt if the
grandfathers of C thought that far ahead.
== 13 of 15 ==
Date: Wed, Oct 9 2013 6:53 am
From: David Brown
On 09/10/13 00:41, alf.p.steinbach@gmail.com wrote:
> On Wednesday, October 9, 2013 12:25:05 AM UTC+2, David Brown wrote:
>> On 08/10/13 18:22, alf.p.steinbach@gmail.com wrote:
>>
>>> Along with writing "void main", which you will find in examples
>>> all over Microsoft's documentation.
>>
>> "void main" is perfectly legal in freestanding (non-hosted) C, and
>> is in common usage in embedded systems of all sorts.
>
> Well we're talking C++ here.
>
> In C++ it's invalid, even in freestanding implementation.
>
> C++11 §3.6.1/2 "[main] shall have a return type of type int, but
> otherwise its type is implementation-defined"
>
> I don't know about C.
>
I've only looked at the details for C - I didn't know it was invalid in
freestanding C++ programs. Of course, "void main(void)" is still likely
to be used in embedded C++ code, but it's nice to know that it should
not be used.
== 14 of 15 ==
Date: Wed, Oct 9 2013 6:56 am
From: alf.p.steinbach@gmail.com
On Wednesday, October 9, 2013 3:39:36 PM UTC+2, David Brown wrote:
> On 09/10/13 13:50, alf.p.steinbach@gmail.com wrote:
>
> > On Wednesday, October 9, 2013 1:29:56 PM UTC+2, David Brown wrote:
>
> >> On 09/10/13 00:49, alf.p.steinbach@gmail.com wrote:
>
> >>> A compiler that yields unpredictable (lack of) effects for ordinary
> >>> code, is simply ... unpredictable.
>
> >>> Not a good thing, regardless of the users.
> >>>
> >>> And let's face: not every C++ programmer is a language lawyer.
> >>
> >> A C or C++ programmer who writes code without a defined meaning, but
> >> expects the compiler to read his mind for what he wants, has a lot to
> >> learn.
> >
> > That's totally irrelevant, a slur.
> > Do quote the alleged "code without a defined meaning".
> >
> > [snipped pages of further misrepresentation and innuendo]
>
> My post was not meant to be a slur or to cause annoyance of any sort. I
> am sorry you took it that way.
No quote of the alleged "code without a defined meaning".
Since there was no such.
I.e. your claim of being sorry can only refer to being caught.
> But like it or not, a lot of C and C++ behaviour has clear definitions,
> and there is a lot that is legal to write in C or C++ but is documented
> as "undefined behaviour". That is the way the language works - and no
> amount of discussions of "what programmers expect" will change that.
This pretends to be arguing against something I have written.
It is at best a misrepresentation.
- Alf
== 15 of 15 ==
Date: Wed, Oct 9 2013 7:16 am
From: David Brown
On 09/10/13 15:56, alf.p.steinbach@gmail.com wrote:
> On Wednesday, October 9, 2013 3:39:36 PM UTC+2, David Brown wrote:
>> On 09/10/13 13:50, alf.p.steinbach@gmail.com wrote:
>>
>>> On Wednesday, October 9, 2013 1:29:56 PM UTC+2, David Brown wrote:
>>
>>>> On 09/10/13 00:49, alf.p.steinbach@gmail.com wrote:
>>
>>>>> A compiler that yields unpredictable (lack of) effects for ordinary
>>>>> code, is simply ... unpredictable.
>>
>>>>> Not a good thing, regardless of the users.
>>>>>
>>>>> And let's face: not every C++ programmer is a language lawyer.
>>>>
>>>> A C or C++ programmer who writes code without a defined meaning, but
>>>> expects the compiler to read his mind for what he wants, has a lot to
>>>> learn.
>>>
>>> That's totally irrelevant, a slur.
>>> Do quote the alleged "code without a defined meaning".
>>>
>>> [snipped pages of further misrepresentation and innuendo]
>>
>> My post was not meant to be a slur or to cause annoyance of any sort. I
>> am sorry you took it that way.
>
> No quote of the alleged "code without a defined meaning".
>
> Since there was no such.
>
> I.e. your claim of being sorry can only refer to being caught.
I am still lost here.
I said that a programmer who writes code without a defined meaning has a
lot to learn. At no point did I say /you/ wrote such code, or that
/you/ "have a lot to learn". I certainly can't quote code that has not
been posted, but you certainly cannot demand a quotation to defend
something I did not say.
Again, I am sorry you have misunderstood what I wrote, and taken offence
at inferred slurs. But I cannot see anything I wrote that directly or
indirectly implied a slur.
The only thing I can think of here is that you /have/ written code that
depends on modular behaviour of signed overflow, without taking suitable
precautions (such as using "-fwrapv" with gcc, or checking the
documentation of other compilers you expect to use). If that's the
case, then yes - you have written code without a defined meaning, and
that is therefore bad code. I don't mean that to be offensive, but as
constructive criticism to help you improve your programming. But I
can't quote you on anything here, as this is just a guess - only /you/
can confirm or deny that.
>
>
>> But like it or not, a lot of C and C++ behaviour has clear definitions,
>> and there is a lot that is legal to write in C or C++ but is documented
>> as "undefined behaviour". That is the way the language works - and no
>> amount of discussions of "what programmers expect" will change that.
>
> This pretends to be arguing against something I have written.
>
> It is at best a misrepresentation.
>
It is either something you agree with, in which case write "Yes", or it
is something you /disagree/ with - in which case try to explain why.
==============================================================================
TOPIC: Shift elements of an array
http://groups.google.com/group/comp.lang.c++/t/c899bed9af911488?hl=en
==============================================================================
== 1 of 8 ==
Date: Tues, Oct 8 2013 2:56 pm
From: Vlad from Moscow
среда, 9 октября 2013 г., 0:49:39 UTC+4 пользователь Scott Lurndal написал:
> There are coding guidelines at all development shops. Some codify the
>
> source location for declarations such that they are declared at the
>
> beginning of any basic block (e.g. following a '{') instead of interspersing
>
> declarations willy-nilly throughout a function. While C++ allows
>
> willy-nilly declarations, it in no way requires them, and many consider
>
> them to be "confusing", particularly in larger function bodies. When declared
>
> at the start of a block, the maintenance programmer will always know exactly
>
> where to look in a function for the declaration, and many editing tools have
>
> short-cuts to move the cursor to the start of a block ('[[' in vi).
>
>
>
> So there is no law either way; it is purely a matter of preference and YPMV.
The the maintenance programmer should look the code where the variables are used. And if he will see numerous variable declarations and he can say nothing what they mean where they used and so on it will be only confused.
I advice you to rewrite your coding guidelines. They are simply a nonsense written by people who understand nothing in programming. Moreover if a function a big enough that it can fit itself one screen you forgot what variables were declared and how they were declared. You will need to scroll screns forward and back that to see the variable declarations.
So never repeat such ninsenses any more that you wrote for code guidelines.
== 2 of 8 ==
Date: Tues, Oct 8 2013 5:35 pm
From: alf.p.steinbach@gmail.com
On Tuesday, October 8, 2013 10:49:39 PM UTC+2, Scott Lurndal wrote:
>
> There are coding guidelines at all development shops. Some codify the
> source location for declarations such that they are declared at the
> beginning of any basic block (e.g. following a '{') instead of interspersing
> declarations willy-nilly throughout a function. While C++ allows
> willy-nilly declarations, it in no way requires them,
Usually, in good C++ code declarations are neither collected in one place, nor placed willy-nilly, which both are context-independent strategies that disregard the requirements of the code hand.
Rather, in good code the declarations support the code's requirements, and the scope of any variable is reduced to its practical minimum in order to reduce the number of possible interactions and data flows, and also some times in order to get constructor and/or destructor calls properly placed.
The main rationale for using "const" is roughly the same, to reduce complexity by reducing possible interactions that otherwise would have have to be considered, so in code with declarations placed independent of the code requirements I expect to not see much "const" usage either, and v.v.
> and many consider
> them to be "confusing", particularly in larger function bodies.
A solution is to not have larger function bodies, for whatever measure of "larger" that is problematic.
A 1200-line function can be OK -- I've maintained one such, happily not mine!, it was a systematic list of cases.
An 8-line function can be complete spaghetti.
However, chances are that the larger the function, the less its programmer or maintainers knew about abstraction, so it will much more likely be spaghetti. Which, interacting with the size, creates a maintenance hell. Which in turn causes code to be just copied around, replicating whatever bugs there are and creating more of the original problem, and so on, in a vicious circle.
> When declared
> at the start of a block, the maintenance programmer will always know exactly
> where to look in a function for the declaration,
Presumably you're not talking about introducing a new block every place a new variable is needed.
If you do, however, then I roughly agree, because that /restricts the scope/ of each variable. It can however be overdone. Easily.
But for the case of collecting declarations at the start of a function or at the start of some main block, I think that finding declarations is what the right-click "go to declaration" is for. ;-)
An up-front group of declarations placement thus fails to have an advantage in C++, but it does have a severe disadvantage.
Namely, the grouping of declarations at the start of a main block means that those variables can be changed everywhere in the block, thus wasting each maintenance programmer's time by the need for analyzing the data interactions, the way statements in that block can influence each other via the variables.
> and many editing tools have
> short-cuts to move the cursor to the start of a block ('[[' in vi).
And the good ones even let you go directly to a declaration. ;-)
> So there is no law either way; it is purely a matter of preference and YPMV.
Not quite.
In C++ it's some times important where constructors and/or destructors are executed. This can be due to functional requirements, or due to efficiency considerations, or maybe reasons I fail to recall right now (it's late). For these cases it's crucial to restrict the scope of a variable appropriately.
For example, if a constructor can throw, then you might need that declaration inside a try-block if you want to catch the possible exception, or outside the try block if you want to decidedly not catch that possible exception. Even though this is a rare situation -- with C++ RAII try blocks are generally rare -- it is important for correctness. Similarly for efficiency.
Cheers & hth.,
- Alf
== 3 of 8 ==
Date: Wed, Oct 9 2013 3:15 am
From: Rosario1903
On Tue, 8 Oct 2013 17:35:20 -0700 (PDT), alf wrote:
>On Tuesday, October 8, 2013 10:49:39 PM UTC+2, Scott Lurndal wrote:
>> There are coding guidelines at all development shops. Some codify the
>> source location for declarations such that they are declared at the
>> beginning of any basic block (e.g. following a '{') instead of interspersing
>> declarations willy-nilly throughout a function. While C++ allows
>> willy-nilly declarations, it in no way requires them,
>
>Usually, in good C++ code declarations
>are neither collected in one place, nor placed willy-nilly,
>which both are context-independent strategies that disregard the
>requirements of the code hand.
>Rather, in good code
good for who?
>the declarations support the code's
>requirements, and the scope of any variable is reduced
>to its practical minimum in order to reduce the number
>of possible interactions and data flows,
the error you describe above
[use one varible for function in 2 or more different places of routine
nothing have in common and bad interact of data of that variable]
is in what i know rare [i not remember happen to me]
and in these rare case it is easy to find soon
at first run
>and also some times in order to get
>constructor and/or destructor calls properly placed.
possible i make error, possible
placed a obj in the start of one routine and use in a loop
it is less memory stressed than insert in the hidden {} of loop
example
f()
{obj k;
for(;;)
{obj w;
operation w and k
}
}
i say if i understand right the k is create one time at start routine
and free at end routine
instead pheraps w is create free
each for() loop passage...
so for what regard machine it is better put it in the beginning of the
routine
>The main rationale for using "const" is roughly the same,
>to reduce complexity by reducing possible
>interactions that otherwise would have
>have to be considered, so in code
>with declarations placed
>independent of the code requirements
>I expect to not see much "const" usage either, and v.v.
i not agree, i consider all memory accessible read-write
and if there are mem place where i have to write only one time
i write it... but i never have problem about this
for example the string
"%s\n"
in the format of
printf("%s\n", a)
is conceptually a const string
for the compiler a const string
for the machine a read write string
but even if i possibly can write on that
never happen it
so i think all your tell of how usefull is of const keyword
is void
in pratical case
>> and many consider
>> them to be "confusing", particularly in larger function bodies.
>
>A solution is to not have larger function bodies,
>for whatever measure of "larger" that is problematic.
>
>A 1200-line function can be OK --
>I've maintained one such, happily not mine!,
>it was a systematic list of cases.
>
>An 8-line function can be complete spaghetti.
== 4 of 8 ==
Date: Wed, Oct 9 2013 3:44 am
From: Rosario1903
On Wed, 09 Oct 2013 12:15:32 +0200, Rosario1903
<Rosario@invalid.invalid> wrote:
>On Tue, 8 Oct 2013 17:35:20 -0700 (PDT), alf wrote:
>>On Tuesday, October 8, 2013 10:49:39 PM UTC+2, Scott Lurndal wrote:
>>> There are coding guidelines at all development shops.
>Some codify the
>i not agree, i consider all memory accessible read-write
>and if there are mem place where i have to write only one time
>i write it... but i never have problem about this
>
>for example the string
>
>"%s\n"
>
>in the format of
>printf("%s\n", a)
>
>is conceptually a const string
>
>for the compiler a const string
>
>for the machine a read write string
>
>but even if i possibly can write on that
>never happen it
>
>so i think all your tell of how usefull is of const keyword
>is void
>in pratical case
>
yes happen some time(3-4-5 times in a life) when the program print
strange chars to the screen and the program seg fault...
if that string is const for machine too, it would only seg fault some
micro second first...
== 5 of 8 ==
Date: Wed, Oct 9 2013 3:53 am
From: alf.p.steinbach@gmail.com
On Wednesday, October 9, 2013 12:15:32 PM UTC+2, Rosario1903 wrote:
>
> good for who?
"whom"
I.e., "good for whom?".
You can also ask, "who is it good for?".
For more info, see <url: http://www.elearnenglishlanguage.com/difficulties/whowhom.html>.
That said, goodness of code is sort of like entropy, in that the more accurately you try to pin it down, the more fuzzy and ill-defined it gets, BUT ordinarily the difference between much of it and none of it is so exceedingly great that the fine details don't matter.
I.e., to a first approximation, good code is good for everybody. ;-)
[snip]
>
> >The main rationale for using "const" is roughly the same,
> >to reduce complexity by reducing possible
> >interactions that otherwise would have
> >have to be considered, so in code
> >with declarations placed
> >independent of the code requirements
> >I expect to not see much "const" usage either, and v.v.
>
> i not agree, i consider all memory accessible read-write
> and if there are mem place where i have to write only one time
> i write it... but i never have problem about this
>
> for example the string
>
> "%s\n"
>
> in the format of
>
> printf("%s\n", a)
>
> is conceptually a const string
> for the compiler a const string
> for the machine a read write string
> but even if i possibly can write on that
> never happen it
>
> so i think all your tell of how usefull is of const keyword
> is void
> in pratical case
A practical motivation for using "const" is just that the tools support and enforce it.
For example,
[code]
#include <iostream>
using namespace std;
int main()
{
char* p = "Blah blah blah, const is so overrated.";
p[0] = 'b';
cout << p << endl;
}
[/code]
Compiling and running with Visual C++ 11.0 (Visual C++ 2012):
[example]
[D:\dev\test]
> set cl
CL=/EHsc /GR /FI"iso646.h" /we4627 /we4927 /W4 /D"_CRT_SECURE_NO_WARNINGS" /nologo
[D:\dev\test]
> cl foo.cpp
foo.cpp
[D:\dev\test]
> foo
-- A crash dialog pops up, http://imgur.com/bpZDHIe
[D:\dev\test]
> echo %errorlevel%
-1073741819
[D:\dev\test]
>
[/code]
The process exit code reported by the ERRORLEVEL pseudo-variable happens to be Windows error code 5 translated to an "NT status code" (what you have in Windows structured exceptions), 0x0xC0000005, where code 5 is "Access is denied" with symbolic constant ERROR_ACCESS_DENIED in <winerror.h>.
So the effect was as-if it that literal string were read only, which it probably was. ;-)
With "const" you would have got a compilation error instead.
For a larger program a compilation error (via "const") would save you a lot of systematic testing of runtime behavior, and associated bug hunting.
Cheers & hth.,
- Alf
== 6 of 8 ==
Date: Wed, Oct 9 2013 3:58 am
From: Juha Nieminen
Vlad from Moscow <vlad.moscow@mail.ru> wrote:
> Before something saying about C++ you at first need to learn C++ and what are arrays in C++. One more arrays are not classes in C++. They have fixed sized at compile time that must be specified by constant expressions.
The next C++ standard will include support for variable-length arrays.
In other words, you will be able to say things like:
void foo(unsigned size)
{
int array[size];
...
}
What will you call them then?
I also find it amusing how you define std::array as "not an array" even
though it's right there in the name, and it fulfills *all* of your
definitions of "C++ array" (fixed size, size must be known at
compile time.)
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
== 7 of 8 ==
Date: Wed, Oct 9 2013 4:38 am
From: Martin Shobe
On 10/8/2013 1:46 PM, Vlad from Moscow wrote:
> вторник, 8 октября 2013 г., 22:06:18 UTC+4 пользователь Martin Shobe написал:
>> On 10/8/2013 11:45 AM, Vlad from Moscow wrote:
[snip]
>>> Secondly operator + again allocates memory to accomodate elements of this temporary object with elements of the original string. And thirdly the memory occupied by the original string has to be substituted for the new one memory.
>> Those had been optimized away.
> it is not guaranteed by the Standard.
And yet zero allocations is not the "at least two" that you claimed.
Martin Shobe
== 8 of 8 ==
Date: Wed, Oct 9 2013 8:09 am
From: SG
On Wednesday, October 9, 2013 12:58:53 PM UTC+2, Juha Nieminen wrote:
>
> The next C++ standard will include support for variable-length arrays.
> In other words, you will be able to say things like:
>
> void foo(unsigned size)
> {
> int array[size];
> ...
> }
IIRC, this feature (along with dyn_array and optional<>) was recently
removed from the standard draft. See
http://isocpp.org/blog/2013/10/trip-report-fall-iso-c-meeting
As for the array discussion: I don't think it's worth anybody's time.
==============================================================================
TOPIC: An Objective-C to C++ Translator
http://groups.google.com/group/comp.lang.c++/t/b6eb3a692e851453?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Oct 9 2013 4:08 am
From: Juha Nieminen
lipingyang2010@gmail.com wrote:
> On Thursday, July 28, 1988 11:19:01 AM UTC-7, Jim Adcock wrote:
>> I have an Objective-C to C++ "translation aid" that I'm willing to make
>> available on an "unsupported public domain" basis to strongly motivated
>> users.
Given that C++ has no support for introspection nor reflection, how
exactly can it achieve that?
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
==============================================================================
TOPIC: test (ignore)
http://groups.google.com/group/comp.lang.c++/t/1c0575e71e422207?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Oct 9 2013 9:13 am
From: "Alf P. Steinbach"
just testing because a message failed to show up after an hour
== 2 of 2 ==
Date: Wed, Oct 9 2013 9:26 am
From: Leigh Johnston
On 09/10/2013 17:13, Alf P. Steinbach wrote:
> just testing because a message failed to show up after an hour
Use alt.test mate.
==============================================================================
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
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment