Wednesday, June 29, 2016

Digest for comp.lang.c++@googlegroups.com - 14 updates in 4 topics

Lynn McGuire <lmc@winsim.com>: Jun 29 04:54PM -0500

"CppCast interview about the Oulu ISO C++ meeting" by Herb Sutter
https://herbsutter.com/2016/06/27/cppcast-interview-about-the-oulu-iso-c-meeting/
 
"On Saturday afternoon, at the ISO C++ meeting in Oulu, Finland, we completed the feature set of C++17 and approved sending out the
feature-complete document for its primary international comment ballot (aka "CD" or Committee Draft ballot)."
 
Lynn
ram@zedat.fu-berlin.de (Stefan Ram): Jun 29 04:33AM

> There's no way to handle this situation
>using only the standard library, where case conversion is assumed to map
>one character to one character.
 
No way?
 
It was always possible to use a custom character encoding, where
»SS« is represented by a single code point (character); it still
can be rendered »SS«, which is a question of I/O. Especially,
Unicode already has »U+1E9E LATIN CAPITAL LETTER SHARP S«.
¯¯¯¯¯¯¯
ram@zedat.fu-berlin.de (Stefan Ram): Jun 29 05:24PM

>It was always possible to use a custom character encoding, where
>»SS« is represented by a single code point (character); it still
>can be rendered »SS«, which is a question of I/O.
 
And there even is a precedent for it: »"\n"« (one character),
which sometimes is output as »"\015\012"« (two characters).
ram@zedat.fu-berlin.de (Stefan Ram): Jun 29 08:11PM

>>which sometimes is output as »"\015\012"« (two characters).
>But that would break the Unix-land convention for narrow streams, that
>(in Unix-land) they only shuffle bytes, with no interpretation.
 
In C++ we have 27.5.3.1.4p1 »binary« »perform input and
output in binary mode (as opposed to text mode)« to
shuffle bytes with no interpretation.
 
Or, we have »text mode«, which is what I was thinking
about above.
 
However, since on input under »DOS« »\015\012« is
being converted to »\n«, and then on output »\n« is
being converted to »\015\012« again, a plain copy,
even in text mode, would not modify the bytes »\015\012«.
Nobody <nobody@nowhere.invalid>: Jun 29 12:39AM +0100

On Tue, 28 Jun 2016 13:16:55 -0700, James Moe wrote:
 
> A case insensitive substring search: How hard can it be?.
 
Substring search is provided by the std::basic_string::find() method.
Comparisons are performed using the eq() member of the traits class,
so if you use a traits class where eq() is case-insensitive, you get a
case-insensitive substring comparison.
 
But that requires using an explicit specialisation of std::basic_string
rather than just using std::string or std::wstring (which use
std::char_traits implicitly). A cast would almost certainly work, but
(AFAIK) it's not guaranteed.
 
Whatever method you choose, there's the issue that it isn't always
possible to perform a case-insensitive comparison character-by-character.
 
The classic example of where this fails is that the German "sharp s"
character ("ß") doesn't have an equivalent upper-case character; the
upper-case equivalent is "SS". There's no way to handle this situation
using only the standard library, where case conversion is assumed to map
one character to one character.
James Moe <jimoeDESPAM@sohnen-moe.com>: Jun 28 10:25PM -0700

On 06/28/2016 03:48 PM, Ben Bacarisse wrote:
> You need search, not search_n.
 
Tried that. No luck.
bool strstricmp (string & s1, string & sub2)
{
string::iterator pos;
 
pos = search(s1.begin, s1.end(),
sub2.begin(), sub2.end(),
icompare);
return (pos != s1.end());
}
Complains that there is no match for the predicate.
 
> And if you are using modern C++ you can [...]
 
Alas, no. g++ 4.7.3.
 
--
James Moe
jmm-list at sohnen-moe dot com
Think.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jun 29 10:56AM +0100

> return (pos != s1.end());
> }
> Complains that there is no match for the predicate.
 
Seems odd. I'd expect more problems to come from the missing () after
s1.begin. When I fix that, it works here.
 
You should consider making s1 and sub2 references to const.
 
>> And if you are using modern C++ you can [...]
 
> Alas, no. g++ 4.7.3.
 
The [...] went on to suggest using an anonymous function. I thought
these were introduced in gcc 4.5.
 
--
Ben.
"Öö Tiib" <ootiib@hot.ee>: Jun 29 04:19AM -0700

