Saturday, December 26, 2015

Digest for comp.lang.c++@googlegroups.com - 20 updates in 9 topics

bleachbot <bleachbot@httrack.com>: Dec 26 07:55PM +0100

bleachbot <bleachbot@httrack.com>: Dec 26 10:51PM +0100

Ramine <ramine@1.1>: Dec 26 04:51PM -0800

Hello...
 
 
Please read the following:
 
http://c2.com/cgi/wiki?StronglyTyped
 
You will notice that they are people who call C and C++ strongly typed
programming languages and they are people who call C weakly typed
programming languages..
 
So how can we be sure if C and C++ are strongly typed or weakly typed ?
 
 
Here is my answer:
 
First we have to define the characteristics and advantages of strongly
typed programming languages, that they discipline us to avoid
programming bugs and errors of logic...that's i think the most important
characteristic of a strongly typed programming language... so
if you look at C++ it has inherited the C deficiencies that allow
C++ and C to make an implicit conversion from an signed long to
a unsigned long and that allow C and C++ to assign two typedefs of
the same type etc.. this deficiencies are considered in my opinion
like a single point of failure in the system, that means this
deficiencies can make your system behave like a weakly typed system
and it will make it inherit the characteristic that are difficiencies of
the weakly typed programming languages.. so in my opinion since it is
like a single point of failure so that makes C and C++ weakly
typed programming languages that are not suitable for realtime
safety critical systems.
 
 
 
Thank you,
Amine Moulay Ramdane.
woodbrian77@gmail.com: Dec 26 01:05PM -0800

There's no shortage of intelligent, but lost C++
programmers. "There is a way which seems right to
a man, but its end is the way of death." Proverbs 14:12
 
Some wax on about sausages even though there's
evidence that bacon, ham and sausages are similar
to cigarettes -- not good for you. C. S. Lewis
struggled to quit smoking and said it was like a
full time job. He already had a full time job
of teaching and research so he found it hard to
deal with the stress of quitting smoking. He
died in his sixties and I blame it largely on
cigarettes. It looks to me like the attitude
toward sausages here is going to lead to more
of this sort of thing.
My prayer for you is that you make it to your
100th birthday. Your cooperation with G-d
in terms of taking care of yourself will help
you get there.
 
When I was young they told us to brush our teeth
3 times a day. Now they've changed it to two
times. If you are lazy like me, the bottom line
is the most important time to brush is before you
go to bed. I used to not floss much, but have
started flossing fairly regularly. I have some
of those plastic floss things and I reuse one of
them for weeks. I wash it after each time I've
used it. That's my way of saving money.
 
 
Brian
Ebenezer Enterprises - Christmas blessings.
http://webEbenezer.net
Ramine <ramine@1.1>: Dec 26 01:56PM -0800

Hello....
 
 
Here is why i don't accept C++ and C...
 
Ada does discipline the programmer with strict rules.
 
But C++ and C do not discipline you at the level of Ada.
 
C and C++ require that you must be disciplined but
it doesn't discipline you at the level of Ada with strict rules,
and that's not good for realtime critical safety systems for example.
 
So i will refrain from using C++ or C in favor of
FreePascal and Dephi and Ada and Java.
 
 
 
Thank you,
Amine Moulay Ramdane.
Mr Flibble <flibble@i42.co.uk>: Dec 26 05:57PM

Some of the idiotic things that regulars of this newsgroup still
continue to advocate:
 
1) Don't use the unsigned integral types despite the fact that the C++
standard library is full of their use.
2) Don't use abstract interfaces (as they advocate against using public
virtual functions).
3) Never derive from standard containers despite the fact that interface
augmentation is useful.
4) Don't use reference members despite the fact that not all classes
need to
be Assignable.
5) Use the memory allocated by std::vector<POD>::reserve() without
constructing elements by bypassing std::vector's modification functions
(e.g. push_back).
 
Use this newsgroup with caution.
 
/Flibble
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 26 01:12AM +0100

On 12/26/2015 1:54 AM, Ramine wrote:
 
