Friday, October 24, 2014

Digest for comp.lang.c++@googlegroups.com - 25 updates in 5 topics

comp.lang.c++@googlegroups.com Google Groups
Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com.
drew@furrfu.invalid (Drew Lawson): Oct 20 05:37PM

In article <m2324v$76r$1@dont-email.me>
 
>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.
 
--
|Drew Lawson | If you're not part of the solution |
| | you're part of the precipitate. |
Victor Bazarov <v.bazarov@comcast.invalid>: Oct 20 02:01PM -0400

On 10/20/2014 1:37 PM, Drew Lawson wrote:
> 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?
 
V
--
I do not respond to top-posted replies, please don't ask
Robert Hutchings <rm.hutchings@gmail.com>: Oct 20 01:12PM -0500

On 10/20/2014 12:37 PM, Drew Lawson wrote:
> 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
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.
Robert Hutchings <rm.hutchings@gmail.com>: Oct 20 01:44PM -0500

On 10/20/2014 1:41 PM, Scott Lurndal wrote:
>> who was compelled by the CEO.
 
> Surely you have citations for this? Other than anecdotal statements of
> unreliable veracity?
 
http://www.computerworld.com/article/2490610/it-outsourcing/this-it-worker-had-to-train-an-h-1b-replacement.html
scott@slp53.sl.home (Scott Lurndal): Oct 20 06:40PM


>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"?
 
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@slp53.sl.home (Scott Lurndal): Oct 20 06:41PM

>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
unreliable veracity?
Robert Hutchings <rm.hutchings@gmail.com>: Oct 20 01:43PM -0500

On 10/20/2014 1:41 PM, Scott Lurndal wrote:
>> who was compelled by the CEO.
 
> Surely you have citations for this? Other than anecdotal statements of
> unreliable veracity?
 
Are you kidding me? MANY workers were forced to this. What citations
could I give?
scott@slp53.sl.home (Scott Lurndal): Oct 20 07:03PM


>> Surely you have citations for this? Other than anecdotal statements of
>> unreliable veracity?
 
>http://www.computerworld.com/article/2490610/it-outsourcing/this-it-worker-had-to-train-an-h-1b-replacement.html
 
1) this is anecdotal.
2) One swallow doesn't make a summer.
Victor Bazarov <v.bazarov@comcast.invalid>: Oct 20 02:33PM -0400

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
 
V
--
I do not respond to top-posted replies, please don't ask
Robert Hutchings <rm.hutchings@gmail.com>: Oct 20 02:10PM -0500

On 10/20/2014 2:03 PM, Scott Lurndal wrote:
 
>> http://www.computerworld.com/article/2490610/it-outsourcing/this-it-worker-had-to-train-an-h-1b-replacement.html
 
> 1) this is anecdotal.
> 2) One swallow doesn't make a summer.
 
http://www.theguardian.com/business/2012/aug/10/illinois-workers-bain-outsourcing
Robert Hutchings <rm.hutchings@gmail.com>: Oct 20 02:12PM -0500

On 10/20/2014 2:03 PM, Scott Lurndal wrote:
 
>> http://www.computerworld.com/article/2490610/it-outsourcing/this-it-worker-had-to-train-an-h-1b-replacement.html
 
> 1) this is anecdotal.
> 2) One swallow doesn't make a summer.
 
http://usatoday30.usatoday.com/money/workplace/2004-04-06-replace_x.htm
Christopher Pisz <nospam@notanaddress.com>: Oct 20 03:20PM -0500

On 10/20/2014 1:40 PM, Scott Lurndal wrote:
>> 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?
 
 
> 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.
 
Desirable by whom?
Robert Hutchings <rm.hutchings@gmail.com>: Oct 20 03:25PM -0500

On 10/20/2014 3:21 PM, Öö Tiib wrote:
> 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?
 
Yes, I can see that. It was hard for us in America to believe it was
happening! But, unfortunately, it WAS happening. Maybe not quite as
much NOW, I hope....
Christopher Pisz <nospam@notanaddress.com>: Oct 20 10:33AM -0500

On 10/19/2014 5:55 AM, Andrea wrote:
> I saw this framework and it seems very interesting (I have done some
> tests with the Qt Creator editor and are positively surprised).
 
> Does anyone use it? Opinions?
 