On Wednesday, 29 June 2016 12:56:32 UTC+3, Ben Bacarisse wrote:
> > Complains that there is no match for the predicate.
 
> Seems odd. I'd expect more problems to come from the missing () after
> s1.begin. When I fix that, it works here.
 
May be that James has some user-defined things named 'search'
and/or 'string'. With 'std::string' and 'std::search' his code will be
rejected because of missing '()' after 's1.begin'.
 
 
> > Alas, no. g++ 4.7.3.
 
> The [...] went on to suggest using an anonymous function. I thought
> these were introduced in gcc 4.5.
 
Yes, lambdas were available since gcc 4.5.
"Öö Tiib" <ootiib@hot.ee>: Jun 29 06:22AM -0700

On Wednesday, 29 June 2016 02:38:24 UTC+3, Nobody wrote:
 
> The classic example of where this fails is that the German "sharp s"
> character ("ß") doesn't have an equivalent upper-case character; the
> upper-case equivalent is "SS".
 
So some capitalized word in text (say "RUSSEN") may be one German
word ("rußen") or other German word ("Russen") or same-looking
word or name from some other language?
 
> There's no way to handle this situation using only the standard
> library, where case conversion is assumed to map one character
> to one character.
 
If the issue is like I described above then it can't be handled with
whatever software and even for real human operator it is possible
to construct ambiguous input that the operator can't decide. If
treating "ß" and "ss" as equivalents is good enough hack around
it then however it is doable.
Ralf Goertz <me@myprovider.invalid>: Jun 29 05:16PM +0200

Am Wed, 29 Jun 2016 06:22:48 -0700 (PDT)
 
> So some capitalized word in text (say "RUSSEN") may be one German word
> ("rußen") or other German word ("Russen") or same-looking word or name
> from some other language?
 
If there is going to be an ambiguity like in your example a capitalized
ß becomes SZ which is what it really is. AFAIK the origin of the ß is a
ligature of ſ (long s) and z. Another more common example of this
ambiguity would be „Maße" (measures). It will become „MASZE" not „MASSE"
(mass).
James Moe <jimoeDESPAM@sohnen-moe.com>: Jun 29 10:48AM -0700

On 06/28/2016 10:25 PM, James Moe wrote:
> pos = search(s1.begin, s1.end(),
 
Bzzt! User error.
That should be "s1.begin()", not "s1.begin".
 
--
James Moe
jmm-list at sohnen-moe dot com
Think.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 29 09:32PM +0200

On 29.06.2016 19:24, Stefan Ram wrote:
>> can be rendered »SS«, which is a question of I/O.
 
> And there even is a precedent for it: »"\n"« (one character),
> which sometimes is output as »"\015\012"« (two characters).
 
But that would break the Unix-land convention for narrow streams, that
(in Unix-land) they only shuffle bytes, with no interpretation.
 
Also keep in mind that in Unix-land the narrow streams are now usually
UTF-8 encoded, with a variable number of bytes per Unicode code point.
 
But I like the idea of the uppercase sharp S. I didn't know about it
until your posting. Thanks!
 
 
Cheers!,
 
- Alf
"J. Clarke" <j.clarke.873638@gmail.com>: Jun 28 08:13PM -0400

In article <nkttkg$81t$1@dont-email.me>, no@spam.net says...
> nonprofessionals programming academic stuff like myself) are not aware
> of the many new additions to the standard, already available in many
> compilers.
 
The trouble we are having with Fortran is that we have to train every
new hire on it. It's not something that people know coming in the door
and if they do it's one of those "modern" Fortrans and not the extended
77 which is what runs on the Z. Between that an JCL, it's often a long
time before somebody is productive. As for linking with C, if C
couldn't link with Fortran it would have been a non-starter for us, but
this is IBM software and IBM hardware and however painful it may be,
there's usually a way to get it to work together.
 
Jerry Stuckle <jstucklex@attglobal.net>: Jun 28 08:45PM -0400

On 6/28/2016 8:13 PM, J. Clarke wrote:
> couldn't link with Fortran it would have been a non-starter for us, but
> this is IBM software and IBM hardware and however painful it may be,
> there's usually a way to get it to work together.
 
Gee, how times have changed. Fortran was the first language I learned
:) But it seems it's only commonly used where the heavy math is
required. Not as much used for general purpose things like C is.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.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.
Posted by at No comments:

Fwd: Colors