> In this example, C++ and C will convert i from a signed int type to
> unsigned int type but this is not good , because this types of
> conversion can cause bugs and errors of logic
 
No, only ignorance about the implicit conversion to unsigned can cause
problems for this specific code. The above result is well-defined
because any conversion of integer to unsigned integer is defined as
yielding the result modulo 2^n where n is the number of value
representation bits in the unsigned type. And it's an expected result.
 
However, there is a closely related feature, namely implicit PROMOTION
up to unsigned in an expression with mixed type operands, where the
above conversion is invoked, that can cause trouble. Specifically, if
integer types Signed and Unsigned have the same size, or Unsigned is
larger than Size, and if such values occur as operands to some built-in
operator, then the Signed value is implicitly converted to Unsigned.
Which is well-defined but can yield nonsense results such as
`string("blah").length() < -5` evaluating to `true`.
 
For more and more specific information about the implicit conversions in
expressions, look up the "usual arithmetic conversions".
 
• • •
 
Recommendations: I recommend using signed integers for numbers and using
unsigned only for bitlevel things. That avoids the surprising automatic
promotions and related bugs, plus, it avoids the common and annoying
warnings about comparing signed and unsigned. Where you need to indicate
that an integer is non-negative, simply use a type alias such as
"Nonnegative", or better, some name specific to the use.
 
• • •
 
To do that, you will in practice need non-member `size` functions that
produce signed integer results, like `static_size`, `n_items` and
`length` below:
 
using Size = ptrdiff_t;
 
// Static capacity of a collection.
 
template< class Type, Size n >
auto constexpr static_size( Ref_<Type[n]> )
-> Size
{ return n; }
 
template< class Type, Size n >
auto constexpr static_size( Ref_<const std::array<Type, n>> )
-> Size
{ return n; }
 
template< Size n >
auto constexpr static_size( Ref_<const std::bitset<n>> )
-> Size
{ return n; }
 
 
// Right-typed (signed integer) dynamic size of a collection.
 
template< class Type >
auto n_items( Ref_<const Type> o )
-> Size
{ return o.size(); }
 
template< Size n >
auto n_items( Ref_<const std::bitset<n>> o )
-> Size
{ return o.count(); } // Corresponds to std::set<int>::size()
 
 
// Lengths of strings.
 
template< class Char, Size n >
auto constexpr length_of_literal( Ref_<const Char[n]> ) //
"length" wraps this.
-> Size
{ return n - 1; }
 
template< class Char, class Traits, class Alloc >
auto length( Object_argument, Ref_<const std::basic_string<Char,
Traits, Alloc>> s )
-> Size
{ return s.length(); }
 
template< class Char >
auto length( Pointer_argument, const Ptr_<const Char> s )
-> Size
{
auto p = s;
while( *p != 0 ) { ++p; }
return p - s;
}
 
template< class Char, Size n
, class Enabled_ = If_< In_< Character_types, Char > >
 
auto constexpr length( Array_argument, Ref_<const Char[n]> a )
-> Size
{ return length_of_literal( a ); }
 
template< class Type >
auto length( Ref_<const Type> o )
-> Size
{ return length( Arg_kind_<Type>(), o ); }
 
The above code is available at GitHub along with other such core
language support, as I recently announced in this group -- but while
that code works with Visual C++ it's not yet even been compiled with
g++, and some of it is only at the 1% to 2% state of completion:
 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4280
 
In C++1z (C++17?) some of the above functions can and probably for
clarity should be expressed in terms of the new `std::size` non-member
function. However, that function is generally unsigned and conflates the
`static_size` and `n_items` functions above, which means that the
wrappers will still be needed, unless the proposal is fixed. See
 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4280
 
for more detailed info.
 
 
> forbid C and C++ on realtime critical systems... and i have read on
> internet that C and C++ are strongly typed languages, how can you
> say that !
 
C is not strongly typed in any sense.
 
C++ supports, but does not require, strongly typed code.
 