All the responses in this thread ignore what the target OS is.
If yer on *nix, sure, go Qt. If you are targeting Windows then there are
vastly more options. You could even use the Windows API....
Christopher Pisz <nospam@notanaddress.com>: Oct 20 10:40AM -0500

On 10/20/2014 10:33 AM, Christopher Pisz wrote:
 
> All the responses in this thread ignore what the target OS is.
> If yer on *nix, sure, go Qt. If you are targeting Windows then there are
> vastly more options. You could even use the Windows API....
 
P.S
I would question why anyone would do a UI in C++ at all, unless you were
programming up a video game. C++ is for high performance critical code
imo. .NET or Java would be more suited for a UI that has to wait on a
user to click a button. You can separate the two and it has been my
experience in most projects that they will. Let your C++ code do the
heavy lifting and let some other technology present it.
 
The only UIs I see people make new with C++ are very simple dialogs. If
you find yourself working on a UI in C++ these days, it was probably
some ancient artifact that no one wants to do over imo.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 20 06:25PM +0100

On 20/10/2014 16:40, Christopher Pisz wrote:
 
> The only UIs I see people make new with C++ are very simple dialogs. If
> you find yourself working on a UI in C++ these days, it was probably
> some ancient artifact that no one wants to do over imo.
 
The proposal to add 2D graphics support to the C++ standard library is
at odds with your analysis re C++ and writing GUIs.
 
/Flibble
Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com>: Oct 20 08:35PM +0200

On Sun, 19 Oct 2014 17:47:36 +0200
Norbert_Paul <norbertpauls_spambin@yahoo.com> wrote:
 
[...]
> quite much time waiting for the compiler to finish after having made
> minor changes. (Actually, I suspect that this having to wait so much
> is also a design issue of our software).
 
The moc is only needed to _define_ signals/slots, not to use them.
And since slots are just normal methods with some syntactic sugar
for the moc, you can often avoid moc-specifics spreading too far
by building moc-aware base classes with virtual slots and deriving
from those. I often do that for standard stuff.
Qt5 is said to have an alternative approach to signals/slots, but
I haven't tried it yet.
 
 
> QList, etc. Being a great fan of the STL I see no point why Qt tries
> to re-invented the wheel. There also exist QThred, QFile, QDirectory,
> QApplication, qMax<T>, ...
 
There are two reasons why these classes exist:
1) Qt predates usable STL (in a productive sense) by quite some time
2) Qt wants a stable _binary_ interface within major releases and you
can completely forget about that as soon as you involve the STL.
 