Sent from my iPad

Begin forwarded message:

From: Sharon Kahn <sharon62kahn@gmail.com>
Date: June 28, 2016 at 6:48:33 PM CDT
Subject: Fwd: Colors









Subject: Colors





 

Posted by at No comments:

Tuesday, June 28, 2016

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

James Moe <jimoeDESPAM@sohnen-moe.com>: Jun 28 01:16PM -0700

Hello,
A case insensitive substring search: How hard can it be?.
I searched for it. There are lots of case insensitive string searches,
but very few case insensitive substring searches. Nothing that I could
understand.
I came up with the following. It seemed that search_n() was perfect
for a substring search; I just had to supply an appropriate comparison
function. which is where I stalled.
 
bool icompare (unsigned char a, unsigned char b)
{
return (toupper(a) == toupper(b));
}
 
bool strstricmp (string & s1, string & sub2)
{
string::iterator pos;
 
pos = search_n(s1.begin, s1.end(),
1,
sub2,
icompare());
return (pos != s1.end());
}
 
The main problem is what to supply icompare() as parameters? Probably
the wrong choice.
 
This was a cakewalk in C. Creating a C++-worthy function is not so easy.
 
--
James Moe
jmm-list at sohnen-moe dot com
Think.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jun 28 11:48PM +0100

> I came up with the following. It seemed that search_n() was perfect
> for a substring search; I just had to supply an appropriate comparison
> function. which is where I stalled.
 
You need search, not search_n. And if you are using modern C++ you can
pass a lambda for the comparison function so there is no need for an
extra named function (though that's not a big deal).
 
<snip>
--
Ben.
grizlyk <grizlyk1@yandex.ru>: Jun 28 12:24PM -0700

Concerning implicit template parameter specification.
 
Good day.
1. There is random taken original code
 
//mouse wheel
class Va_mw: public Vaction{
public:
void proceed();
 
Va_mw():key_timer_passed(0){}
 
protected:
//what mouse event to do in child
virtual
void m_event()=0;
 
//repeat time counter
unsigned key_timer_passed;
};
 
//mouse wheel up
class Te_mw_up: public Va_mw{
public:
//on hold
void m_event();
};
 
//mouse wheel dn
class Te_mw_dn: public Va_mw{
public:
//on hold
void m_event();
};
 
The code was redesigned and it was useful to apply template here. If you have questions about template parameter type definition, you can consider the folowing way of the implicit type definition
 
//Ta_mwe::Tevent compile time interface
template<class Tevent>
class Ia_mwe_event{
public:
//void m_event();
typedef
void
(Tevent::* f_m_event)
();
 
public:
Ia_mwe_event(){
f_m_event m_event= &Tevent::m_event;
}
};
 
//mouse wheel up
class Tevent_mw_up{
public:
//on hold
void m_event();
 
protected:
Ia_mwe_event<Tevent_mw_up>
anIevent;
};
 
//mouse wheel
template<class Tevent>
class Ta_mwe: public Vaction{
public:
void proceed();
 
protected:
Tevent e_mw;
 
protected:
Ia_mwe_event<Tevent>
anIevent;
};
 
2. To remove the low level type support code, C++ can be improved.
 
the code above is C++ "allows but does not support" low level implicit way to use the following proposed rules:
 
compile time interface for abstract types of data (ADT)
#//mouse wheel event
#using interface = std::ct_adt_interface;
#interface Ia_mw_event{
#public:
# void m_event();
#};
';' is mandatory here, the same as class scope
 
interface name can be used instead of typeless "class" keyword for template parameter declaration
interface name can be used to specialization of declared typeless "class" template parameter
#//mouse wheel
#template<Ia_mw_event Tevent>
#class Ta_mw: public Vaction{
#public:
#...
 
interface can not be used as run-time template (as ordinary C++ run-time interface "class" does)
because there is no the object in memory as "interface" and object of "interface type" can not be defined
 
abstract types of data itself has no "inheritance" mechanism of class creation of object programming
so interface can not be inherited as ordinary C++ class does
and interface can not be inherited by class syntax to avoid confusing with class specific inheritance rules
 
but abstract types of data itself must have a way to generic use different ADTs with the same methods in code templates
so to declare class, which is complaint an interface, the following syntax must be used
class name [: list of base class](optional) [interface: list of interfaces](optional) [{ class body }](class definition);
#//mouse wheel up
#class Tevent_mw_up
#interface: public Ia_mw_event{
#public:
#...
here class Tevent_mw_up can be used where interface Ia_mw_event does
 
members and types which are declared in an interface must be defined in classes which are complaint the interface
and the interface members can not be removed by class declaration
 
to declare interface, which is complaint the other interface, the following syntax must be used
interface name [interface: list of interfaces](optional) [{ interface body }](interface definition);
#interface Ia_mw_event2
#interface: Ia_mw_event{
#public:
# void m_event2();
#};
here interface Ia_mw_event2 can be used where interface Ia_mw_event does
 
interface can declare other interfaces as members by the following syntax of object definition of "interface type"
#interface Ia_mw_event3{
#public:
# Ia_mw_event a_mw_event;
#};
in classes Ia_mw_event interface type name must be replaced by class type name which are complaint the interface
here Ia_mw_event must not be used as template parameter
because all Ia_mw_event replacements are the same Ia_mw_event3 compile time interface
but template parameters used to create different compile-time interfaces by different parameters with similar compile-time interface
in other words, all compile time interface names "already generic by default"
 
the same example with "template" used for another purpose and the interface definition
will produce set of different compile time interfaces Ia_mw_event4<>, depends on anIa_mw_event
#template<Ia_mw_event anIa_mw_event>
#interface Ia_mw_event4{
#public:
# anIa_mw_event a_mw_event;
#};
 
interface can define internal interfaces as own namespace members with the same generic "interface definition"
 
interface can define own members by exporting member declaration from other interfaces with "using" by the following syntax
using [interface](optional) interface_name;
using interface_name::member_name;
in the case "new" interface is not the same as "used" though has the same members
the way is intended to break links between different classes with similar members by type, but logically not equal ones
interface can explicitly redeclare items inserted by "using" by ordinary rules
 
interface can define own scope member by the following syntax of namespace definition
namespace scope_name{
}
"interface scope" can be accessed with "::" operator like this: "interface_name::scope_name", not by "."
interface scope can define own members by exporting member declaration from other interfaces with "using" keyword
interface can explicitly redeclare items within namespace inserted by "using" by ordinary rules
 
class can include interfaces with "using" keyword for internal purposes
all members of the "using" interface must be declared in the class
but the class will not be complaint the "using" interface
 
changed interface can be added to class outside of class definition by ordinary work with interfaces
which are already declared inside class definition
(work by inherinace existed interface, by include existed interface, etc)
in general case it is prohibited to add changed interfaces to class outside of class definition
 
so in order to add new interfaces to class outside of class definition
in general case you must create new class but the same as existing
but to avoid the useless work with run-time properties of the existing class
there is a way to add new interfaces to class outside of class definition
by the following syntax
interface interface_name = class_name [, class_name](optional);
"interface_name" and "class_name" must be declared (but may be not defined)
"class_name" can be tested for compliant to "interface_name" in the point of both class and interface definition
the same as if "interface_name" was declared inside "class_name" definition
 
PS:
Complete text of the code example can be obtained here http://grizlyk1.narod.ru/cpp_new/msg02/template_interfaces_280616.pdf (only C++ code and C++ improvements rules in english)
 
Best regards.
"J. Clarke" <j.clarke.873638@gmail.com>: Jun 27 09:59PM -0400

In article <be4c8772-84b7-4d08-aa70-acd4496da460@googlegroups.com>,
ootiib@hot.ee says...
> > reflect the age of the language more than it does the quality of it.
 
> Example about nonexistence of programming language is hardly about
> age of it.
 
It is exactly about the age of it. No code was written before it
existed. A little code was written shortly after it existed. More code
was written later.
 
 
> > > 14 years old programming language is not new.
 
> > Cobol is over 50. Fortran is over 60. APL is 52.
 
> What known software is written in those, then? Or are those "too old"?
 
The entire accounting system at my employer for one. The Fortran is
being ported to C, a piece at a time but the Cobol is doing just fine.
The APL is used for the testing that keeps the other code honest.
 
That software is managing a portfolio larger than the GDP of Sweden.
 
Don't assume that the only software that exists is the stuff you find on
github or can buy online. And don't assume that it all runs on PCs and
Linux either.
 
> old programming language. The reason is that you for one consider it too
> new for that. You seemingly even consider about 21 years old Java and
> Python as new. For me tools of that age must be rather mature.
 
No, the reasoning is that arguing quanity of code is pointless.
"Öö Tiib" <ootiib@hot.ee>: Jun 28 12:52AM -0700

On Tuesday, 28 June 2016 04:59:40 UTC+3, J. Clarke wrote:
 
> It is exactly about the age of it. No code was written before it
> existed. A little code was written shortly after it existed. More code
> was written later.
 
That all is true but what has it to do with the usefulness of results
of that writing of code?
 
 
> The entire accounting system at my employer for one. The Fortran is
> being ported to C, a piece at a time but the Cobol is doing just fine.
> The APL is used for the testing that keeps the other code honest.
 
You dodge "known". So how we can judge quality of it?

 
> That software is managing a portfolio larger than the GDP of Sweden.
 
That is perhaps indirect indicator of quality of described software? Not
convincing, sorry.
 
 
> Don't assume that the only software that exists is the stuff you find on
> github or can buy online. And don't assume that it all runs on PCs and
> Linux either.
 
I was not about quantity of code lines that exist and run somewhere.
It is perhaps PHP and Javascript that win that field (despite being "young"
by your standards). Quantity is orthogonal to quality.
 
> > new for that. You seemingly even consider about 21 years old Java and
> > Python as new. For me tools of that age must be rather mature.
 
> No, the reasoning is that arguing quanity of code is pointless.
 
You seem to misunderstand my point and fight with a straw man. I was
writing "what is expressed in it" in meaning "what are the best known pieces
expressed in it". It does not indeed matter how lot of (whatever garbage)
code is written in a language. C# may be indeed wins both C and C++
already on that field despite its younger age.
scott@slp53.sl.home (Scott Lurndal): Jun 28 12:40PM

>> being ported to C, a piece at a time but the Cobol is doing just fine.
>> The APL is used for the testing that keeps the other code honest.
 
>You dodge "known". So how we can judge quality of it?
 
Good grief. The vast majority of software is bespoke.
Ghost <no@spam.net>: Jun 28 10:21AM -0300

Em 27/06/2016 22:59, J. Clarke escreveu:
 
> The entire accounting system at my employer for one. The Fortran is
> being ported to C, a piece at a time but the Cobol is doing just fine.
> The APL is used for the testing that keeps the other code honest.
 
Not assuming that you don't already know, perhaps it is worth mentioning
that the Fortran standard has had a couple of revisions, the latest of
which being called "Modern" Fortran by authors (Fortran 2003 and
Fortran 2008). One notable addition is what the standard calls
/interoperability/ with C, which is a standardized way to link Fortran
code to C code. It is notable that so many Fortran programmers (mostly
nonprofessionals programming academic stuff like myself) are not aware
of the many new additions to the standard, already available in many
compilers.
 
"Öö Tiib" <ootiib@hot.ee>: Jun 28 07:55AM -0700

On Tuesday, 28 June 2016 15:40:20 UTC+3, Scott Lurndal wrote:
> >> The APL is used for the testing that keeps the other code honest.
 
> >You dodge "known". So how we can judge quality of it?
 
> Good grief. The vast majority of software is bespoke.
 
That may be true but is irrelevant. We still can't say how good it is,
even if we know that there are huge amounts of unknown software.
 
Similarly wast majority of what is said in English may be vulgar
nonsense but that does not reduce its usefulness for writing
poetry or scientific papers.
Ghost <no@spam.net>: Jun 28 10:25AM -0300

Em 23/06/2016 14:05, Ghost escreveu:
> that Fortran doesn't have unsigned types.
 
> Any help appreciated.
> Thanks.
 
I should mention that doing this wasn't necessary after all. The
Fortran standard, through its /iso_c_binding/ module, has this
situation covered by means of things like c_ptr and c_funptr.
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:

Fwd: 神似! - Look alike, Very funny!



Sent from my iPad

Begin forwarded message:

From: Hsiao-Hung <k6hsi@aol.com>
Date: June 28, 2016 at 3:14:40 PM CDT
Subject: Fwd: 神似! - Look alike, Very funny!



標題: Fwd: 神似! - Look alike, Very funny!











Below :  the most look alike is .....
.
.


   








Posted by at No comments:

Fwd: 全球最适合养老的21个国家，美得变态，瑞士第一中国第...Best countries for retirees to live in




Subject: Fw: FW: 全球最适合养老的21个国家，美得变态，瑞士第一中国第...Best countries for retirees to live in


這些國家雖様様條件都好 ， 但是一般老人如語言不通， 加上沒有朋友， 那種終老的日子也難敖呀！

   同意！。有老本，老伴，老友，親人，語言通，環境熟---就是最好的養老之郷。
    山水美丽的地方，不妨去旅游，不是久居。你説呢？
Posted by at No comments:

Digest for comp.programming.threads@googlegroups.com - 1 update in 1 topic

the janky <thetatemdeluxe@gmail.com>: Jun 27 07:00AM -0700


> > --
> > John Dallman, jgd@cix.co.uk, HTML mail is treated as probable spam.
 
> Maybe he could read Binary. You never know.
 
010010010010000001101000011010010110011101101000011011000111100100100000011001000110111101110101011000100111010000100000011010010111010000101110
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.programming.threads+unsubscribe@googlegroups.com.
Posted by at No comments:

Monday, June 27, 2016

Digest for comp.lang.c++@googlegroups.com - 6 updates in 3 topics

"Chris M. Thomasson" <invalid@invalid.invalid>: Jun 27 01:16PM -0700

On 6/26/2016 8:52 AM, Peter Fairbrother wrote:
> On 21/02/16 21:38, Chris M. Thomasson wrote:
>> Original idea by Juaquin Anderson in the comments of the
>> following thread:
[...]
> the imaginary parts as plaintext bits, seems like it would work.
 
> but oh oh, what is an escape orbit? for each iteration?
 
> If you/he means the imaginary part of x, then it seems to make some sense.
 
FWIW, my experiments say its the sign of the (real) part, during forward
iteration that can recreate the bits stored during reverse iteration:
 
http://pastebin.com/VsvH3HdE
 
Juaquin must have made a mistake here. Or, I created another version
accidentally that works with real. I will ask him. I need to go right
now, I have fairly limited time to work on this.
 
Your question is very great; insightful indeed! I will get back to you
later on tonight, or tomorrow morning. Also, take a close look at these
two threads:
 
https://groups.google.com/forum/#!original/sci.crypt/mycXj0ViYaw/hVFJ3vE4BAAJ
 
https://groups.google.com/forum/#!original/sci.crypt/mycXj0ViYaw/lS28y_52BAAJ
 
All of the required math can be found here:
 
https://groups.google.com/d/topic/comp.lang.javascript/dgakiMzhgv0/discussion
 
Sorry, got to go now.
 
;^o
 
 
[...]
"Chris M. Thomasson" <invalid@invalid.invalid>: Jun 27 01:21PM -0700

On 6/26/2016 8:52 AM, Peter Fairbrother wrote:
> On 21/02/16 21:38, Chris M. Thomasson wrote:
>> Original idea by Juaquin Anderson in the comments of the
[...]
 
Read this as well:
 
https://plus.google.com/101799841244447089430/posts/1YKAJn1XKYd
Marcel Mueller <news.5.maazl@spamgourmet.org>: Jun 27 09:23PM +0200

On 26.06.16 17.19, Alf P. Steinbach wrote:
> switch (+f)
 
At least it looks more pretty.
 
 
Marcel
"Öö Tiib" <ootiib@hot.ee>: Jun 26 11:07PM -0700

On Sunday, 26 June 2016 12:10:44 UTC+3, J. Clarke wrote:
> > C++ and what is in C#.
 
> So what known software was written in C in 1968 and what does that fact
> tell us about the utility of C?
 
Nothing was written in C in 1968.
That does tell us that C had no utility in 1968.
Why you asked me to type those tautologies?
 
 
> Comparing a new language with an old language on the basis of "what was
> written in it" seems kind of silly.
 
14 years old programming language is not new.
"J. Clarke" <j.clarke.873638@gmail.com>: Jun 27 05:55AM -0400

In article <5b912432-f3d1-4b81-bb92-ccb6329f6242@googlegroups.com>,
ootiib@hot.ee says...
 
> Nothing was written in C in 1968.
> That does tell us that C had no utility in 1968.
> Why you asked me to type those tautologies?
 
Good, you got the point. Quantity of code written in a language may
reflect the age of the language more than it does the quality of it.
 
> > Comparing a new language with an old language on the basis of "what was
> > written in it" seems kind of silly.
 
> 14 years old programming language is not new.
 
Cobol is over 50. Fortran is over 60. APL is 52. C is 44. C++ is 33.
By that standard C# is very new. It's newer than Java and Python, to
name two other popular languages that I for one consider to be new.
"Öö Tiib" <ootiib@hot.ee>: Jun 27 04:33AM -0700

On Monday, 27 June 2016 12:56:10 UTC+3, J. Clarke wrote:
> > Why you asked me to type those tautologies?
 
> Good, you got the point. Quantity of code written in a language may
> reflect the age of the language more than it does the quality of it.
 
Example about nonexistence of programming language is hardly about
age of it.
 
> > > written in it" seems kind of silly.
 
> > 14 years old programming language is not new.
 
> Cobol is over 50. Fortran is over 60. APL is 52.
 
What known software is written in those, then? Or are those "too old"?
 
> C is 44. C++ is 33. By that standard C# is very new. It's newer than Java
> and Python, to name two other popular languages that I for one consider
> to be new.
 
So what your claim is? I have impression that you claim is that it is silly to
expect that at least something widely known has been written in 14 years
old programming language. The reason is that you for one consider it too
new for that. You seemingly even consider about 21 years old Java and
Python as new. For me tools of that age must be rather mature.
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:

Sunday, June 26, 2016

Digest for comp.lang.c++@googlegroups.com - 6 updates in 3 topics

Peter Fairbrother <peter@tsto.co.uk>: Jun 26 04:52PM +0100

On 21/02/16 21:38, Chris M. Thomasson wrote:
> choose a point in the n'th level set. The point can be chosen
> by taking a starting point just outside the circle delimiting
> the target set,
 
I don't get this bit. I am not a chaos theorist, and I do not understand
_exactly_ what is being proposed. Could you explain further?
 
Please try and be as precise as you can.
 
 
For example, what is the n-th level set? Is it the same thing as the
target set? (if so, please don't call it by two different names... )
 
I initially thought it was the set of points which remain less than some
value after n iterations (presumably of x -> x^2 + c) - or possibly that
set minus the set for n-1 iterations - but I don't see how that would be
delimited by a circle.
 
 
Can c be freely chosen from some large range?
 
 
> and applying inverse iteration, choosing roots
> by sign according to the bits in the sequence to be encoded.
 
Is that the actual encryption operation?
 
> until the point lands in the target set. The decoded message
> would have n bits determined by writing down the sign of the
> imaginary component of the escape orbit for each iteration.
 
 
This last part 5, decode by repeatedly iterating and taking the sign of
the imaginary parts as plaintext bits, seems like it would work.
 
but oh oh, what is an escape orbit? for each iteration?
 
If you/he means the imaginary part of x, then it seems to make some sense.
 
But what is the imaginary component of the escape orbit of an iteration?
 
 
 
I still don't see how you get the initial ciphertext.
 
Repeated reverse iterations and choosing which root to use, OK, I get
that. But how do you choose the starting point, given some
arbitrarily-chosen c?
 
 
 
 
Assuming you can do that, as a cipher it seems to have several
disadvantages: first, it is computationally expensive.
 
Second, the ciphertext is somewhat longer than the plaintext. For cipher
purposes, you need too be able to encrypt say 128 bits in a block -
there are some 64-bit block ciphers still around, but they are
deprecated, and some people say you need 256 bits in a block nowadays.
 
As a corollary to the above, the actual length needed for the ciphertext
is ... variable, which is a bit disconcerting.
 
Another corollary, you might have to check whether each block decrypts
correctly, so as to tell whether you have enough precision ..
 
So in general it isn't that useful as a cipher.
 
except ..
 
it *may* have a slightly interesting security property, ie a strong
proof of security.
 
This is kinda a holy grail for some cryptologists, and if I am right
about that, it may have some limited use.
 
 
 
> Sounds easy right?
 
Maybe if you are a chaos theorist ..
 
- Peter Fairbrother
 
ps ignore anything austinobyrne has to say - he is a well-known idiot.
 
> the fractal dimension of the Julia set, and the degree of
> imbalance of the contractivity in the tree traversal of the
> Julia set."
 
ps nope, that makes no sense to me either ..
Marcel Mueller <news.5.maazl@spamgourmet.org>: Jun 26 04:31PM +0200

When I use enums with flags an define the type safe bit operators I get
warning in switch statements when I have bit combinations in a case
constant. (case value not in enumerated type)
 
Basically the overloaded operators cause the argument to switch to be of
the enum type rather than int. And now the compiler (here gcc) does some
consistency checks.
It is just a warning and I can turn it off, but this disables another
sometimes useful warning for other enum types that not all enum values
of the switch are handled.
 
Is there anything else I can do except for casting to int at the switch
statement?
 
 
enum Flags
{ None = 0
, Val1 = 1
, Val2 = 2
//...
};
 
inline constexpr Flags operator|(Flags l, Flags r)
{ return (Flags)((int)l|r); }
// further operators
 
int main()
{
Flags f = Val1|Val2;
switch (f)
{default:
return 0;
case Val1:
return 1;
case Val2:
return 2;
case Val1|Val2: // Warning!
return 3;
}
}
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 26 05:19PM +0200

On 26.06.2016 16:31, Marcel Mueller wrote:
> When I use enums with flags an define the type safe bit operators I get
> warning in switch statements when I have bit combinations in a case
> constant. (case value not in enumerated type)
 
[snip]
> return 3;
> }
> }
 