Betrand Meyer, in his Software Development book, went on at length about
the difference of /enabling/ something, versus fully /supporting/ it.
C++ enables strongly typed code, and C++ provides much support for it,
but does not require it. That has to do with its historical roots in C,
that C++ must support direct use of most C libraries.
 
 
> type for example, so that makes C and C++ problematic and not suited for
> realtime critical systems and such, ADA and Delphi and FreePascal are in
> fact strongly typed and does not authorize this type of conversion.
 
The problems for designing and implementing real time systems are much
to do with the dangers of parallel processing and less to do with the
low level details of the language at hand.
 
Well, there are of course also management problems. For an example you
might google the Ariane disaster... ;-)
 
Now that C++ supports threads in its standard library it's perhaps even
better suited for real time systems. Still I think very fondly of the
Ada rendezvous mechanism for threads. I don't think that can be easily
emulated (at least not efficiently) in C++!
 
 
Cheers & hth.,
 
- Alf
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 26 01:51AM +0100

On 12/26/2015 1:12 AM, Alf P. Steinbach wrote:
> that code works with Visual C++ it's not yet even been compiled with
> g++, and some of it is only at the 1% to 2% state of completion:
 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4280
 
Sorry, I meant
 

https://github.com/alf-p-steinbach/cppx/blob/plutonium/core_language_support/sizes_and_lengths.hpp
 
 
Cheers,
 
- Alf
JiiPee <no@notvalid.com>: Dec 26 02:17AM

On 26/12/2015 00:12, Alf P. Steinbach wrote:
> Recommendations: I recommend using signed integers for numbers and
> using unsigned only for bitlevel things.
 
yes this is what Bjarne seems to recommend as well
Paul <pepstein5@gmail.com>: Dec 26 03:21AM -0800

On Friday, December 25, 2015 at 11:28:38 PM UTC, JiiPee wrote:
 
> I wonder why the compiler does not give an error here? I think it should
> be like that: unsigned must be converted with static_cast to int, and
> otherwise its a compilation error. Thats how it should be imo.
 
I think C++ allows implicit conversion between unsigned int and int. If an unsigned int and int are in the same expression, there's a question of whether the int is converted to unsigned or vice versa. The answer is that the int is converted to unsigned.
 
If you think that a compiler should give an error here, that is up to you. On most settings, compilers will indeed warn when unsigneds are compared with ints. Gcc additionally has a "Treat warnings as errors" setting. Combine the two settings and voila!
 
Paul
JiiPee <no@notvalid.com>: Dec 26 11:56AM

On 26/12/2015 11:21, Paul wrote:
> I think C++ allows implicit conversion between unsigned int and int. If an unsigned int and int are in the same expression, there's a question of whether the int is converted to unsigned or vice versa. The answer is that the int is converted to unsigned.
 
> If you think that a compiler should give an error here, that is up to you. On most settings, compilers will indeed warn when unsigneds are compared with ints. Gcc additionally has a "Treat warnings as errors" setting. Combine the two settings and voila!
 
> Paul
 
yes ok, that might the solution then. even for the OP. Although
personally I do not see this so much a problem currently as I rarely use
unsigned... I just use int almost everywhere.
Paul <pepstein5@gmail.com>: Dec 26 04:46AM -0800

On Saturday, December 26, 2015 at 11:57:02 AM UTC, JiiPee wrote:
 
> yes ok, that might the solution then. even for the OP. Although
> personally I do not see this so much a problem currently as I rarely use
> unsigned... I just use int almost everywhere.
 
Ok, except that ints might not work very well for Ferrero Rocher chocolates. Since they taste so good (particularly at holiday times where you can eat guilt-free), you might want to use unsigned to buy 2^32-1 of them rather than an int-based approach which lets you eat only 2^31-1. Ints for the dieters, but unsigneds for those who want to maximise consumption.
 
Paul
Mr Flibble <flibble@i42.co.uk>: Dec 26 05:56PM