One could also add
3) Why fix what isn't broken? Qt containers also have an STL-compatible
interface including iterators, plus they allow implicit sharing.
 
 
Furthermore, QString does NOT compete with std::string. QString exists
due to the blatant absence of a proper string class anywhere in the
standard. QString has proper Unicode support, and all classes within
Qt which use "strings" interface to it, so it's trivial to have full,
platform-independent, lossless Unicode support from the command line to
the file system. Good luck trying that with std::string, std::wstring and
the (mostly) char*-based crap provided by the standard -- it might work
on Unix with UTF-8 encoding to a certain extent (and that only by accident,
not because it's standard-defined behaviour), but the only thing it'll
produce on Windows is another broken application.
There's an analogon of std::string in Qt too, BTW. It's called QByteArray
and the main difference between that and std::string is that Qt used
the corrent name.
 
 
 
Andreas
--
Dr. Andreas Dehmel Ceterum censeo
FLIPME(ed.enilno-t@nouqraz) Microsoft esse delendam
http://www.zarquon.homepage.t-online.de (Cato the Much Younger)
Melzzzzz <mel@zzzzz.com>: Oct 20 08:15PM +0200

On Mon, 20 Oct 2014 10:40:15 -0500
> were programming up a video game. C++ is for high performance
> critical code imo. .NET or Java would be more suited for a UI that
> has to wait on a user to click a button.
 
Java for UI?! Bljak...
 
You can separate the two and
 
> The only UIs I see people make new with C++ are very simple dialogs.
> If you find yourself working on a UI in C++ these days, it was
> probably some ancient artifact that no one wants to do over imo.
 
C++ is perfect for UI... Take for example spreadsheet app in few
lines of code with Qt... from qt programming book....
 
 
--
Manjaro all the way!
http://manjaro.org/
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 20 07:52PM +0100

On 20/10/2014 19:35, Andreas Dehmel wrote:
 
> Furthermore, QString does NOT compete with std::string. QString exists
> due to the blatant absence of a proper string class anywhere in the
> standard. QString has proper Unicode support, and all classes within
 
QString uses wchar_t and UTF-16 which I would hardly call "proper
Unicode support".
 
> There's an analogon of std::string in Qt too, BTW. It's called QByteArray
> and the main difference between that and std::string is that Qt used
> the corrent name.
 
At least std::string lets you encode UTF-8 which is far superior to
UTF-16 (which like UTF-8 is also a variable length encoding).
 
/Flibble
Christopher Pisz <nospam@notanaddress.com>: Oct 20 01:54PM -0500

On 10/20/2014 12:25 PM, Mr Flibble wrote:
> On 20/10/2014 16:40, Christopher Pisz wrote:
>> On 10/20/2014 10:33 AM, Christopher Pisz wrote:
>>> On 10/19/2014 5:55 AM, Andrea wrote:
SNIP
> The proposal to add 2D graphics support to the C++ standard library is
> at odds with your analysis re C++ and writing GUIs.
 
> /Flibble
 
Plans for the future don't effect an analysis of the current.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 20 07:59PM +0100

On 20/10/2014 19:54, Christopher Pisz wrote:
>> at odds with your analysis re C++ and writing GUIs.
 
>> /Flibble
 
> Plans for the future don't effect an analysis of the current.
 
Bullshit mate and you know it.
 
/Flibble
Paavo Helde <myfirstname@osa.pri.ee>: Oct 20 11:22AM -0500

drew@furrfu.invalid (Drew Lawson) wrote in
 
> This is what g++ gives me when I use a non-const iterator on a const
> vector<string> (linebreaks added for sanity, the original is 2 lines):
 
> foo.cc:11: error: no match for 'operator=' in 'it =
 
Here the compiler explicitly tells you in the beginning of the error
message: "no match for 'operator='". That's all you need, the rest of the
line noise can be ignored. It tells me an assignment did not work
somewhere. If I look at the culprit line and it looks otherwise kosher,
then the reason is most probably const-non-const mixup. At least it has
been so in 100% of cases I have seen this error for my code.
 
Yes, the error messages could be better, but they are actually helpful -
if you know what to look for.
 
Cheers
Paavo
Paavo Helde <myfirstname@osa.pri.ee>: Oct 20 02:01PM -0500

drew@furrfu.invalid (Drew Lawson) wrote in
> I realize this is a toolset problem, not a language problem. I'd
> appreciate hearing about any C++ compilers that don't spew line
> noise for cases like this.
 
I did a little experimentation with online compilers. The program is
here:
 
#include <vector>
#include <string>
int main() {
std::vector<std::string> abc;
abc.push_back("a");
std::vector<std::string>::const_iterator it = abc.begin();
*it = "b";
}
 
The error messages I got are below. It appears Intel's icc is actually
producing the most helpful message.
 
---------------------
icc 13.0:
 
/tmp/gcc-explorer-compiler114920-17793-151o21n/example.cpp(7): error: no
operator "=" matches these operands
 
operand types are: const std::string = const char [2]
 
 
---------------------
gcc 4.9.0:
 
/tmp/gcc-explorer-compiler114920-29276-1xukbcf/example.cpp: In function
'int main()':
 
7 : error: passing 'const std::basic_string' as 'this' argument of
'std::basic_string<_CharT, _Traits, _Alloc>& std::basic_string<_CharT,
_Traits, _Alloc>::operator=(const _CharT*) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]' discards qualifiers [-
fpermissive]
 
---------------------
clang 3.4.1
 
7 : error: no viable overloaded '='
 
*it = "b";
 
~~~ ^ ~~~
 
/usr/lib/gcc/x86_64-linux-
gnu/4.8/../../../../include/c++/4.8/bits/basic_string.h:546:7: note:
candidate function not viable: 'this' argument has type 'const
std::basic_string<char>', but method is not marked const
 
operator=(const basic_string& __str)
 
^
 
/usr/lib/gcc/x86_64-linux-
gnu/4.8/../../../../include/c++/4.8/bits/basic_string.h:554:7: note:
candidate function not viable: 'this' argument has type 'const
std::basic_string<char>', but method is not marked const
 
operator=(const _CharT* __s)
 
^
 
/usr/lib/gcc/x86_64-linux-
gnu/4.8/../../../../include/c++/4.8/bits/basic_string.h:565:7: note:
candidate function not viable: 'this' argument has type 'const
std::basic_string<char>', but method is not marked const
 
