Monday, July 1, 2019

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

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 01 01:38AM +0200

On 01.07.2019 01:16, G G wrote:
 
> double ( a_value ) or (double) a_value
 
> vs.
 
> static_cast<double>( a_value ) /* c++ 11 + */
 
The named casts have always been part of C++.
 
They're named because
 
* That makes the intent more clear.
* It's grep-able.
* It's more to write, which is a good thing for casts.
 
The two first notations, `double(x)` and `(double)x`, mean exactly the
same, but unlike the `static_cast` you don't know what that thing is
without inspecting `x`. It could be a `const_cast`, a `static_cast`, a
`reinterpret_cast` or a cast to inaccessible base, or a (restricted)
combination. When the code is maintained and `x` is changed, the unnamed
cast can drastically change meaning and introduce a bug.
 
Still, constructing a class type instance with one argument is
syntactically a cast of that argument, so one can't avoid the notation.
For that matter, constructing a class instance with any number of
arguments is syntactically a cast, but it gets absurd with 2 or more
arguments. I guess Stroustrup intended a kind of unification of
"conversion" expressions.
 
Cheers & hth.,
 
- Alf
Juha Nieminen <nospam@thanks.invalid>: Jul 01 07:38AM


> double ( a_value ) or (double) a_value
 
> vs.
 
> static_cast<double>( a_value ) /* c++ 11 + */
 
The problem with C-style casts (even with the C++ style use of
parentheses) is that, while it looks nice and neat (and almost
looks like a function call), it's way too strong and may lead
to mistakes, especially with aliased or custom types. That's
because a C style cast will cast pretty much *anything* to
pretty much anything else, no questions asked.
 
static_cast guards you against accidental casts between
incompatible types, which may catch programming mistakes at
the best possible stage of development.
 
Also, once you get used to static_cast, it actually helps reading
and understanding the code because it visually indicates where
a cast is being made, which with the "function call syntax" it may
not be as apparent (because it looks like a function call, not a
type cast).
Bonita Montero <Bonita.Montero@gmail.com>: Jul 01 02:40PM +0200

C++-style casts are superfluous child-proof locks in most cases.
And in many cases they're even syntactic sugar.
Melzzzzz <Melzzzzz@zzzzz.com>: Jul 01 12:45PM


> double ( a_value ) or (double) a_value
 
> vs.
 
> static_cast<double>( a_value ) /* c++ 11 + */
 
no that's 98
 
--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Melzzzzz <Melzzzzz@zzzzz.com>: Jul 01 12:46PM

> C++-style casts are superfluous child-proof locks in most cases.
> And in many cases they're even syntactic sugar.
No.
 
--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Bonita Montero <Bonita.Montero@gmail.com>: Jul 01 02:53PM +0200

>> C++-style casts are superfluous child-proof locks in most cases.
>> And in many cases they're even syntactic sugar.
 
> No.
 
No, sure.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jul 01 01:14PM

On Sun, 2019-06-30, G G wrote:
 
> double ( a_value ) or (double) a_value
 
> vs.
 
> static_cast<double>( a_value ) /* c++ 11 + */
 
Do you have a question, or do you want to make a statement about
something? And what is the smiley for -- is the whole posting a
joke?
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
G G <gdotone@gmail.com>: Jul 01 11:22AM -0700

No, reading two books. One book spent a great bit of time describing casting using double( a_value) type the other book just said static_cast<double>(a_value) was the way to cast. I was hoping someone would explain why the change and the reason for it. Both books I think are at least c++11
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jul 01 12:53PM -0700

On 7/1/2019 5:53 AM, Bonita Montero wrote:
>>> And in many cases they're even syntactic sugar.
 
>> No.
 
> No, sure.
 
There is a difference between static_cast and reinterpret_cast. No?
G G <gdotone@gmail.com>: Jul 01 01:55PM -0700

Oh yeah the smile. I'm a happy to actually be learning
Real Troll <real.troll@trolls.com>: Jun 30 08:45PM -0400

On 30/06/2019 22:09, Mr Flibble wrote:
 
> Why would we read it again
 
Because he told you so, dickhead!!!
 
In future if you don't like his posts then kill-file him and stop
replicating his post or his name. Some of us don't see his posts but
silly people like you not only reads them but also replicates them here
and and messes our normally fine set-ups!!.
 
I don't expect you to abide by this rule so I'm kill-filing you also so
that I don't have to read any of your crap here.
 
Real Troll Here with new agenda!!!!!!!!!!!!!!
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 01 05:04PM +0100

On 01/07/2019 01:45, Real Troll wrote:
 
> I don't expect you to abide by this rule so I'm kill-filing you also so
> that I don't have to read any of your crap here.
 