enum Flags
{ None = 0
, Val1 = 1
, Val2 = 2
//...
};
 
inline constexpr Flags operator|(Flags l, Flags r)
{ return (Flags)((int)l|r); }
// further operators
 
int main()
{
Flags f = Val1|Val2;
switch (+f)
{default:
return 0;
case Val1:
return 1;
case Val2:
return 2;
case Val1|Val2: // Warning!
return 3;
}
}
 
 
Cheers & hth.,
 
- Alf
"J. Clarke" <j.clarke.873638@gmail.com>: Jun 26 05:10AM -0400

In article <fcdaa56d-59a0-4b61-925c-f31f55a89cf0@googlegroups.com>,
ootiib@hot.ee says...
 
> That is so silly. The tongue does not matter. What matters is what is
> expressed in it. So better compare what known software is written in
> C++ and what is in C#.
 
So what known software was written in C in 1968 and what does that fact
tell us about the utility of C?
 
Comparing a new language with an old language on the basis of "what was
written in it" seems kind of silly.
"J. Clarke" <j.clarke.873638@gmail.com>: Jun 26 05:34AM -0400

In article <nderds$g8i$1@news.xmission.com>,
legalize+jeeves@mail.xmission.com says...
 
> >Does there exist a list of operating systems/hardware that I can target
> >in C++?
 