operator=(_CharT __c)
 
^
 
-----------------------------
 
MSVC 2012:
 
test.cpp(7): error C2678: binary '=' : no operator found which takes a
left-hand operand of type 'const std::basic_string<_Elem,_Traits,
_Alloc>' (or there is no acceptable conversion)
with
[
_Elem=char,
_Traits=std::char_traits<char>,
_Alloc=std::allocator<char>
]
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include
\xstring(912): could be 'std::basic_string<_Elem,_Traits,_Alloc>
&std::basic_string<_Elem,_Traits,_Alloc>::operator =(std::basic_string
<_Elem,_Traits,_Alloc> &&) throw()'
with
[
_Elem=char,
_Traits=std::char_traits<char>,
_Alloc=std::allocator<char>
]
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include
\xstring(969): or 'std::basic_string<_Elem,_Traits,_Alloc>
&std::basic_string<_Elem,_Traits,_Alloc>::operator =(const
std::basic_string<_Elem,_Traits,_Alloc> &)'
with
[
_Elem=char,
_Traits=std::char_traits<char>,
_Alloc=std::allocator<char>
]
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include
\xstring(987): or 'std::basic_string<_Elem,_Traits,_Alloc>
&std::basic_string<_Elem,_Traits,_Alloc>::operator =(const _Elem *)'
with
[
_Elem=char,
_Traits=std::char_traits<char>,
_Alloc=std::allocator<char>
]
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include
\xstring(992): or 'std::basic_string<_Elem,_Traits,_Alloc>
&std::basic_string<_Elem,_Traits,_Alloc>::operator =(_Elem)'
with
[
_Elem=char,
_Traits=std::char_traits<char>,
_Alloc=std::allocator<char>
]
while trying to match the argument list '(const
std::basic_string<_Elem,_Traits,_Alloc>, const char [2])'
with
[
_Elem=char,
_Traits=std::char_traits<char>,
_Alloc=std::allocator<char>
]
 
-------------------------------
Truth <ItIs@IsTruth.com>: Oct 24 06:30AM -0700

On 10/23/2014 4:00 AM, James K. Lowden wrote:
 
>> I am mostly finished w/ a free edx.org course on c++. I have found
>> this worthwhile, but my question is this: how can I write a program
>> with dividing my code into separate files.
[...]
 
> Since about 1975, yes. :-)
 
> make is a tool much maligned but exceedingly useful, likely the only
> declarative rule processor in your toolbox.
[...]
> make" (assuming you're using GNU make), easier to understand.
 
> HTH.
 
> --jkl
 
Snipped well written, informative post for brevity. :-)
 
Once you get the basics down, one could also look into CMake. It's a
tool to help manage, (and more), make files.
http://www.cmake.org/
 
Nice synopsis.
http://www.cmake.org/Wiki/CMake
 
HTH as well. :)
Emanuel Berg <embe8573@student.uu.se>: Oct 19 10:01PM +0200

> ad hoc stuff like your polling.
 
> (Someone else suggested ways to cut down on the
> influence.)
 
OK, first, thank you, and thank you to J. Clarke as
well.
 
You are absolutely right, the problem is that there is
RT and BE and they influence each other. The challenge
is to isolate them except for what cannot be isolated,
which is the shared DRAM.
 
But, the RT part doesn't have to be isolated from the
BE part, as long as the influence can be bounded. If
it can be bounded, it can be computed, and then
formalized, i.e., the BE influence will be
incorporated and accounted for in the RT part.
 
At this moment, the RT part knows how many accesses
the BE part can be allowed to make, and this is
communicated to the Linux kernel with a syscall.
 
The BE processes are told to run exclusively on the BE
core (in userspace) with the tool taskset
('taskset -c CORE') and with this
 
GRUB_CMDLINE_LINUX_DEFAULT="quiet isolcpus=0"
 
in /etc/default/grub - it works, they only run there
and this can be confirmed with 'top' or 'ps'.
 
Do you happen to know how the scheduler can be
modified to, whenever told so (doesn't matter by means
of an interrupt or polling), how the scheduler can be
told to not execute those tasks, i.e. to freeze the BE
core?
 
Or is that better setup on a process basis, as in a
field in the PCB or something? (I would think that's
where ps and top get their information.)
 
--
underground experts united
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:

Post a Comment

Subscribe to: Post Comments (Atom)