- A "better" C++ - 16 Updates
- Bitset Initialization - 8 Updates
- C++ needs some help - 1 Update
| 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 --- |
| woodbrian77@gmail.com: Nov 30 09:55AM -0800 > I hope you will consider becoming an early adopter > of this approach. There are still some tier-1 > user IDs available. I'm happy to say there are fewer of these tier-1 accounts available today than when I started this thread. I believe these top tier account numbers will be like Boardwalk and Park Place in the future. This is your chance to get in on the ground floor. Brian Ebenezer Enterprises - So far G-d has helped us. http://webEbenezer.net |
| 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. |
No comments:
Post a Comment