> All of them.
 
All of them? Really? So tell us where to get a C++ compiler that
targets the Zuse Z4.

> >My office mate is arguing with me that C# is now more portable than C++,
> >because...mono. He is making me angry.
 
> Every other language sits on top of some layer that is either C or C++.
 
That would be news to Fortran, LISP, ALGOL, COBOL, RPG, APL, Simula,
SNOBOL, Speakeasy, BASIC, PL/I, and JOSS, among others.
 
C++ is highly portable and targets a great many systems, but don't
overstate the case.
"J. Clarke" <j.clarke.873638@gmail.com>: Jun 26 05:49AM -0400

In article <ndi9dc$1raf$2@gioia.aioe.org>, klammerj@NOSPAM.a1.net
says...
 
> I mean it's a nice marketing spin and all, but if the goal is
> portability (as they claim) but it'll only run on windowze,
> something has to be wrong, no?
 
Mono is a subset of dotNet and it doesn't "only run on Windows". You
can write C++ code that "only runs on Windows" you know, all you have to
do is access system services that are not present on other operating
systems.
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:

Saturday, June 25, 2016

Digest for comp.lang.c++@googlegroups.com - 2 updates in 1 topic

"Chris M. Thomasson" <invalid@invalid.invalid>: Jun 24 01:32PM -0700

On 6/24/2016 12:49 PM, Ramine wrote:
> On 6/24/2016 3:36 PM, Chris M. Thomasson wrote:
>> On 6/24/2016 9:51 AM, Ramine wrote:
[...]
>> Where is the C++ code for the (DLL_PCG_DENSE/SPASE.dll)'s?
 
> It's the Object Pascal code for the DENSE that you have to download from
> here:
 
NO! Please convert the Object Pascal code to C++, darn it!
 
;^o
"Chris M. Thomasson" <invalid@invalid.invalid>: Jun 24 01:57PM -0700

On 6/24/2016 1:40 PM, Ramine wrote:
> as you have noticed i have used Dynamic Link Libraries source codes
> compiled with FreePascal, and that's also a good way to speed the things
> for me.
 
That is fine. The problem is that you seemed to suggest that you have
already done the work wrt the content of the subject...
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:
Subscribe to: Posts (Atom)