Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Has anyone seen this?
353 views
Skip to first unread message
Robert Hutchings
Oct 19, 2014, 11:25:46 AM10/19/14
to
https://www.phy.duke.edu/~rgb/Beowulf/c++_interview/c++_interview.html
I guess it's a fake interview with Stroustrup, but I think it
illustrates the point....
I guess it's a fake interview with Stroustrup, but I think it
illustrates the point....
Öö Tiib
Oct 19, 2014, 12:03:33 PM10/19/14
to
hard to find but not because C++ is that hard. C++ is OK. Reason is
that those losers who can't code themselves out of paper bag in any
language all around just blog, joke and whine how bad C++ is.
Why? Take Java, take Python, take PHP, take C or take C# and go and
write something useful. Nah. Easier is to whine about C++.
Is there some major force on Earth that pushes you towards C++?
*NONE*. Microsoft pushes you to C#, Apple pushes you to Objective-C,
Google pushes you to Go, Oracle pushes you to Java. So why you
whine about C++? No one on Earth does want you to use it.
Expect the actual software users, who like how it runs smoothly.
For us it is OK, that is improving our salary of C++ programmers
and life is good. ;)
Robert Hutchings
Oct 19, 2014, 12:25:47 PM10/19/14
to
is the most powerful language ever created IMHO, and, yes, it can be
difficult, but that is not necessarily a bad thing :)
Jorgen Grahn
Oct 20, 2014, 2:07:03 AM10/20/14
to
On Sun, 2014-10-19, 嘱 Tiib wrote:
> On Sunday, 19 October 2014 18:25:46 UTC+3, Robert Hutchings wrote:
>> https://www.phy.duke.edu/~rgb/Beowulf/c++_interview/c++_interview.html
>>
>> I guess it's a fake interview with Stroustrup, but I think it
>> illustrates the point....
>
> Everybody have seen those jokes.
...
> On Sunday, 19 October 2014 18:25:46 UTC+3, Robert Hutchings wrote:
>> https://www.phy.duke.edu/~rgb/Beowulf/c++_interview/c++_interview.html
>>
>> I guess it's a fake interview with Stroustrup, but I think it
>> illustrates the point....
>
> Everybody have seen those jokes.
> Why? Take Java, take Python, take PHP, take C or take C# and go and
> write something useful. Nah. Easier is to whine about C++.
>
> Is there some major force on Earth that pushes you towards C++?
> *NONE*. Microsoft pushes you to C#, Apple pushes you to Objective-C,
> Google pushes you to Go, Oracle pushes you to Java. So why you
> whine about C++? No one on Earth does want you to use it.
20 years ago they did, and a lot of C programmers were forced to write
> write something useful. Nah. Easier is to whine about C++.
>
> Is there some major force on Earth that pushes you towards C++?
> *NONE*. Microsoft pushes you to C#, Apple pushes you to Objective-C,
> Google pushes you to Go, Oracle pushes you to Java. So why you
> whine about C++? No one on Earth does want you to use it.
bad C++ code. Why people (including some who were children at the
time) are still reacting to that, I don't know. It's a mystery.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Juha Nieminen
Oct 20, 2014, 9:18:58 AM10/20/14
to
Victor Bazarov
Oct 20, 2014, 9:19:43 AM10/20/14
to
On 10/20/2014 2:06 AM, Jorgen Grahn wrote:
> On Sun, 2014-10-19, 嘱 Tiib wrote:
>> [..] So why you
> On Sun, 2014-10-19, 嘱 Tiib wrote:
>> whine about C++? No one on Earth does want you to use it.
>
> 20 years ago they did, and a lot of C programmers were forced to write
> bad C++ code.
Are you in jest? Nobody was/is/will be *forced* to write anything.
>
> 20 years ago they did, and a lot of C programmers were forced to write
> bad C++ code.
They *choose* to do so because it is beneficial to *them*. In any
situation one always *chooses* to behave the way to one's own advantage.
> Why people (including some who were children at the
> time) are still reacting to that, I don't know. It's a mystery.
purpose, to gain some perceived advantage ("squeaky wheel gets the
grease"). If it's still a mystery to you, perhaps you just haven't
given it enough thought... Not that you should, mind you. There are
other, more interesting subjects to occupy one's thoughts that those, I
am sure.
The purpose of those who react to whining (the squeaking of the
proverbial wheel) is done to try to limit the redistribution of the
world grease unjustifiedly (based on the squeaking alone), since it's
often perceived that the world grease is of limited supply...
How's that?
>
> /Jorgen
>
V
--
I do not respond to top-posted replies, please don't ask
Drew Lawson
Oct 20, 2014, 1:37:12 PM10/20/14
to
In article <m2324v$76r$1...@dont-email.me>
20 years ago) my employer of the time decided that the 15 year old
C codebase that I worked in was to be C++ going forward.
And do you recall what the "C++ trainers" of 1994 were like? They
brought in a guy to train the team. He spent half his time telling
us that C sucked, and the other half demonstrating that he didn't
know C. I'm not clear just how much C++ he knew, as he wasn't the
best at explaining things. To his credit, he was good at identifying
the cash cow of the year.
A lot of bad C++ resulted.
--
|Drew Lawson | If you're not part of the solution |
| | you're part of the precipitate. |
Victor Bazarov <v.ba...@comcast.invalid> writes:
>On 10/20/2014 2:06 AM, Jorgen Grahn wrote:
>> On Sun, 2014-10-19, 嘱 Tiib wrote:
>>> [..] So why you
>>> whine about C++? No one on Earth does want you to use it.
>>
>> 20 years ago they did, and a lot of C programmers were forced to write
>> bad C++ code.
>
>Are you in jest? Nobody was/is/will be *forced* to write anything.
>They *choose* to do so because it is beneficial to *them*. In any
>situation one always *chooses* to behave the way to one's own advantage.
If you say so. I "chose" not to be unemployed when (almost exactly
>On 10/20/2014 2:06 AM, Jorgen Grahn wrote:
>> On Sun, 2014-10-19, 嘱 Tiib wrote:
>>> [..] So why you
>>> whine about C++? No one on Earth does want you to use it.
>>
>> 20 years ago they did, and a lot of C programmers were forced to write
>> bad C++ code.
>
>Are you in jest? Nobody was/is/will be *forced* to write anything.
>They *choose* to do so because it is beneficial to *them*. In any
>situation one always *chooses* to behave the way to one's own advantage.
20 years ago) my employer of the time decided that the 15 year old
C codebase that I worked in was to be C++ going forward.
And do you recall what the "C++ trainers" of 1994 were like? They
brought in a guy to train the team. He spent half his time telling
us that C sucked, and the other half demonstrating that he didn't
know C. I'm not clear just how much C++ he knew, as he wasn't the
best at explaining things. To his credit, he was good at identifying
the cash cow of the year.
A lot of bad C++ resulted.
--
|Drew Lawson | If you're not part of the solution |
| | you're part of the precipitate. |
Victor Bazarov
Oct 20, 2014, 2:01:33 PM10/20/14
to
knowledge of C for the low quality of the C++ code *you and your
co-workers* wrote. Did I get that right?
Robert Hutchings
Oct 20, 2014, 2:13:54 PM10/20/14
to
On 10/20/2014 12:37 PM, Drew Lawson wrote:
> In article <m2324v$76r$1...@dont-email.me>
> Victor Bazarov <v.ba...@comcast.invalid> writes:
>> On 10/20/2014 2:06 AM, Jorgen Grahn wrote:
> In article <m2324v$76r$1...@dont-email.me>
> Victor Bazarov <v.ba...@comcast.invalid> writes:
>> On 10/20/2014 2:06 AM, Jorgen Grahn wrote:
>>> On Sun, 2014-10-19, Öö Tiib wrote:
>>>> [..] So why you
>>>> whine about C++? No one on Earth does want you to use it.
>>>
>>> 20 years ago they did, and a lot of C programmers were forced to write
>>> bad C++ code.
>>
>> Are you in jest? Nobody was/is/will be *forced* to write anything.
>> They *choose* to do so because it is beneficial to *them*. In any
>> situation one always *chooses* to behave the way to one's own advantage.
>
> If you say so. I "chose" not to be unemployed when (almost exactly
> 20 years ago) my employer of the time decided that the 15 year old
> C codebase that I worked in was to be C++ going forward.
>
> And do you recall what the "C++ trainers" of 1994 were like? They
> brought in a guy to train the team. He spent half his time telling
> us that C sucked, and the other half demonstrating that he didn't
> know C. I'm not clear just how much C++ he knew, as he wasn't the
> best at explaining things. To his credit, he was good at identifying
> the cash cow of the year.
>
> A lot of bad C++ resulted.
>
The statement that "one always *chooses* to behave the way to one's own
>>>> [..] So why you
>>>> whine about C++? No one on Earth does want you to use it.
>>>
>>> 20 years ago they did, and a lot of C programmers were forced to write
>>> bad C++ code.
>>
>> Are you in jest? Nobody was/is/will be *forced* to write anything.
>> They *choose* to do so because it is beneficial to *them*. In any
>> situation one always *chooses* to behave the way to one's own advantage.
>
> If you say so. I "chose" not to be unemployed when (almost exactly
> 20 years ago) my employer of the time decided that the 15 year old
> C codebase that I worked in was to be C++ going forward.
>
> And do you recall what the "C++ trainers" of 1994 were like? They
> brought in a guy to train the team. He spent half his time telling
> us that C sucked, and the other half demonstrating that he didn't
> know C. I'm not clear just how much C++ he knew, as he wasn't the
> best at explaining things. To his credit, he was good at identifying
> the cash cow of the year.
>
> A lot of bad C++ resulted.
>
advantage" is bullshit. Many employers forced programmers to train
their foreign replacements or forfeit their retirement benefits. No one
"chose" to do that, except the managers who were compelled by the CIO
who was compelled by the CEO.
Victor Bazarov
Oct 20, 2014, 2:33:40 PM10/20/14
to
On 10/20/2014 2:20 PM, Martin Shobe wrote:
> No, he's blaming it on the trainer failing to teach C++ since he spent
> his time bad-mouthing a language he didn't know well. (Kind of like a
> number of posts about C++ I've seen recently here and in comp.lang.c.)
Right. In other words, his (and his coworkers') part in that process
was completely passive (i.e. no part at all). No C++ knowledge was
imparted on to them, and that's the teacher's fault. And those who
hired that teacher. And those who financed those who hired. And those
who also invented the accursed language.
> I'll leave to you to decide whether or not he was "forced" to write bad
> C++ code. But, it's pretty clear he was put in a situation where bad C++
> code was the likely result.
Sure. At no fault of theirs, as we have determined. I think I understand.
>
> Martin Shobe
> his time bad-mouthing a language he didn't know well. (Kind of like a
> number of posts about C++ I've seen recently here and in comp.lang.c.)
Right. In other words, his (and his coworkers') part in that process
was completely passive (i.e. no part at all). No C++ knowledge was
imparted on to them, and that's the teacher's fault. And those who
hired that teacher. And those who financed those who hired. And those
who also invented the accursed language.
> I'll leave to you to decide whether or not he was "forced" to write bad
> C++ code. But, it's pretty clear he was put in a situation where bad C++
> code was the likely result.
Sure. At no fault of theirs, as we have determined. I think I understand.
>
> Martin Shobe
Scott Lurndal
Oct 20, 2014, 2:41:04 PM10/20/14
to
>> If I try to unify your statements, you blame some guy's lack of
>> knowledge of C for the low quality of the C++ code *you and your
>> co-workers* wrote. Did I get that right?
>
>
>> knowledge of C for the low quality of the C++ code *you and your
>> co-workers* wrote. Did I get that right?
>
>
>I'll leave to you to decide whether or not he was "forced" to write bad
>C++ code. But, it's pretty clear he was put in a situation where bad C++
>code was the likely result.
What, exactly, is the definition of "Bad C++ code"?
>C++ code. But, it's pretty clear he was put in a situation where bad C++
>code was the likely result.
If it compiles and produces the desired result, isn't it good by definition?
Or is this more of the "must use every ridiculous feature of the
language from the most recent version of the language specification
in order to be 'good C++ code'" meme?
Now maintainability, perhaps, may be an issue (although I'd argue that
modern features like auto and lambdas hurt readability, if not
by extension maintainability).
There is absolutely nothing wrong with C with classes-style of usage
with respect to C++, and often it is quite desirable.
Scott Lurndal
Oct 20, 2014, 2:41:52 PM10/20/14
to
Robert Hutchings <rm.hut...@gmail.com> writes:
>The statement that "one always *chooses* to behave the way to one's own
>advantage" is bullshit. Many employers forced programmers to train
>their foreign replacements or forfeit their retirement benefits. No one
>"chose" to do that, except the managers who were compelled by the CIO
>who was compelled by the CEO.
Surely you have citations for this? Other than anecdotal statements of
>The statement that "one always *chooses* to behave the way to one's own
>advantage" is bullshit. Many employers forced programmers to train
>their foreign replacements or forfeit their retirement benefits. No one
>"chose" to do that, except the managers who were compelled by the CIO
>who was compelled by the CEO.
unreliable veracity?
Robert Hutchings
Oct 20, 2014, 2:43:36 PM10/20/14
to
could I give?
Robert Hutchings
Oct 20, 2014, 2:44:57 PM10/20/14
to
On 10/20/2014 1:41 PM, Scott Lurndal wrote:
Scott Lurndal
Oct 20, 2014, 3:03:23 PM10/20/14
to
2) One swallow doesn't make a summer.
Robert Hutchings
Oct 20, 2014, 3:08:48 PM10/20/14
to
the USA in the 2000's and continues today. Why would anyone deny this?
Robert Hutchings
Oct 20, 2014, 3:10:29 PM10/20/14
to
Robert Hutchings
Oct 20, 2014, 3:11:15 PM10/20/14
to
Robert Hutchings
Oct 20, 2014, 3:13:03 PM10/20/14
to
Robert Hutchings
Oct 20, 2014, 3:13:40 PM10/20/14
to
Ian Collins
Oct 20, 2014, 3:50:06 PM10/20/14
to
protected.
--
Ian Collins
Öö Tiib
Oct 20, 2014, 4:00:45 PM10/20/14
to
On Monday, 20 October 2014 21:41:04 UTC+3, Scott Lurndal wrote:
> Martin Shobe <martin...@yahoo.com> writes:
> >On 10/20/2014 1:01 PM, Victor Bazarov wrote:
>
> >> If I try to unify your statements, you blame some guy's lack of
> >> knowledge of C for the low quality of the C++ code *you and your
> >> co-workers* wrote. Did I get that right?
> >
> >
> >I'll leave to you to decide whether or not he was "forced" to write bad
> >C++ code. But, it's pretty clear he was put in a situation where bad C++
> >code was the likely result.
>
> What, exactly, is the definition of "Bad C++ code"?
Particular "badness" is not specific to C++ (or even compiler
> Martin Shobe <martin...@yahoo.com> writes:
> >On 10/20/2014 1:01 PM, Victor Bazarov wrote:
>
> >> If I try to unify your statements, you blame some guy's lack of
> >> knowledge of C for the low quality of the C++ code *you and your
> >> co-workers* wrote. Did I get that right?
> >
> >
> >I'll leave to you to decide whether or not he was "forced" to write bad
> >C++ code. But, it's pretty clear he was put in a situation where bad C++
> >code was the likely result.
>
> What, exactly, is the definition of "Bad C++ code"?
programming). It happens almost always when some unfamiliar innovation
is imposed from above by authorities to actual workers. Authorities
who bought some buzzwords actually do not even know the details involved.
When Peter the Great introduced potatoes to Russia then not all
went immediately well. According to the Great Encyclopedia of Cyril
and Methodius, at first Russians thought that the edible part of
the plant was the fruit growing on the potato bush after it
blossomed, rather than the root growing underground.
Apparently even Catherine served the wrong fruit of the potato
plant to her husband Peter the Great after he gave her the
"earthly apples" as a gift. Nothing to talk of poor illiterate
serfs. Hapless potato growers boiled the fruits and tried to eat
them with sugar, but the taste was still so awful that they
gave up on it. However ... Emperors orders, nothing to do.
Some time passed and potato indeed became an important staple
of Russian diet and it has saved many Russians from hunger during
next centuries. Nothing so drastic happened with that "bad" C++. :D
Christopher Pisz
Oct 20, 2014, 4:20:31 PM10/20/14
to
On 10/20/2014 1:40 PM, Scott Lurndal wrote:
> Martin Shobe <martin...@yahoo.com> writes:
>> On 10/20/2014 1:01 PM, Victor Bazarov wrote:
>
>>> If I try to unify your statements, you blame some guy's lack of
>>> knowledge of C for the low quality of the C++ code *you and your
>>> co-workers* wrote. Did I get that right?
>>
>
>>
>> I'll leave to you to decide whether or not he was "forced" to write bad
>> C++ code. But, it's pretty clear he was put in a situation where bad C++
>> code was the likely result.
>
> What, exactly, is the definition of "Bad C++ code"?
Spoken like a true C developer. If it works it's good. Bah!
> Martin Shobe <martin...@yahoo.com> writes:
>> On 10/20/2014 1:01 PM, Victor Bazarov wrote:
>
>>> If I try to unify your statements, you blame some guy's lack of
>>> knowledge of C for the low quality of the C++ code *you and your
>>> co-workers* wrote. Did I get that right?
>>
>
>>
>> I'll leave to you to decide whether or not he was "forced" to write bad
>> C++ code. But, it's pretty clear he was put in a situation where bad C++
>> code was the likely result.
>
> What, exactly, is the definition of "Bad C++ code"?
No it isn't. Not even close.
Can it be modified easily? Can additional features be made? Can Joe Bob
off the street come in and understand it when it comes time? Can your
boss whiteboard the architecture and be correct? Do we have to maintain
our own custom implementations of things others are already maintaining
for us?
>
> If it compiles and produces the desired result, isn't it good by definition?
>
> Or is this more of the "must use every ridiculous feature of the
> language from the most recent version of the language specification
> in order to be 'good C++ code'" meme?
>
> Now maintainability, perhaps, may be an issue (although I'd argue that
> modern features like auto and lambdas hurt readability, if not
> by extension maintainability).
>
> There is absolutely nothing wrong with C with classes-style of usage
> with respect to C++, and often it is quite desirable.
>
Öö Tiib
Oct 20, 2014, 4:21:18 PM10/20/14
to
it has something to do with that US is one of few countries that has
not ratified the International Covenant on Economic, Social and
Cultural Rights of humans?
Robert Hutchings
Oct 20, 2014, 4:25:49 PM10/20/14
to
happening! But, unfortunately, it WAS happening. Maybe not quite as
much NOW, I hope....
David Harmon
Oct 20, 2014, 11:45:03 PM10/20/14
to
On Mon, 20 Oct 2014 13:18:47 +0000 (UTC) in comp.lang.c++, Juha
Nieminen <nos...@thanks.invalid> wrote,
Nieminen <nos...@thanks.invalid> wrote,
>Robert Hutchings <rm.hut...@gmail.com> wrote:
>> https://www.phy.duke.edu/~rgb/Beowulf/c++_interview/c++_interview.html
>>
>> I guess it's a fake interview with Stroustrup, but I think it
>> illustrates the point....
>
>What point?
That lying liars will always lie.
>> https://www.phy.duke.edu/~rgb/Beowulf/c++_interview/c++_interview.html
>>
>> I guess it's a fake interview with Stroustrup, but I think it
>> illustrates the point....
>
>What point?
Scott Lurndal
Oct 21, 2014, 10:00:25 AM10/21/14
to
Christopher Pisz <nos...@notanaddress.com> writes:
>On 10/20/2014 1:40 PM, Scott Lurndal wrote:
>> Martin Shobe <martin...@yahoo.com> writes:
>>> On 10/20/2014 1:01 PM, Victor Bazarov wrote:
>>
>>>> If I try to unify your statements, you blame some guy's lack of
>>>> knowledge of C for the low quality of the C++ code *you and your
>>>> co-workers* wrote. Did I get that right?
>>>
>>
>>>
>>> I'll leave to you to decide whether or not he was "forced" to write bad
>>> C++ code. But, it's pretty clear he was put in a situation where bad C++
>>> code was the likely result.
>>
>> What, exactly, is the definition of "Bad C++ code"?
>
>Spoken like a true C developer. If it works it's good. Bah!
>No it isn't. Not even close.
Get of your high horse and answer the question. Define bad C++ code.
>On 10/20/2014 1:40 PM, Scott Lurndal wrote:
>> Martin Shobe <martin...@yahoo.com> writes:
>>> On 10/20/2014 1:01 PM, Victor Bazarov wrote:
>>
>>>> If I try to unify your statements, you blame some guy's lack of
>>>> knowledge of C for the low quality of the C++ code *you and your
>>>> co-workers* wrote. Did I get that right?
>>>
>>
>>>
>>> I'll leave to you to decide whether or not he was "forced" to write bad
>>> C++ code. But, it's pretty clear he was put in a situation where bad C++
>>> code was the likely result.
>>
>> What, exactly, is the definition of "Bad C++ code"?
>
>Spoken like a true C developer. If it works it's good. Bah!
>No it isn't. Not even close.
>
>Can it be modified easily? Can additional features be made? Can Joe Bob
>off the street come in and understand it when it comes time? Can your
>boss whiteboard the architecture and be correct? Do we have to maintain
>our own custom implementations of things others are already maintaining
>for us?
for every programming language (even assembler).
>> There is absolutely nothing wrong with C with classes-style of usage
>> with respect to C++, and often it is quite desirable.
>>
>
>Desirable by whom?
Operating systems, Hypervisors, Embedded code are classic examples.
Scott Lurndal
Oct 21, 2014, 10:01:18 AM10/21/14
to
Robert Hutchings <rm.hut...@gmail.com> writes:
Having been in the industry, in the US, for more than 30 years, I've
not see this. Note that this is also anecdotal information.
not see this. Note that this is also anecdotal information.
Robert Hutchings
Oct 21, 2014, 10:23:40 AM10/21/14
to
would have expected better from a C++ programmer.
Robert Hutchings
Oct 21, 2014, 10:29:40 AM10/21/14
to
Robert Hutchings
Oct 21, 2014, 10:31:20 AM10/21/14
to
Robert Hutchings
Oct 21, 2014, 10:32:20 AM10/21/14
to
Scott Lurndal
Oct 21, 2014, 10:35:00 AM10/21/14
to
Robert Hutchings <rm.hut...@gmail.com> writes:
>On 10/21/2014 9:01 AM, Scott Lurndal wrote:
>> Robert Hutchings <rm.hut...@gmail.com> writes:
>On 10/21/2014 9:01 AM, Scott Lurndal wrote:
>> Robert Hutchings <rm.hut...@gmail.com> writes:
"Plonk"
Drew Lawson
Oct 21, 2014, 10:35:24 AM10/21/14
to
In article <m23ile$2q8$1...@dont-email.me>
>>>> bad C++ code.
>>>
choose to move to C++ because they see the wonderfulness of it.
I simply illustrated that some people (me and the ~20 other developers
on that project) were subject to job pressure (you can, and probably
will, wordsmith whether that is "force") to move to C++.
Since there were poor training issues, the results also weer poor.
That is a separate issue.
But, yes, if management takes a development team, tells them to
switch to an unfamiliar language, *and* maintains that deadlines
are not changing, I would expect poor results. In fact, I would
be amazed if the resulting code was good.
--
Drew Lawson | Savage bed foot-warmer
| of purest feline ancestry
| Look out little furry folk
| it's the all-night working cat
Victor Bazarov <v.ba...@comcast.invalid> writes:
>On 10/20/2014 1:37 PM, Drew Lawson wrote:
>> In article <m2324v$76r$1...@dont-email.me>
>> Victor Bazarov <v.ba...@comcast.invalid> writes:
>>> On 10/20/2014 2:06 AM, Jorgen Grahn wrote:
>>>> On Sun, 2014-10-19, 嘱 Tiib wrote:
>>>>> [..] So why you
>>>>> whine about C++? No one on Earth does want you to use it.
>>>>
>>>> 20 years ago they did, and a lot of C programmers were forced to write
>On 10/20/2014 1:37 PM, Drew Lawson wrote:
>> In article <m2324v$76r$1...@dont-email.me>
>> Victor Bazarov <v.ba...@comcast.invalid> writes:
>>> On 10/20/2014 2:06 AM, Jorgen Grahn wrote:
>>>> On Sun, 2014-10-19, 嘱 Tiib wrote:
>>>>> [..] So why you
>>>>> whine about C++? No one on Earth does want you to use it.
>>>>
>>>> bad C++ code.
>>>
>>> Are you in jest? Nobody was/is/will be *forced* to write anything.
>>> They *choose* to do so because it is beneficial to *them*. In any
>>> situation one always *chooses* to behave the way to one's own advantage.
>>
>> If you say so. I "chose" not to be unemployed when (almost exactly
>> 20 years ago) my employer of the time decided that the 15 year old
>> C codebase that I worked in was to be C++ going forward.
>>
>> And do you recall what the "C++ trainers" of 1994 were like? They
>> brought in a guy to train the team. He spent half his time telling
>> us that C sucked, and the other half demonstrating that he didn't
>> know C. I'm not clear just how much C++ he knew, as he wasn't the
>> best at explaining things. To his credit, he was good at identifying
>> the cash cow of the year.
>>
>> A lot of bad C++ resulted.
>
>>> They *choose* to do so because it is beneficial to *them*. In any
>>> situation one always *chooses* to behave the way to one's own advantage.
>>
>> If you say so. I "chose" not to be unemployed when (almost exactly
>> 20 years ago) my employer of the time decided that the 15 year old
>> C codebase that I worked in was to be C++ going forward.
>>
>> And do you recall what the "C++ trainers" of 1994 were like? They
>> brought in a guy to train the team. He spent half his time telling
>> us that C sucked, and the other half demonstrating that he didn't
>> know C. I'm not clear just how much C++ he knew, as he wasn't the
>> best at explaining things. To his credit, he was good at identifying
>> the cash cow of the year.
>>
>> A lot of bad C++ resulted.
>
>If I try to unify your statements, you blame some guy's lack of
>knowledge of C for the low quality of the C++ code *you and your
>co-workers* wrote. Did I get that right?
You asserted that no one was forced to move to C++. People just
>knowledge of C for the low quality of the C++ code *you and your
>co-workers* wrote. Did I get that right?
choose to move to C++ because they see the wonderfulness of it.
I simply illustrated that some people (me and the ~20 other developers
on that project) were subject to job pressure (you can, and probably
will, wordsmith whether that is "force") to move to C++.
Since there were poor training issues, the results also weer poor.
That is a separate issue.
But, yes, if management takes a development team, tells them to
switch to an unfamiliar language, *and* maintains that deadlines
are not changing, I would expect poor results. In fact, I would
be amazed if the resulting code was good.
--
Drew Lawson | Savage bed foot-warmer
| of purest feline ancestry
| Look out little furry folk
| it's the all-night working cat
Christopher Pisz
Oct 21, 2014, 12:21:01 PM10/21/14
to
On 10/21/2014 9:00 AM, Scott Lurndal wrote:
> Christopher Pisz <nos...@notanaddress.com> writes:
>> On 10/20/2014 1:40 PM, Scott Lurndal wrote:
>>> Martin Shobe <martin...@yahoo.com> writes:
>>>> On 10/20/2014 1:01 PM, Victor Bazarov wrote:
SNIP
> Christopher Pisz <nos...@notanaddress.com> writes:
>> On 10/20/2014 1:40 PM, Scott Lurndal wrote:
>>> Martin Shobe <martin...@yahoo.com> writes:
>>>> On 10/20/2014 1:01 PM, Victor Bazarov wrote:
> Anyone who sees C++ as a tool, not as a religion.
>
It's more a matter of seeing C as a cult of relic programmers whom have
>
twisted values built into them from years of programming with 4k of
memory, that do not apply anymore, and are out to ruin C++ projects,
because hiring companies insist on hiring "C++/C" programmers, of which
there is no such thing.
I have never ever ever worked on a project with a C programmer that
wasn't responsible for more than 80% of the bugs being tracked. Whom
didn't argue until veins popped out of their forehead about things like
how to format strings, file reading and writing, using globals all over
the friggin place "because its easier', ignoring the initialization
fiasco, making retarded interfaces that take string arguments and then
parsing them using lucky charms encoder rings to get real arguments and
call other functions and on and on and on.
My response was to your statement, "If it works, then it is good code",
for which you should be shot. And the tie in to "spoken like a true C
programmer" is because that statement has been said in so many arguments
in the past by the very C programmers of which I speak.
I hardly see C++ as a religion, and I don't even see anything wrong with
C itself in certain settings (real low level and small projects), but
the mentality from which your statement is derived is what I take issue
with. It makes my job suck, plain and simple.
Scott Lurndal
Oct 21, 2014, 2:00:25 PM10/21/14
to
Christopher Pisz <nos...@notanaddress.com> writes:
>On 10/21/2014 9:00 AM, Scott Lurndal wrote:
>> Christopher Pisz <nos...@notanaddress.com> writes:
>>> On 10/20/2014 1:40 PM, Scott Lurndal wrote:
>>>> Martin Shobe <martin...@yahoo.com> writes:
>>>>> On 10/20/2014 1:01 PM, Victor Bazarov wrote:
>SNIP
>> Anyone who sees C++ as a tool, not as a religion.
>>
>
>It's more a matter of seeing C as a cult of relic programmers whom have
>twisted values built into them from years of programming with 4k of
>memory, that do not apply anymore, and are out to ruin C++ projects,
>because hiring companies insist on hiring "C++/C" programmers, of which
>there is no such thing.
What imaginary world do you live in?
>On 10/21/2014 9:00 AM, Scott Lurndal wrote:
>> Christopher Pisz <nos...@notanaddress.com> writes:
>>> On 10/20/2014 1:40 PM, Scott Lurndal wrote:
>>>> Martin Shobe <martin...@yahoo.com> writes:
>>>>> On 10/20/2014 1:01 PM, Victor Bazarov wrote:
>SNIP
>> Anyone who sees C++ as a tool, not as a religion.
>>
>
>It's more a matter of seeing C as a cult of relic programmers whom have
>twisted values built into them from years of programming with 4k of
>memory, that do not apply anymore, and are out to ruin C++ projects,
>because hiring companies insist on hiring "C++/C" programmers, of which
>there is no such thing.
Christopher Pisz
Oct 21, 2014, 3:10:31 PM10/21/14
to
Nobody
Oct 21, 2014, 10:29:44 PM10/21/14
to
On Sun, 19 Oct 2014 11:25:33 -0500, Robert Hutchings wrote:
> I tend to agree with you, and Bjarne never REALLY said any of that. C++
> is the most powerful language ever created IMHO, and, yes, it can be
> difficult, but that is not necessarily a bad thing :)
Combining those two, one thing Bjarne *did* actually say was:
"C makes it easy to shoot yourself in the foot; C++ makes it harder, but
when you do it blows your whole leg off"
> I tend to agree with you, and Bjarne never REALLY said any of that. C++
> is the most powerful language ever created IMHO, and, yes, it can be
> difficult, but that is not necessarily a bad thing :)
Combining those two, one thing Bjarne *did* actually say was:
"C makes it easy to shoot yourself in the foot; C++ makes it harder, but
when you do it blows your whole leg off"
Nobody
Oct 21, 2014, 10:36:48 PM10/21/14
to
On Sun, 19 Oct 2014 09:03:22 -0700, Öö Tiib wrote:
> Is there some major force on Earth that pushes you towards C++?
> *NONE*. Microsoft pushes you to C#,
Er, not really. Microsoft pushes people who might otherwise use Java
towards C#. Microsoft pushes former VB programmers towards C#.
But for people who are actually likely to be productive in C++, that's
where all of their "real software" APIs remain focused. They're not going
to want Windows software to run at half the speed of comparable OSX or
Linux offerings. They're certainly not going to want Xbox games to run at
half the speed of the PlayStation version.
> Is there some major force on Earth that pushes you towards C++?
> *NONE*. Microsoft pushes you to C#,
Er, not really. Microsoft pushes people who might otherwise use Java
towards C#. Microsoft pushes former VB programmers towards C#.
But for people who are actually likely to be productive in C++, that's
where all of their "real software" APIs remain focused. They're not going
to want Windows software to run at half the speed of comparable OSX or
Linux offerings. They're certainly not going to want Xbox games to run at
half the speed of the PlayStation version.
David Brown
Oct 22, 2014, 4:22:04 AM10/22/14
to
On 21/10/14 20:00, Scott Lurndal wrote:
> Christopher Pisz <nos...@notanaddress.com> writes:
>> On 10/21/2014 9:00 AM, Scott Lurndal wrote:
>>> Christopher Pisz <nos...@notanaddress.com> writes:
>>>> On 10/20/2014 1:40 PM, Scott Lurndal wrote:
>>>>> Martin Shobe <martin...@yahoo.com> writes:
>>>>>> On 10/20/2014 1:01 PM, Victor Bazarov wrote:
>> SNIP
>>> Anyone who sees C++ as a tool, not as a religion.
>>>
>>
>> It's more a matter of seeing C as a cult of relic programmers whom have
>> twisted values built into them from years of programming with 4k of
>> memory, that do not apply anymore, and are out to ruin C++ projects,
>> because hiring companies insist on hiring "C++/C" programmers, of which
>> there is no such thing.
>
> What imaginary world do you live in?
>
I expect his point is that there is no such language as C/C++ or C++/C.
> Christopher Pisz <nos...@notanaddress.com> writes:
>> On 10/21/2014 9:00 AM, Scott Lurndal wrote:
>>> Christopher Pisz <nos...@notanaddress.com> writes:
>>>> On 10/20/2014 1:40 PM, Scott Lurndal wrote:
>>>>> Martin Shobe <martin...@yahoo.com> writes:
>>>>>> On 10/20/2014 1:01 PM, Victor Bazarov wrote:
>> SNIP
>>> Anyone who sees C++ as a tool, not as a religion.
>>>
>>
>> It's more a matter of seeing C as a cult of relic programmers whom have
>> twisted values built into them from years of programming with 4k of
>> memory, that do not apply anymore, and are out to ruin C++ projects,
>> because hiring companies insist on hiring "C++/C" programmers, of which
>> there is no such thing.
>
> What imaginary world do you live in?
>
A good C++ programmer will not necessarily be good at working with C
code, and vice versa - programmers will usually specialise in one of the
languages. Of course it is possible to be good at both - but then you
are a "C and C++ programmer", not a "C/C++ programmer".
Scott Lurndal
Oct 22, 2014, 12:31:47 PM10/22/14
to
Christopher Pisz
Oct 22, 2014, 12:36:08 PM10/22/14
to
different idea of what "good" is and it is often incorrect, because the
definition has changed quite a bit.
The quote that started this subthread is a perfect example.
David Brown
Oct 22, 2014, 5:32:41 PM10/22/14
to
programmer" (etc.) rather than "/good/ C++ programmer".
Öö Tiib
Oct 22, 2014, 8:03:41 PM10/22/14
to
*all* programmers towards C#. The only reason of making things like
that "managed" C++/CLI vomit can be desire to discredit C++.
Nobody
Oct 22, 2014, 10:40:51 PM10/22/14
to
On Wed, 22 Oct 2014 17:03:24 -0700, Öö Tiib wrote:
> I do not know what Microsoft wants. I only see what it does. It pushes
> *all* programmers towards C#. The only reason of making things like
> that "managed" C++/CLI vomit can be desire to discredit C++.
Not even close. AFAICT, "managed C++" is meant primarily to expand the CLI
> I do not know what Microsoft wants. I only see what it does. It pushes
> *all* programmers towards C#. The only reason of making things like
> that "managed" C++/CLI vomit can be desire to discredit C++.
ecosystem to improve its competitiveness relative to Java.
It's all about covering bases, not keeping all eggs in one basket, etc.
Microsoft isn't expecting C++ to disappear or even trying to make that
happen. They just have many "plan B"s.
Daniel
Oct 22, 2014, 11:04:56 PM10/22/14
to
On Wednesday, October 22, 2014 8:03:41 PM UTC-4, Öö Tiib wrote:
> I do not know what Microsoft wants. I only see what it does. It pushes
> *all* programmers towards C#. The only reason of making things like
> that "managed" C++/CLI vomit can be desire to discredit C++.
On the contrary, what C++/CLI does is it allows the functionality of libraries written in C or Standard C++ to be exposed to the .Net family of languages, in particular, to C#. It's hard for me to see why anybody who cares about Standard C++ would find that unwelcome.
> I do not know what Microsoft wants. I only see what it does. It pushes
> *all* programmers towards C#. The only reason of making things like
> that "managed" C++/CLI vomit can be desire to discredit C++.
Best regards,
Daniel
woodb...@gmail.com
Oct 23, 2014, 1:12:56 AM10/23/14
to
https://www.youtube.com/watch?v=fHNmRkzxHWs
Chandler Carruth tells why he has a low opinion of
::std::map and ::std::deque. It was refreshing to hear
his views on these matters. I've tried to warn others
of the problems with ::std::map, but am not sure how
many have listened. I sometimes use ::boost::intrusive
containers as an alternative to ::std::map.
Brian
Ebenezer Enterprises - Unless the L-rd builds the house,
they labor in vain that build it. Psalms 127:1
http://webEbenezer.net
Christopher Pisz
Oct 23, 2014, 12:33:18 PM10/23/14
to
On 10/23/2014 12:12 AM, woodb...@gmail.com wrote:
> On Wednesday, October 22, 2014 10:04:56 PM UTC-5, Daniel wrote:
> On Wednesday, October 22, 2014 10:04:56 PM UTC-5, Daniel wrote:
>> On Wednesday, October 22, 2014 8:03:41 PM UTC-4, 嘱 Tiib wrote:
>>
>>> I do not know what Microsoft wants. I only see what it does. It pushes
>>> *all* programmers towards C#. The only reason of making things like
>>> that "managed" C++/CLI vomit can be desire to discredit C++.
>>
>> On the contrary, what C++/CLI does is it allows the functionality of libraries written in C or Standard C++ to be exposed to the .Net family of languages, in particular, to C#. It's hard for me to see why anybody who cares about Standard C++ would find that unwelcome.
>
> I care about C++. In this talk
>
> https://www.youtube.com/watch?v=fHNmRkzxHWs
>
> Chandler Carruth tells why he has a low opinion of
> ::std::map and ::std::deque. It was refreshing to hear
> his views on these matters. I've tried to warn others
> of the problems with ::std::map, but am not sure how
> many have listened. I sometimes use ::boost::intrusive
> containers as an alternative to ::std::map.
>
> Brian
> Ebenezer Enterprises - Unless the L-rd builds the house,
> they labor in vain that build it. Psalms 127:1
>
> http://webEbenezer.net
>
>
>
This is an interesting video. Coworker raised a point though. If you're
>>
>>> I do not know what Microsoft wants. I only see what it does. It pushes
>>> *all* programmers towards C#. The only reason of making things like
>>> that "managed" C++/CLI vomit can be desire to discredit C++.
>>
>> On the contrary, what C++/CLI does is it allows the functionality of libraries written in C or Standard C++ to be exposed to the .Net family of languages, in particular, to C#. It's hard for me to see why anybody who cares about Standard C++ would find that unwelcome.
>
> I care about C++. In this talk
>
> https://www.youtube.com/watch?v=fHNmRkzxHWs
>
> Chandler Carruth tells why he has a low opinion of
> ::std::map and ::std::deque. It was refreshing to hear
> his views on these matters. I've tried to warn others
> of the problems with ::std::map, but am not sure how
> many have listened. I sometimes use ::boost::intrusive
> containers as an alternative to ::std::map.
>
> Brian
> Ebenezer Enterprises - Unless the L-rd builds the house,
> they labor in vain that build it. Psalms 127:1
>
> http://webEbenezer.net
>
>
>
on an every day desktop system where 100s of processes are running, what
are the chances you are ever going to be in L1 or L2 anyway unless your
process has the highest priority?
His advice to _never_ use a linked list is a little hard to swallow. If
I am constantly inserting and don't know before hand how much memory I
need, I find it hard to believe that I could get better performance
using a vector, since the whole vector has to move because of its
guarantee to be contiguous.
I'd be interested in seeing some test code to profile that show results
that conflict with the way we usually think.
Bo Persson
Oct 23, 2014, 1:01:59 PM10/23/14
to
On 2014-10-23 18:33, Christopher Pisz wrote:
> On 10/23/2014 12:12 AM, woodb...@gmail.com wrote:
>> On Wednesday, October 22, 2014 10:04:56 PM UTC-5, Daniel wrote:
> On 10/23/2014 12:12 AM, woodb...@gmail.com wrote:
>> On Wednesday, October 22, 2014 10:04:56 PM UTC-5, Daniel wrote:
>>> On Wednesday, October 22, 2014 8:03:41 PM UTC-4, Öö Tiib wrote:
>>>
>>>> I do not know what Microsoft wants. I only see what it does. It pushes
>>>> *all* programmers towards C#. The only reason of making things like
>>>> that "managed" C++/CLI vomit can be desire to discredit C++.
>>>
>>> On the contrary, what C++/CLI does is it allows the functionality of
>>> libraries written in C or Standard C++ to be exposed to the .Net
>>> family of languages, in particular, to C#. It's hard for me to see
>>> why anybody who cares about Standard C++ would find that unwelcome.
>>
>> I care about C++. In this talk
>>
>> https://www.youtube.com/watch?v=fHNmRkzxHWs
>>
>> Chandler Carruth tells why he has a low opinion of
>> ::std::map and ::std::deque. It was refreshing to hear
>> his views on these matters. I've tried to warn others
>> of the problems with ::std::map, but am not sure how
>> many have listened. I sometimes use ::boost::intrusive
>> containers as an alternative to ::std::map.
>>
>>
>>
>
>>>
>>>> I do not know what Microsoft wants. I only see what it does. It pushes
>>>> *all* programmers towards C#. The only reason of making things like
>>>> that "managed" C++/CLI vomit can be desire to discredit C++.
>>>
>>> On the contrary, what C++/CLI does is it allows the functionality of
>>> libraries written in C or Standard C++ to be exposed to the .Net
>>> family of languages, in particular, to C#. It's hard for me to see
>>> why anybody who cares about Standard C++ would find that unwelcome.
>>
>> I care about C++. In this talk
>>
>> https://www.youtube.com/watch?v=fHNmRkzxHWs
>>
>> Chandler Carruth tells why he has a low opinion of
>> ::std::map and ::std::deque. It was refreshing to hear
>> his views on these matters. I've tried to warn others
>> of the problems with ::std::map, but am not sure how
>> many have listened. I sometimes use ::boost::intrusive
>> containers as an alternative to ::std::map.
>>
>>
>>
>
> This is an interesting video. Coworker raised a point though. If you're
> on an every day desktop system where 100s of processes are running, what
> are the chances you are ever going to be in L1 or L2 anyway unless your
> process has the highest priority?
>
> His advice to _never_ use a linked list is a little hard to swallow. If
> I am constantly inserting and don't know before hand how much memory I
> need, I find it hard to believe that I could get better performance
> using a vector, since the whole vector has to move because of its
> guarantee to be contiguous.
You don't need to know *exactly* how much memory you will need, even a
> on an every day desktop system where 100s of processes are running, what
> are the chances you are ever going to be in L1 or L2 anyway unless your
> process has the highest priority?
>
> His advice to _never_ use a linked list is a little hard to swallow. If
> I am constantly inserting and don't know before hand how much memory I
> need, I find it hard to believe that I could get better performance
> using a vector, since the whole vector has to move because of its
> guarantee to be contiguous.
ballpark figure will help.
After, say, a v.reserve(1000000) the vector will hardly ever reallocate.
Bo Persson
Paavo Helde
Oct 23, 2014, 1:02:00 PM10/23/14
to
Christopher Pisz <nos...@notanaddress.com> wrote in
news:m2bajq$av9$1...@dont-email.me:
> This is an interesting video. Coworker raised a point though. If
> you're on an every day desktop system where 100s of processes are
> running, what are the chances you are ever going to be in L1 or L2
> anyway unless your process has the highest priority?
Thankfully enough, most of these 100 processes are sleeping and waiting
for something like a mouse click. Also, your evereday desktop system
already has multiple cores (together with multiple L1 and to some extent
also L2 and L3 caches) so it can run more processes really in parallel.
We have done lots of profiling with memory-intensive applications and the
effect of caches is clearly visible. For example, when adding more
calculation threads one-by-one the overall performance goes up linearly
to 6 threads, then starts to decline and level to a plateau, although the
machine has 12 physical cores (and 24 logical ones with HT). Reason?
There were only 6 L3 caches. If the caches were of no use, nothing
spectacular would happen at 6 threads.
> His advice to _never_ use a linked list is a little hard to swallow.
> If I am constantly inserting and don't know before hand how much
> memory I need, I find it hard to believe that I could get better
> performance using a vector, since the whole vector has to move because
> of its guarantee to be contiguous.
>
> I'd be interested in seeing some test code to profile that show
> results that conflict with the way we usually think.
It all depends on the task. Std::list is in general indeed pretty
useless, std::deque or std::vector are often a better fit. But it all
depends on circumstances, one cannot apply generic wisdom "never use
something!" here. If some data structure were really not useful at all
for anything, it would not be in the standard! And performance is only
one of the goals and must be balanced with all others.
Cheers
Paavo
news:m2bajq$av9$1...@dont-email.me:
> This is an interesting video. Coworker raised a point though. If
> you're on an every day desktop system where 100s of processes are
> running, what are the chances you are ever going to be in L1 or L2
> anyway unless your process has the highest priority?
for something like a mouse click. Also, your evereday desktop system
already has multiple cores (together with multiple L1 and to some extent
also L2 and L3 caches) so it can run more processes really in parallel.
We have done lots of profiling with memory-intensive applications and the
effect of caches is clearly visible. For example, when adding more
calculation threads one-by-one the overall performance goes up linearly
to 6 threads, then starts to decline and level to a plateau, although the
machine has 12 physical cores (and 24 logical ones with HT). Reason?
There were only 6 L3 caches. If the caches were of no use, nothing
spectacular would happen at 6 threads.
> His advice to _never_ use a linked list is a little hard to swallow.
> If I am constantly inserting and don't know before hand how much
> memory I need, I find it hard to believe that I could get better
> performance using a vector, since the whole vector has to move because
> of its guarantee to be contiguous.
>
> I'd be interested in seeing some test code to profile that show
> results that conflict with the way we usually think.
useless, std::deque or std::vector are often a better fit. But it all
depends on circumstances, one cannot apply generic wisdom "never use
something!" here. If some data structure were really not useful at all
for anything, it would not be in the standard! And performance is only
one of the goals and must be balanced with all others.
Cheers
Paavo
Öö Tiib
Oct 24, 2014, 4:38:39 AM10/24/14
to
anyone welcome that? C and C++ can with ease interface with script
languages like Python. What is oh so special about C# that it needs
a vomit package?
Daniel
Oct 24, 2014, 9:25:39 AM10/24/14
to
On Friday, October 24, 2014 4:38:39 AM UTC-4, Öö Tiib wrote:
>
> C and C++ can be exposed to C# wrapped into that puke layer? How can
> anyone welcome that?
Why not? It provides more customers for libraries written completely in Standard C++.
>
> C and C++ can be exposed to C# wrapped into that puke layer? How can
> anyone welcome that?
> C and C++ can with ease interface with script
> languages like Python. What is oh so special about C# that it needs
> a vomit package?
Daniel
Öö Tiib
Oct 24, 2014, 6:14:30 PM10/24/14
to
On Friday, 24 October 2014 16:25:39 UTC+3, Daniel wrote:
> On Friday, October 24, 2014 4:38:39 AM UTC-4, Öö Tiib wrote:
> >
> > C and C++ can be exposed to C# wrapped into that puke layer? How can
> > anyone welcome that?
>
> Why not? It provides more customers for libraries written completely
> in Standard C++.
It does not provide anything. It just makes interfacing between
> On Friday, October 24, 2014 4:38:39 AM UTC-4, Öö Tiib wrote:
> >
> > C and C++ can be exposed to C# wrapped into that puke layer? How can
> > anyone welcome that?
>
> Why not? It provides more customers for libraries written completely
> in Standard C++.
languages pointlessly complicated. You have been brainwashed to
believe that there can be reason (and even need) for having such
layer of shit anywhere. Have you tried to write C++ for Android?
It is easy to interface between Java and C++.
> > C and C++ can with ease interface with script
> > languages like Python. What is oh so special about C# that it needs
> > a vomit package?
>
> It's only glue to bind one language with another.
> You find "ref class", "ref interface", ^ so offensive to your eye?
> Relax. It's isolated to an interfacing assembly.
about unneeded layer of trash that neither C++ nor C# developers can
debug within reasonable time-frame. So who's left? Me? No way.
I have more pleasant things to do than to dig in such artificially
manufactured vomit.
Christopher Pisz
Oct 24, 2014, 7:02:19 PM10/24/14
to
On 10/24/2014 5:14 PM, 嘱 Tiib wrote:
> On Friday, 24 October 2014 16:25:39 UTC+3, Daniel wrote:
> On Friday, 24 October 2014 16:25:39 UTC+3, Daniel wrote:
I agree though. I have never ever ever had the desire to turn on the CLR
in msvc for a C++ project.
You can also talk to C# through COM and I do do that. COM interfaces on
the C++ side can probably also be described as vomit, but I found the C#
side not to be too bad. I hate COM, but sometimes I just need to talk to
C# and its better than writing something from scratch to do the job.
Pros outweigh cons sometimes.
This still leads to debugging problems as described. As well as memory
leak detection problems. However, if your COM layer is just a simple
pass through, than that's not as big of an issue.
Öö Tiib
Oct 25, 2014, 7:26:08 AM10/25/14
to
communication and even for RPC (but that RPC part feels vulnerable,
it opens more attack vectors, so is better to disable). C++ end is
tolerable if to consider that it works inter-process and in
language-neutral way.
> This still leads to debugging problems as described. As well as memory
> leak detection problems. However, if your COM layer is just a simple
> pass through, than that's not as big of an issue.
Debugging is simpler if to keep the modules written in different
languages in different processes. Then we have just to attach different
debugger to each process.
Memory management issues I have only seen in C++ when someone did not
use the ATL COM smart pointers and/or called 'IUnknown::AddRef' or
'IUnknown::Release' directly for whatever reason. That indeed screws
everything up. :D
The only thing I don't like about COM is its dependency on Windows
registry. That is fault of registry, database of everything is good
for nothing.
Tobias Müller
Oct 25, 2014, 8:20:05 AM10/25/14
to
Öö Tiib <oot...@hot.ee> wrote:
> C and C++ can be exposed to C# wrapped into that puke layer? How can
> anyone welcome that? C and C++ can with ease interface with script
> languages like Python. What is oh so special about C# that it needs
> a vomit package?
Did you actually ever use it or do you always complain like that about
> C and C++ can be exposed to C# wrapped into that puke layer? How can
> anyone welcome that? C and C++ can with ease interface with script
> languages like Python. What is oh so special about C# that it needs
> a vomit package?
things you don't know yourself?
Interop from C# is actually quite painless. I like it much more than
Java/JNI. I don't know if it's the same with android though.
The primary C# interop construct is not C++/CLI but the so called P/Invoke
(platform invoke). It's similar to the FFI in most languages. Define a
prototype of a C function in C# and then call it.
For most cases this enough and you don't need C++/CLI.
Only for complex cases use C++/CLI. You can almost freely mix
managed/unmanaged code with managed/unmanaged data.
Tobi
Öö Tiib
Oct 25, 2014, 9:18:12 AM10/25/14
to
of the time. Also modern desktop system has several processor cores. One has
to have skill to make all cores occupied on desktop system. The cores do not
share L1 or L2. The few processes/threads that work usually work on
different cores.
So we will be in cache most of the time unless we spread the data structure thinly in large memory area (with likes of 'std::list', 'std::set' or 'std::map'). Replacing with 'boost::intrusive::?' or 'boost::flat_?'
(note that what is better depends on circumstances) typically results with
2 times faster program, sometimes 4 or 8 times.
> His advice to _never_ use a linked list is a little hard to swallow. If
> I am constantly inserting and don't know before hand how much memory I
> need, I find it hard to believe that I could get better performance
> using a vector, since the whole vector has to move because of its
> guarantee to be contiguous.
'std::vector' alone performs worse than 'std::list'. Suggestion to
*always* use 'vector' instead of 'list' is plain wrong.
Most well-performing function of 'std::list' is likely 'splice'. It
is rarely used (or even mentioned) when solving real problems and
usually something that uses 'boost::intrusive::list' wins it in tests.
> I'd be interested in seeing some test code to profile that show results
> that conflict with the way we usually think.
book, not Usenet article, short video nor blog.
With 'std::list' it is simple. Just produce a test case that achieves
anything reasonable (the result of algorithm has point) with long 'list'
and challenge people to write the algorithm with something else. If they
can't then we finally have found a case where 'std::list' wins. ;)
Öö Tiib
Oct 25, 2014, 12:41:24 PM10/25/14
to
On Saturday, 25 October 2014 15:20:05 UTC+3, Tobias Müller wrote:
> Öö Tiib <oot...@hot.ee> wrote:
> > C and C++ can be exposed to C# wrapped into that puke layer? How can
> > anyone welcome that? C and C++ can with ease interface with script
> > languages like Python. What is oh so special about C# that it needs
> > a vomit package?
>
> Did you actually ever use it or do you always complain like that about
> things you don't know yourself?
What is "it"? I have indeed participated in writing several
> Öö Tiib <oot...@hot.ee> wrote:
> > C and C++ can be exposed to C# wrapped into that puke layer? How can
> > anyone welcome that? C and C++ can with ease interface with script
> > languages like Python. What is oh so special about C# that it needs
> > a vomit package?
>
> Did you actually ever use it or do you always complain like that about
> things you don't know yourself?
applications in C++ for various platforms and also few in C#. Where
C++/CLI has been ever used there it was most broken part. Even
microsoft's own intellisense could not sort it out what the code means
and it had to be replaced, typically with COM interop.
> Interop from C# is actually quite painless. I like it much more than
> Java/JNI. I don't know if it's the same with android though.
>
> The primary C# interop construct is not C++/CLI but the so called P/Invoke
> (platform invoke). It's similar to the FFI in most languages. Define a
> prototype of a C function in C# and then call it.
> For most cases this enough and you don't need C++/CLI.
>
> Only for complex cases use C++/CLI. You can almost freely mix
> managed/unmanaged code with managed/unmanaged data.
nothing and needed for nothing vomit of language whose only purpose
is to discredit the C++ language with its misleading name.
woodb...@gmail.com
Oct 25, 2014, 1:30:54 PM10/25/14
to
and ::boost::intrusive::list. I think we see unfortunate
consequences of standards process making the container we
know as ::std::list part of the standard. If ::std::list
hadn't been added to the standard, we would have easier
time today sorting this stuff out and giving name of "list"
to a more useful container. Things added to the standard
could have more conservative names. If they had called
::std::list "proposed_list", we wouldn't have this problem.
Brian
Ebenezer Enterprises
http://webEbenezer.net
Öö Tiib
Oct 25, 2014, 3:40:33 PM10/25/14
to
for differentiating.
> I think we see unfortunate
> consequences of standards process making the container we
> know as ::std::list part of the standard. If ::std::list
> hadn't been added to the standard, we would have easier
> time today sorting this stuff out and giving name of "list"
> to a more useful container.
is sequence. The order in sequence of linked elements is important but
should not be result of comparing the elements (or else set and priority
queue perform better) or result of comparing something related to
elements (or else map performs better) or result of adding/removing
elements from container ends (or else deque and ring buffer perform
better).
That basically narrows down usefulness of list into situation where
the sequence is produced by 'splice'ing sub-sequences between different
lists. It is hard to imagine example for such situation.
There are no much difference if it is 'std::list',
'boost::intrusive::slist' or 'boost::intrusive::list'. All of those are
doomed by being optimal for rather unusual situation.
> Things added to the standard could have more conservative names.
> If they had called ::std::list "proposed_list", we wouldn't have
> this problem.
too lot of containers in standard library and they are already in
difficulty to pick. Adding more details there makes it likely
worse not better.
jacob navia
Oct 25, 2014, 5:13:33 PM10/25/14
to
Le 20/10/2014 22:20, Christopher Pisz a écrit :
> Spoken like a true C developer. If it works it's good. Bah!
Well, obviously you think that if it doesn'tg work it is much better!
Surely a C++ "aficionado".
> Spoken like a true C developer. If it works it's good. Bah!
Well, obviously you think that if it doesn'tg work it is much better!
Surely a C++ "aficionado".
jacob navia
Oct 25, 2014, 5:24:15 PM10/25/14
to
Le 21/10/2014 18:20, Christopher Pisz a écrit :
> On 10/21/2014 9:00 AM, Scott Lurndal wrote:
>> Christopher Pisz <nos...@notanaddress.com> writes:
>>> On 10/20/2014 1:40 PM, Scott Lurndal wrote:
>>>> Martin Shobe <martin...@yahoo.com> writes:
>>>>> On 10/20/2014 1:01 PM, Victor Bazarov wrote:
> SNIP
>> Anyone who sees C++ as a tool, not as a religion.
>>
>
> It's more a matter of seeing C as a cult of relic programmers whom have
> twisted values built into them from years of programming with 4k of
> memory, that do not apply anymore, and are out to ruin C++ projects,
C programmers often prefer simplicity in coding. They tend to dislike
> On 10/21/2014 9:00 AM, Scott Lurndal wrote:
>> Christopher Pisz <nos...@notanaddress.com> writes:
>>> On 10/20/2014 1:40 PM, Scott Lurndal wrote:
>>>> Martin Shobe <martin...@yahoo.com> writes:
>>>>> On 10/20/2014 1:01 PM, Victor Bazarov wrote:
> SNIP
>> Anyone who sees C++ as a tool, not as a religion.
>>
>
> It's more a matter of seeing C as a cult of relic programmers whom have
> twisted values built into them from years of programming with 4k of
> memory, that do not apply anymore, and are out to ruin C++ projects,
the utter bloat and performance hit that comes with bloated, fat code.
Now, within the C++ community, insulting the C programmers is a very
old trend, since the inception of this language. The myth of the
"old C programmer" is being vomited since at least 20 years by the C++
heads, when they try to justify their new lambda, templates, what have
you...
>
> I have never ever ever worked on a project with a C programmer that
> wasn't responsible for more than 80% of the bugs being tracked. Whom
> didn't argue until veins popped out of their forehead about things like
> how to format strings, file reading and writing, using globals all over
> the friggin place "because its easier', ignoring the initialization
> fiasco, making retarded interfaces that take string arguments and then
> parsing them using lucky charms encoder rings to get real arguments and
> call other functions and on and on and on.
>
How easy it is to insult people without even the shadow of some data to
justify these insults.
I can do the same:
> I have never ever ever worked on a project with a C++ programmer that
> wasn't responsible for more than 80% of the bugs being tracked. Whom
> didn't argue until veins popped out of their forehead about things like
> how to use templates until nobody understand what the code does,
using lambdas, tiny classes all over the friggin place "because its
easier', ignoring the documentation fiasco, making retarded interfaces
that take string arguments and then
> parsing them using lucky charms encoder rings to get real arguments and
> call other functions and on and on and on.
>
How about that? Isn't that nice to insult other people riding your
highhorse?
> My response was to your statement, "If it works, then it is good code",
> for which you should be shot.
Of course, code that doesn't work is better! That is the reasoning
behind the C++ programmers?
And the tie in to "spoken like a true C
> programmer" is because that statement has been said in so many arguments
> in the past by the very C programmers of which I speak.
>
Surely C++ programmers do not follow the principle:
IF IT AIN'T BROKE DO NOT FIX IT IDIOT!
jacob navia
Oct 25, 2014, 5:34:15 PM10/25/14
to
Le 22/10/2014 18:35, Christopher Pisz a écrit :
> Sure, but the people coming from the world of C have a completely
> different idea of what "good" is and it is often incorrect, because the
> definition has changed quite a bit.
>
> The quote that started this subthread is a perfect example.
Yes, perfect
> Sure, but the people coming from the world of C have a completely
> different idea of what "good" is and it is often incorrect, because the
> definition has changed quite a bit.
>
> The quote that started this subthread is a perfect example.
C++ has been able to hide the lost of performance and efficiency with
using the hardware advances. Modern processors do get bogged down
compiling templte ridden code but it is masked with machines with 8/16
processors and 32 GB of memory.
Bad luck for C++, people are starting to realize that all that language
features DO HAVE an important COST.
Not only in embedded systems where each kilobyte counts but ALSO in more
advanced environments.
Cost of code bloat, that destroys performance
Cost of code bloat that destroys readability
Cost of portability issues between compilers and between versions of the
language.
Nobody is able to understand 100% of all C++. Not even Stroustroup, that
after years of efforts was forced to acknowledge that he could not add
an essential new feature to the language ("concepts" anyone?)
The people here give a proof of this situation with every question a
bit complex:
Why doesn't this compile?
The answers are often:
It compiles with compiler "xyz"
It doesn't compile with compiler 'zzz'
Nobody is able to follow the language text and deduce why it should
compile or not!
Look, C++ has its strengths but also has a lot of weakness, the
principal one is its shher SIZE.
Of course (as you point out) you can go to the computer store and buy
more RAM and accomodate an even bigger language.
But there aren't any stores to buy a BRAIN EXTENSION to accomodate the
ever increasing amount of C++ trivia we are supposed to swallow!
Yours truly
jacob, a C programmer
Ian Collins
Oct 25, 2014, 6:00:06 PM10/25/14
to
jacob navia wrote:
> Le 22/10/2014 18:35, Christopher Pisz a écrit :
>> Sure, but the people coming from the world of C have a completely
>> different idea of what "good" is and it is often incorrect, because the
>> definition has changed quite a bit.
>>
>> The quote that started this subthread is a perfect example.
>
> Yes, perfect
>
> C++ has been able to hide the lost of performance and efficiency with
> using the hardware advances. Modern processors do get bogged down
> compiling templte ridden code but it is masked with machines with 8/16
> processors and 32 GB of memory.
>
> Bad luck for C++, people are starting to realize that all that language
> features DO HAVE an important COST.
>
> Not only in embedded systems where each kilobyte counts but ALSO in more
> advanced environments.
>
> Cost of code bloat, that destroys performance
So don't write bloated code, this isn't rocket science.
> Le 22/10/2014 18:35, Christopher Pisz a écrit :
>> Sure, but the people coming from the world of C have a completely
>> different idea of what "good" is and it is often incorrect, because the
>> definition has changed quite a bit.
>>
>> The quote that started this subthread is a perfect example.
>
> Yes, perfect
>
> C++ has been able to hide the lost of performance and efficiency with
> using the hardware advances. Modern processors do get bogged down
> compiling templte ridden code but it is masked with machines with 8/16
> processors and 32 GB of memory.
>
> Bad luck for C++, people are starting to realize that all that language
> features DO HAVE an important COST.
>
> Not only in embedded systems where each kilobyte counts but ALSO in more
> advanced environments.
>
> Cost of code bloat, that destroys performance
> Cost of code bloat that destroys readability
> Cost of portability issues between compilers and between versions of the
> language.
> Of course (as you point out) you can go to the computer store and buy
> more RAM and accomodate an even bigger language.
> But there aren't any stores to buy a BRAIN EXTENSION to accomodate the
> ever increasing amount of C++ trivia we are supposed to swallow!
>
> Yours truly
>
> jacob, a C programmer
--
Ian Collins
Öö Tiib
Oct 25, 2014, 7:46:59 PM10/25/14
to
On Sunday, 26 October 2014 00:34:15 UTC+3, jacob navia wrote:
> Le 22/10/2014 18:35, Christopher Pisz a écrit :
> > Sure, but the people coming from the world of C have a completely
> > different idea of what "good" is and it is often incorrect, because the
> > definition has changed quite a bit.
> >
> > The quote that started this subthread is a perfect example.
>
> Yes, perfect
>
> C++ has been able to hide the lost of performance and efficiency with
> using the hardware advances. Modern processors do get bogged down
> compiling templte ridden code but it is masked with machines with 8/16
> processors and 32 GB of memory.
Good C++ does not lose in performance compared to good C. It is easy to
> Le 22/10/2014 18:35, Christopher Pisz a écrit :
> > Sure, but the people coming from the world of C have a completely
> > different idea of what "good" is and it is often incorrect, because the
> > definition has changed quite a bit.
> >
> > The quote that started this subthread is a perfect example.
>
> Yes, perfect
>
> C++ has been able to hide the lost of performance and efficiency with
> using the hardware advances. Modern processors do get bogged down
> compiling templte ridden code but it is masked with machines with 8/16
> processors and 32 GB of memory.
produce badly performing and inefficient programs in C++ and in C and
even in assembler.
> Nobody is able to understand 100% of all C++. Not even Stroustroup, that
> after years of efforts was forced to acknowledge that he could not add
> an essential new feature to the language ("concepts" anyone?)
They still aim to simplify type traits checking and to produce better
diagnostics with templates with reduced plan "concepts lite". What it
is to you? You won't use templates anyway, you use macros that are
often even far worse to debug than templates.
> Look, C++ has its strengths but also has a lot of weakness, the
> principal one is its shher SIZE.
the compilers produce are not that large. C++ is well-performing and
efficient language in good hands.
> Of course (as you point out) you can go to the computer store and buy
> more RAM and accomodate an even bigger language.
application to be bigger than same thing achieved with C.
> But there aren't any stores to buy a BRAIN EXTENSION to accomodate the
> ever increasing amount of C++ trivia we are supposed to swallow!
for brain extension) is to understand correctly what the humans want
to do with our programs and why. Once that is clear then to put it
to programming language is lot easier. With C it is just less convenient
than with C++.
Christopher Pisz
Oct 27, 2014, 12:13:10 PM10/27/14
to
Having something that appears to perform one iteration of the
requirements is not good until it is maintainable and extensible.
If the only guy that can make sense of the is the old man C programmer,
whom has memorized all the lucky charms encoder rings he wrote the thing
with, then it is not good. In fact, it would probably be better to
delete it and start over than to spend man hours trying to reverse
engineer it.
"working" is only one factor of what makes good code. While many
managers may disagree, it is often to the company's detriment.
0 new messages