> Real Troll Here with new agenda!!!!!!!!!!!!!!
 
But I didn't replicate his post here, dickhead!!!
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into
snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who
doesn't believe in any God the most. Oh, no..wait.. that never happens." –
Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jul 01 12:55PM -0700

On 6/30/2019 5:45 PM, Real Troll wrote:
> On 30/06/2019 22:09, Mr Flibble wrote:
 
>> Why would we read it again
 
> Because he told you so, dickhead!!!
Sorry, but this made be bust out laughing. :^D
[...]
Bonita Montero <Bonita.Montero@gmail.com>: Jul 01 06:56AM +0200

> What's with all the `::std::`?  `std::` is fine. Your code is nearly as
> bad as Alf's.
 
::std:: is because of Stefan's compulsiveness.
Juha Nieminen <nospam@thanks.invalid>: Jul 01 07:30AM

> If it works, why "improve" it? strtok is perfectly legal C++.
 
Because strtok has known and acknowledged limitations which make it
unsuitable for many applications. Most prominently, it maintains
an internal singleton state, which means you can't strtok two strings
in alternation (not even if you do it inside one single thread.
Of course strtok is completely non-thread-safe and cannot be made
thread-safe even by using locking from the outside.)
 
There exist non-singleton implementations of strtok, where the
internal state is kept in a struct, but these are, so far, non-standard
library extensions.
scott@slp53.sl.home (Scott Lurndal): Jul 01 01:09PM

>> If it works, why "improve" it? strtok is perfectly legal C++.
 
>Because strtok has known and acknowledged limitations which make it
>unsuitable for many applications.
 
I'm well aware of strtok and its shortcomings.
 
However, my question stands. If it works already [in an application], why change it?
 
The impression I got was that the OP didn't think it was "C++" enough.
alexo <alelvb@inwind.it>: Jul 01 03:21PM +0200

Il 28/06/19 19:14, alexo ha scritto:
> is there a purely C++ function that behaves like the C strtok() ?
 
> thank you
 
> alessandro
 
I've seen that my asking teased some of you. So I public the code I
wrote for my parser. It may be appear simple, stupid or whatever, I ask
you your suggestions about.
Remember thet I'm not a professional programmer nor a student but just
an hobbyst C++ coder.
 
 
 
 
// it needs of a std::vector<string> named 'atoms'
 
 
// the parse_formula header is the following:
 
static void parse_formula(string& f, unsigned int mc_factor = 1);
 
// parse_formula implementation
// in a certain point of the code it calls itself using mc_factor
// to remember the multiplicative coefficient of the former
// parentheses analysis.
 
