Paavo Helde <myfirstname@osa.pri.ee>: Nov 29 06:16PM -0600
> C was the first computer language to successfully change from line
> oriented (Fortran, Cobol, etc) to byte oriented. And, then C++ jumped
> from pure procedural to object oriented.
If you really think OO is the single or the main feature differentiating
C++ from C, then I'm afraid there has been some miscommunication at some
point. There are also for example RAII, templates, functional-programming
features (including lambdas), which all are tangential to OO and which
really make C++ a multi-paradigm language. The RAII concept alone is worth
at least as much as the whole OO paradigm, and yet by some reason it is not
often found in other languages, OO or not.
Cheers
Paavo
|
Lynn McGuire <lmc@winsim.com>: Nov 29 08:21PM -0600
On 11/29/2015 6:16 PM, Paavo Helde wrote:
> often found in other languages, OO or not.
> Cheers
> Paavo
Cool, you helped my argument that C and C++ are a major change in the
way that computer software is written.
I started writing software using Fortran IV on a Univac 1108 in 1975
with punch cards and a line printer. Today's software tools are simply
amazing even though I am a big C++ fan.
I've got 800,000 lines of Fortran code and 500,000 lines of C++ in our
application. The cost of maintaining the Fortran code is eating me
alive whereas the C++ code is extremely extensible and maintainable. If
I could wave a magic wand and convert my F77 code to C++, I would do it
right now.
Thanks,
Lynn
|
Wouter van Ooijen <wouter@voti.nl>: Nov 30 07:43AM +0100
Op 29-Nov-15 om 11:22 PM schreef Lynn McGuire:
>> Algol 60.
>> Bo Persson
> Sorry, Algol was not a successful computer language.
Even if you don't regard it as a sucessfull language as such, it has set
the standard for block-scoped goto-less line-agnostic syntax for
(nearly?) all subsequent languages.
Wouter
|
Christian Gollwitzer <auriocus@gmx.de>: Nov 30 09:17AM +0100
Am 30.11.15 um 03:21 schrieb Lynn McGuire:
> If
> I could wave a magic wand and convert my F77 code to C++, I would do it
> right now.
http://www.netlib.org/f2c/
(just kidding)
Christian
|
scott@slp53.sl.home (Scott Lurndal): Nov 30 02:07PM
>> Consider this quote from Rob Pike, one of the developers of the Go
>> programming language, which he gave in a speech in 2012:
>C was the first computer language to successfully change from line
I give you ALGOL, SPL/3000, BPL, Bliss, BCPL and a handful of other
languages predating C.
|
scott@slp53.sl.home (Scott Lurndal): Nov 30 02:08PM
>> Algol 60.
>> Bo Persson
>Sorry, Algol was not a successful computer language.
By what criteria? It is still in widespread use in certain
verticals on Unisys (nee Burroughs) hardware.
|
Lynn McGuire <lmc@winsim.com>: Nov 30 12:31PM -0600
On 11/30/2015 2:17 AM, Christian Gollwitzer wrote:
> http://www.netlib.org/f2c/
> (just kidding)
> Christian
I wish. The code from f2c is absolutely horrible.
We are going to try Fable next:
http://cci.lbl.gov/fable/
Lynn
|
Lynn McGuire <lmc@winsim.com>: Nov 30 12:32PM -0600
On 11/30/2015 8:07 AM, Scott Lurndal wrote:
>> C was the first computer language to successfully change from line
> I give you ALGOL, SPL/3000, BPL, Bliss, BCPL and a handful of other
> languages predating C.
None of these were successful in the marketplace of life.
Lynn
|
Lynn McGuire <lmc@winsim.com>: Nov 30 12:33PM -0600
On 11/30/2015 8:08 AM, Scott Lurndal wrote:
>> Sorry, Algol was not a successful computer language.
> By what criteria? It is still in widespread use in certain
> verticals on Unisys (nee Burroughs) hardware.
Mine.
Lynn
|
Lynn McGuire <lmc@winsim.com>: Nov 30 12:34PM -0600
On 11/30/2015 12:43 AM, Wouter van Ooijen wrote:
> Even if you don't regard it as a sucessfull language as such, it has set the standard for block-scoped goto-less line-agnostic syntax
> for (nearly?) all subsequent languages.
> Wouter
Great experimental language according to my Dad who wrote refinery optimization programs in it for Shell. But it did not make the
jump to common usage.
Lynn
|
Lynn McGuire <lmc@winsim.com>: Nov 30 12:36PM -0600
On 11/30/2015 8:07 AM, Scott Lurndal wrote:
>> C was the first computer language to successfully change from line
> I give you ALGOL, SPL/3000, BPL, Bliss, BCPL and a handful of other
> languages predating C.
BTW, my list of successful computer languages is:
1. Assembly language
2. Fortran
3. Cobol
4. C
5. C++
6. PHP
7. HTML
8. Objective C/C++
9. Perl
10. C#
11. Java
Lynn
|
Juha Nieminen <nospam@thanks.invalid>: Nov 30 06:54PM
> 1. Assembly language
Whether assembly can be considered a "programming language" is a matter
of opinion and definition.
Sure, it gives a readable name to each opcode, and the compiler will
calculate jump offsets and addresses for you, but... that's about it.
It's almost as much of a "programming language" as writing executable
binary code in raw bytes directly. Maybe not as hard, but not much
easier either.
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
|
scott@slp53.sl.home (Scott Lurndal): Nov 30 07:17PM
>> I give you ALGOL, SPL/3000, BPL, Bliss, BCPL and a handful of other
>> languages predating C.
>None of these were successful in the marketplace of life.
You wrote "C was the first computer language to successfully change
from line to byte".
I wrote that ALGOL, SPL/3000, BPL, Bliss, BCPL and a handful of
other languages which predated C were byte-oriented.
You made no claim about success, however, your claim that
the aforementioned languages weren't "successful in the marketplace
of life" is complete nonsense.
|
scott@slp53.sl.home (Scott Lurndal): Nov 30 07:18PM
>> By what criteria? It is still in widespread use in certain
>> verticals on Unisys (nee Burroughs) hardware.
>Mine.
Which is completely meaningless when you communicate
with others in the field.
|
Lynn McGuire <lmc@winsim.com>: Nov 30 03:16PM -0600
On 11/30/2015 12:36 PM, Lynn McGuire wrote:
> 10. C#
> 11. Java
> Lynn
Oops, I left off:
12. Basic
Lynn
|
Lynn McGuire <lmc@winsim.com>: Nov 30 03:22PM -0600
On 11/30/2015 12:54 PM, Juha Nieminen wrote:
> It's almost as much of a "programming language" as writing executable
> binary code in raw bytes directly. Maybe not as hard, but not much
> easier either.
Calculating those jumps and offsets is non-trivial. I took an IBM 370 Macro Assembly course in college and had to calculate those
jumps and offsets by hand. And not all opcodes translate into a single machine instruction.
Here are the current top 50 computer languages by searches. Assembly is #11.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Huh, Pascal is #11 and #17. I would have never thought it was in the top 50 anymore.
Lynn
|
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 30 04:38AM +0100
On 11/29/2015 9:27 PM, MikeCopeland wrote:
> I can, of course, construct a string constant of these bits, but it's
> tedious to code and completely lacking in good documentation...
> Is there an easy way to do so in source code? TIA
The answers so far have just presented short, easy to grasp code.
But a challenge to simplify one little aspect of notation requires lots
more code, to hone that little aspect down to the very simplest! Like
my::Bits<100> const bits = { 7, 9, 43, 47, Range( 51, 59 ), 66, 67 };
In the following I have however refrained from adding the most obvious
things like standard typedefs for iterators, or a formally correct
operator++(int); I leave those details to the reader!
<code>
#include <bitset>
#include <functional> // std::equal_to, std::less
#include <initializer_list>
#include <iostream>
#include <stddef.h> // ptrdiff_t
#include <utility> // std::move
namespace my {
using std::bitset;
using std::equal_to;
using std::initializer_list;
using std::less;
using std::move;
using Size = ptrdiff_t;
template< class Type >
auto n_items( Type const& o ) -> Size { return o.size(); }
template< class Type >
auto stdcmp( Type&& a, Type&& b )
-> int
{
using Eq = equal_to<Type>;
using Lt = less<Type>;
return (Eq()( a, b )? 0 : Lt()( a, b )? -1 : +1);
}
template< class State >
class Forward_iterator
{
private:
State state_;
public:
friend
auto operator==( Forward_iterator const& a, Forward_iterator
const& b )
-> bool
{ return (compare( a.state_, b.state_ ) == 0); }
friend
auto operator!=( Forward_iterator const& a, Forward_iterator
const& b )
-> bool
{ return (compare( a.state_, b.state_ ) != 0); }
auto operator++()
-> Forward_iterator&
{ state_.advance(); return *this; }
void operator++( int )
{
//Forward_iterator result = *this;
state_.advance();
//return result;
}
auto operator*() const
-> decltype( state_.referent() )
{ return state_.referent(); }
Forward_iterator( State state ): state_( move( state ) ) {}
};
template< class Type = int >
class Int_range
{
private:
Type first_;
Type last_;
class Iterstate
{
friend class Int_range<Type>;
private:
Int_range const* p_range_;
Type current_;
Iterstate( Int_range const& range, Type const where )
: p_range_( &range ), current_( where )
{}
public:
friend
auto compare( Iterstate const& a, Iterstate const& b )
-> int
{
if( int const r = stdcmp( a.p_range_, b.p_range_ ) ) {
return r; };
return stdcmp( a.current_, b.current_ );
}
void advance() { ++current_; }
auto referent() const -> Type { return current_; }
};
public:
using Iterator = Forward_iterator<Iterstate>;
auto begin() const
-> Iterator
{ return Iterator( Iterstate( *this, first_ ) ); }
auto end() const
-> Iterator
{ return Iterator( Iterstate( *this, last_ + 1 ) ); }
Int_range( Type const value )
: first_( value ), last_( value )
{}
Int_range( Type const a, Type const b )
: first_( a ), last_( b )
{}
};
template< Size n >
class Bits
: public std::bitset< n >
{
public:
Bits( initializer_list<Int_range<>> const& one_bits )
{
for( Int_range<> const& r : one_bits )
{
for( int const i : r )
{
this->set( i );
}
}
}
};
} // namespace my
auto main() -> int
{
using Range = my::Int_range<>;
my::Bits<100> const bits = { 7, 9, 43, 47, Range( 51, 59 ), 66, 67 };
std::cout << "Bits ";
for ( int i = 0; i < n_items( bits ); i++)
{
if( bits.test(i) )
{
std::cout << i << ' ';
}
}
std::cout << "are set." << std::endl;
}
</code>
Cheers, & hth.,
- Alf
|
"Öö Tiib" <ootiib@hot.ee>: Nov 29 10:25PM -0800
On Sunday, 29 November 2015 22:27:32 UTC+2, MikeCopeland wrote:
> I can, of course, construct a string constant of these bits, but it's
> tedious to code and completely lacking in good documentation...
> Is there an easy way to do so in source code? TIA
To set 15 concrete bits you can just use 'set':
#include <iostream>
#include <bitset>
int main()
{
std::bitset<100> myBits;
myBits.set( 7).set( 9).set(43).set(47).set(51)
.set(52).set(53).set(54).set(55).set(56)
.set(57).set(58).set(59).set(66).set(67);
std::cout << myBits << '\n';
}
Magic numbers make it to look like binary dump, better name your bits.
|
Paavo Helde <myfirstname@osa.pri.ee>: Nov 30 02:31AM -0600
> But your requirement reminds me of the Pascal way to do the same:
> var myBits: set of 1..100;
> myBits := [7, 9, 43, 47, 51..59, 66, 67];
In C++ there are two different containers for holding such things,
std::set and std::bitset. I guess the Pascal sets are internally
implemented similarly to C++ std::set. Coincidentally, initializing a
std::set would indeed be one line in C++:
std::set<int> myBits {7, 9, 43, 47, 51, 52, 53, 54, 55, 56, 57, 58, 59,
66, 67};
Alas, integer type range restriction is not present here. One could use a
custom class (e.g. boost::constrained_value) instead of int here, but
this is not in standard.
std::bitset is a different beast which encapsulates an array of bits.
Coincidentally, it suits better for emulating Pascal subrange type 'set
of 0..N', for small values of N. Alas, it is lacking a convenience
constructor taking a list of bits, I guess this might be just an
oversight.
Cheers
Paavo
|
Juha Nieminen <nospam@thanks.invalid>: Nov 30 09:24AM
> using std::initializer_list;
> using std::less;
> using std::move;
Why?
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
|
"K. Frank" <kfrank29.c@gmail.com>: Nov 30 06:39AM -0800
Hi Juha (and Alf)!
On Monday, November 30, 2015 at 4:24:51 AM UTC-5, Juha Nieminen wrote:
> > using std::less;
> > using std::move;
> Why?
Why?
Because this is a c++ newsgroup where people explore
ideas with like-minded (or sometimes unlike-minded)
members of the community. It's a good place to try
things out that might be interesting but not fully
baked, and might not have a place in production code.
Personally, I welcome Alf's posts. Some of them I
find to be gratuitous overkill, but others I find
to be informative and thought-provoking, even if I
wouldn't use them in "real" code.
It's good to experiment.
And in fairness, Alf did begin his post with:
> But a challenge to simplify one little aspect of
> notation requires lots more code, to hone that little
> aspect down to the very simplest!
which I take to be Alf-speak for "others have already
posted the practical solution, but let's go ahead and
have a little fun here ..."
Or, in short, why not?
Happy Hacking!
K. Frank
|
David Brown <david.brown@hesbynett.no>: Nov 30 03:52PM +0100
On 30/11/15 10:24, Juha Nieminen wrote:
>> using std::less;
>> using std::move;
> Why?
My guess is that Alf wants to simplify the code that uses these common
identifiers, but does not want a global "using std" to fill up his
namespace.
It is also possible that he uses a common #include file in his
programming that lists a number of these "using" clauses, but for the
example here he has copied them in directly. Perhaps in his normal code
he simply writes #include "using_std.h" to bring in a few dozen common
identifiers.
|
"Öö Tiib" <ootiib@hot.ee>: Nov 30 08:18AM -0800
On Monday, 30 November 2015 16:53:13 UTC+2, David Brown wrote:
> My guess is that Alf wants to simplify the code that uses these common
> identifiers, but does not want a global "using std" to fill up his
> namespace.
You meant 'using namespace std'.
> example here he has copied them in directly. Perhaps in his normal code
> he simply writes #include "using_std.h" to bring in a few dozen common
> identifiers.
That is unlikely. It was still about declaring names in namespace 'my'.
The row of using declarations (that replace less flexible 'typedef' of
C++03) is like "terms and abbreviations" at start of document.
IOW that:
namespace my {
using std::bitset;
}
It means that 'bitset' in context of 'my' means 'std::bitset'.
Or that:
namespace my {
template<std::size_t N>
using Flags = std::bitset<N>;
}
It means that 'Flags' in namespace 'my' means 'std::bitset'.
Such aliasing perhaps gives diminishing returns on case of 'std::bitset'
but can make usage of types with long names (like
std::chrono::high_resolution_clock) or very flexibly configurable
templates (like 'boost::multi_index_container' or
'boost::adjacency_matrix') notably more readable.
However once we use aliasing to some names from other scopes then it
can be considered cleaner and more uniform to alias every "foreign"
name used.
|
Juha Nieminen <nospam@thanks.invalid>: Nov 30 06:56PM
> members of the community. It's a good place to try
> things out that might be interesting but not fully
> baked, and might not have a place in production code.
My objection was not to his program or his contribution.
My objection was to his needless abuse of 'using'.
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
|