On 26/12/2015 00:12, Alf P. Steinbach wrote:
> auto length( Ref_<const Type> o )
> -> Size
> { return length( Arg_kind_<Type>(), o ); }
 
Absurd, time for my usual "Idiots" post sausages.
 
/Flibble
Paul <pepstein5@gmail.com>: Dec 26 04:42AM -0800

A depth-first search and a breadth-first search are almost identical except that breadth-first uses a queue and depth-first uses a stack.
 
Suppose we want code that does both. What's the most natural way to take advantage of the similarity to avoid code duplication, using the STL containers? I don't think templates will work because stack is a container adaptor rather than a type. There's also the problem that the name for the topmost element changes -- top() for a stack but front() for a queue.
 
Thank you,
 
Paul
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 26 02:14PM +0100

On 12/26/2015 1:42 PM, Paul wrote:
> container adaptor rather than a type. There's also the problem that
> the name for the topmost element changes -- top() for a stack but
> front() for a queue.
 
Well, there's std::dequeue for you.
 
Cheers & hth.,
 
- Alf
"Öö Tiib" <ootiib@hot.ee>: Dec 26 05:25AM -0800

On Saturday, 26 December 2015 14:42:28 UTC+2, Paul wrote:
> A depth-first search and a breadth-first search are almost identical
> except that breadth-first uses a queue and depth-first uses a stack.
 
You conflate idea and implementation here. Neither algorithm deals with
underlying container types and some third container adaptor for example
'std::priority_queue' can be used for storing progress of both algorithms.
 
> take advantage of the similarity to avoid code duplication, using the
> STL containers? I don't think templates will work because stack is
> a container adaptor rather than a type.
 
What it has to do with anything? AFAIK 'std::queue' is as much a
container adaptor as is 'std::stack'.
 
> There's also the problem that the name for the topmost element
> changes -- top() for a stack but front() for a queue.
 
You can always use lambdas. Lambdas have name only if you name those
and that compilers tend to inline if possible. However what is the
supposed gain here?
Paavo Helde <myfirstname@osa.pri.ee>: Dec 26 04:15AM -0600


> In ADA when you define two types like this:
 
> type length is new float;
> type weight is new float;
 
You can do this in C++ easily, the syntax is just slightly different:
 
struct length { float value; };
 
struct weight { float value; };
 
int main() {
length x{3.14f};
weight y = x;
}
 
1> main.cpp
1>main.cpp(7): error C2440: 'initializing' : cannot convert from
'length' to 'weight'
1> No user-defined-conversion operator available that can
perform this conversion, or the operator cannot be called
 
 
> a signed long to an unsigned long is authorized in C and C++,
> and that's bad because it can cause bugs and errors of logic and
> that's not good for high integrity and realtime safety critical
systems,
> in ADA and FreePascal and Delphi this type of implicit conversion is
not
> so ADA is really suited for high integrity and realtime safety critical
> systems and this is why C and C++ are bad as i have explained to you
> before.
 
C and C++ have many pitfalls. If Ada works better for what you do, you
should use Ada.
 
Cheers
Paavo
nicesw123@gmail.com: Dec 26 12:33AM -0800

1) What is the type of "a"? Is it const char [2]?
 
2) What is the type of decltype("a") ???
How does one get the following to compile and run without asserting?
 
 
#include <iostream>
#include <cassert>
 
int main()
{
assert((std::is_same<
decltype("a"),
???? /* const char [2] */
>::value));
return 0;
}
 
 
 
 
 
Thanks.
nicesw123@gmail.com: Dec 26 12:38AM -0800


> Thanks.
 
Ah I figured it out. One needs to watch out for references when using decltype!
 
 
#include <cassert>
 
int main()
{
assert((std::is_same<decltype("a"), const char (&)[2]>::value));
return 0;
}
nicesw123@gmail.com: Dec 26 12:41AM -0800

Header <type_traits> is needed also.
 
 
#include <type_traits>
#include <cassert>
 
int main()
{
assert((std::is_same<decltype("a"), const char (&)[2]>::value));
return 0;
}
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)