void WCalc::parse_formula(string& f, unsigned int mc_factor)
{
unsigned int number_of_atoms = 0;
 
string s {};
 
if(f.length() == 0 || f.length() > SIZE)
{
error = true;
return;
}
 
for(unsigned int i = 0; i < f.length(); i++) {
if(islower(f[i])) {
error = true;
break;
}
if(f.length() == 1 and isupper(f[i])) // single letter atom
{
s = f[i];
atoms.push_back(s);
s.clear();
number_of_atoms++;
coefficients.push_back(1 * mc_factor); // set atomic
coefficient to 1
break;
}
if(isupper(f[i]) and isupper(f[i + 1])) { // single atom
s = f[i];
atoms.push_back(s);
s.clear();
number_of_atoms++;
coefficients.push_back(1 * mc_factor); // set atomic
coefficient to 1
continue;
}
if(isupper(f[i]) and islower(f[i + 1])) { // two letters
atom...
if(islower(f[i + 2])) {
cout << "\nwrong input";
error = true;
break;
} else {
s = f[i];
s += f[i + 1];
atoms.push_back(s);
number_of_atoms++;
s.clear();
 
if(isdigit(f[i + 2])) { // ...and its atomic
coefficient
int ks = i + 2;
int ke = ks;
while(isdigit(f[ke])) {
ke++;
}
 
coefficients.push_back(atoi(f.substr(ks, ke -
ks).c_str()) * mc_factor);
 
i += ke - ks;
}
else
{
coefficients.push_back(1 * mc_factor); //
atomic coefficient 1
i += 1;
}
}
}
if(isupper(f[i]) and isdigit(f[i + 1])) { // one letter atom...
s = f[i];
atoms.push_back(s);
number_of_atoms++;
s.clear();
 
int ks = i + 1;
int ke = ks;
 
while(isdigit(f[ke])) { // ... and its atomic coefficient
ke++;
}
 
coefficients.push_back(atoi(f.substr(ks, ke -
ks).c_str()) * mc_factor);
 
i += ke - ks;
}
if(isupper(f[i]) and (f[i + 1] == '*')) { // if we reach
the crystallization molecules
s = f[i];
atoms.push_back(s);
s.clear();
number_of_atoms++;
coefficients.push_back(1 * mc_factor);
}
if(isupper(f[i]) and (f[i + 1] == '\0')) { // if we have
the last atom of the formula
s = f[i];
atoms.push_back(s);
s.clear();
number_of_atoms++;
coefficients.push_back(1 * mc_factor);
}
 
if(isupper(f[i]) and ((f[i + 1] == '(') || (f[i + 1] ==
'['))) {
s = f[i];
atoms.push_back(s);
s.clear();
number_of_atoms++;
coefficients.push_back(1 * mc_factor);
}
if(isupper(f[i]) and (f[i + 1] == ')' || f[i + 1] == ']') ) {
s = f[i];
atoms.push_back(s);
s.clear();
number_of_atoms++;
coefficients.push_back(1 * mc_factor);
continue;
}
if(ispunct(f[i]) and f[i] != '(' and f[i] != ')' and f[i]
!= '[' and f[i] != ']' and f[i] != '*') {
error = true;
break;
}
 
if(f[i] == '(') { // handle round parentheses
int k = i + 1;
int cpindex = i + 2;
int index = i + 2;
 
while(f[cpindex] != ')') {
cpindex++;
}
 
index = cpindex + 1;
 
while(isdigit(f[index])) {
index++;
}
 
s = f.substr(k, cpindex - k);
 
if(index > cpindex + 1) {
mc_factor *= atoi(f.substr(cpindex + 1, index -
cpindex).c_str());
}
else
{
mc_factor = 1;
}
 
i += index -k;
parse_formula(s, mc_factor);
mc_factor = 1;
}
 
if(f[i] == '[') { // handle square parentheses
int k = i + 1;
int csqpindex = i + 1;
int sqindex = i + 2;
 
while(f[csqpindex] != ']') {
csqpindex++;
}
 
sqindex = csqpindex + 1;
 
while(isdigit(f[sqindex])) {
sqindex++;
}
 
s = f.substr(k, csqpindex - k);
 
if(sqindex > csqpindex + 1) {
mc_factor = atoi(f.substr(csqpindex + 1, sqindex -
csqpindex).c_str());
}
else
{
mc_factor = 1;
}
 
i += sqindex - k;
parse_formula(s, mc_factor);
mc_factor = 1;
}
 
if(f[i] == '*') // crystallization molecules
{
int ks = i+1;
 
if(isupper(f[ks]))
{
mc_factor = 1;
s = f.substr(ks, strlen(f.c_str()) - ks);
parse_formula(s, mc_factor);
 
break;
}
 
int kc, kf, kp;
kc = kf = kp = i+1;
 
if(isdigit(f[kc]))
{
while(isdigit(f[kc]))
{
kc++;
kf++;
}
 
kf = kp = kc;
 
if(f[kp] == '(' or f[kp] == '[' )
{
kf = kp+1;
 
s = f.substr(kf, strlen(f.c_str()) - (kf+1));
mc_factor = atoi(f.substr(ks, kc - ks).c_str());
 
parse_formula(s, mc_factor);
 
break;
}
else
{
kf = kc;
 
s = f.substr(kf, - ks);
mc_factor = atoi(f.substr(ks, kc - ks).c_str());
 
parse_formula(s, mc_factor);
 
break;
}
}
}
}
}
James Kuyper <jameskuyper@alumni.caltech.edu>: Jul 01 09:45AM -0400

On 7/1/19 3:30 AM, Juha Nieminen wrote:
 
> There exist non-singleton implementations of strtok, where the
> internal state is kept in a struct, but these are, so far, non-standard
> library extensions.
 
strtok_s() is optional, but is fully specified in the C standard, with
that definition normatively cross-referenced by the C++ standard. I
don't see how you could label it non-standard.
Juha Nieminen <nospam@thanks.invalid>: Jul 01 07:26AM


> You're asking that the relevant library code be duplicated in each
> posting here.
 
> That would be idiotic, if you think about it.
 
This newsgroup is about standard C++. Unless the thread is about a
particular third-party library, keep all third-party libraries out
of the code, unless absolutely necessary.
 
Your pet personal library is *far* for necessary. It's completely
superfluous and only makes it harder for anybody to do anything
with any code you post, for no good reason.
 
Even if you have to repeat a few lines of code in more than one post,
so what? Who cares? Answers can share code, if they are relevant to
the topic at hand.
 
For some reason you are enamored with this pet personal library of
yours, which, frankly, feels lie what a very newbie programmer would
do. I also get the feeling that you, indeed, have a very naive notion
that if you keep using it in this newsgroup, it might get adopted and
popular. I highly doubt that will ever happen, so just stop it. It's
only annoying.
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: