Thursday, January 25, 2018

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

blisca <blisca@tiscali.it>: Jan 25 07:47AM +0100

Hello
 
i need some help,please
 
I have installed two c++ environment
Code::Blocks and Eclipse Oxygen
 
In both cases a simple "Hello world" project is compiled with 0 errors 0
warnings,
but i can't debug it.
If i set a breakpoint i have this error:
 
No symbol table is loaded. Use the "file" command.
 
I read lot of forum for similar question,checked all the boxes (i
think)having to do with debug information generation,but no way
 
Should i re-install MinGw oe what?
 
Please can you help me?
 
Thank you so much for your attention
 
---
Questa email è stata esaminata alla ricerca di virus da AVG.
http://www.avg.com
Vir Campestris <vir.campestris@invalid.invalid>: Jan 25 09:07PM

On 25/01/2018 06:47, blisca wrote:
 
> Should i re-install MinGw oe what?
 
> Please can you help me?
 
> Thank you so much for your attention
 
I'm going to guess you're running Linux and Gnu tools.
 
There's a switch "-g" to the Gnu compilers to make them generate debug
information.
> ---
> Questa email è stata esaminata alla ricerca di virus da AVG.
> http://www.avg.com
 
And turn that thing off please. There is an option somewhere in the tool.
 
Andy
Tim Rentsch <txr@alumni.caltech.edu>: Jan 25 10:46AM -0800

>> "(c = fgetc (in))" becuase the comma-operator has the
>> lowest precedence.
 
> I just looked. There are 17 levels of operator precedence.
 
17, and counting. The latest C++ standard draft has an additional
level for the new <=> operator.
 
Incidentally, C++ has one more level than C, because of going
through pointer-to-member values. In retrospect I think it might
have been better if the syntax for using pointer-to-member access
were
 
postfix-expression . ( expression )
postfix-expression -> ( expression )
 
so using pointer-to-member could fold in naturally into the
existing syntax, rather than having to add a level. (Disclaimer:
I have done no checking for possible ambiguities, etc.)
 
> Please consider that future readers of your code may not have
> memorised them all.
 
Anyone who has the necessary skills to be a competent software
developer can learn the syntax/precedence rules for expressions,
even in C++. The word "memorize" (or "memorise") isn't quite
right -- children memorize the order of letters in the alphabet,
which has an arbitrary order. The syntax for expressions is not
at all arbitrary but explicitly chosen for reasons that are (at
least mostly) good ones. That makes it easier to learn than an
arbitrary order like letters in an alphabet. Speaking of which,
there are (in English) 26 letters in the alphabet, and we expect
everyone will have memorized that order. A mere 17 levels is a
piece of cake.
 
Furthermore, anyone who is serious about being a good developer
should aspire to know the syntax/precedence rules without having
to look them up (if they don't know them already). Appeals to
concern over "the average programmer" displays an attitude of
excusing thinking that is sloppy, lazy, or careless. That's
self-reinforcing in the wrong direction: if it's expected that
someone's thinking will be sloppy, lazy, or careless, it will be;
conversely, if it's expected that their thinking will not be
sloppy, lazy, or careless, it won't be. (Or perhaps the person
in question will leave to seek out another profession, which is
also a good result.) It wouldn't be a bad idea to tell new hires
that at the end of a week they would be tested on knowing the
language expression precedence rules, and anyone who failed the
test be let go. Even better, tell them (before they come in)
that they will be tested on that during the interview.
 
Interesting anecdote -- where I went to school, there was course
for people who were Chemistry majors that gave the following
test (announced in advance as being closed book): student is
given a piece of paper with a blank periodic table on it, and
instructed to fill in the names/symbols for the elements, in
their appropriate boxes.
 
Other disciplines take their education seriously. So should
software developers.
asetofsymbols@gmail.com: Jan 25 12:01PM -0800

In one ideal language one has to remember the minimum possible
for the language (so one easy language)
because one have to think to the algorithm and see the loop
Vir Campestris <vir.campestris@invalid.invalid>: Jan 25 09:03PM

> In one ideal language one has to remember the minimum possible
> for the language (so one easy language)
> because one have to think to the algorithm and see the loop
 
Absolutely.
 
To me the language is a way to get things done, not a means in itself.
 
Tim & I will have to disagree over that, just as we disagree on minor
points of English vs American.
 
Andy
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 25 06:48AM

On Wed, 2018-01-24, Tim Rentsch wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
...
[const on parameters and locals]
 
> matter, but in those cases I would rather see effort be applied
> to dividing the function appropriately than to making the long
> function easier to live with.
 
Yes, but refactoring a function is more work and more risk.
 
One of my favorite ways of deciphering someone else's overlong
function is to add const, so I can be sure 'foo' set near the
beginning of the function has the same value one screenful later.
Then when I understand it better, it's easier to refactor.
 
 
> For me 'const' signifies something worth bringing to the attention
> of the reader. Overusing const is just as much of a negative as
> underusing it.
 
Different mindsets, then.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 25 07:02AM

On Wed, 2018-01-24, Alf P. Steinbach wrote:
>> things a lot less than having to read code backwards.
 
> I'm not sure I grok what you mean here. Surely you don't read the code
> sequentially?
 
I see what he means, I think: he wants to open a file and see the most
important stuff at the top -- constructors and public functions, if
it's a class; or main() if it's the main source.
 
That's what I'd like to see too, ideally ... but if I tried to do it
that way I'm afraid I wouldn't split out helper functions as often as
I should. I can't be bothered to maintain three things: the
declaration of helper(), the call to helper(), and the implementation
of helper(), somewhere far down in the file.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Ian Collins <ian-news@hotmail.com>: Jan 25 08:16PM +1300

On 01/25/2018 08:02 PM, Jorgen Grahn wrote:
> I should. I can't be bothered to maintain three things: the
> declaration of helper(), the call to helper(), and the implementation
> of helper(), somewhere far down in the file.
 
I agree, helpers should be in the anonymous namespace, which has the
side effect of grouping then tidily.
 
--
Ian.
Daniel <danielaparker@gmail.com>: Jan 25 05:30AM -0800

On Wednesday, January 24, 2018 at 6:07:18 PM UTC-5, Daniel wrote:
> On Wednesday, January 24, 2018 at 4:55:28 PM UTC-5, Vir Campestris wrote:
 
> > If I was designing a language from scratch I think I'd make const default.
 
> I'd be skeptical ...
 
Ahh, I should have checked the context before replying, thought it
was about function signatures, as it is, my comment makes no sense.
 
Daniel
Manfred <noname@invalid.add>: Jan 25 05:01PM +0100

On 1/25/2018 7:48 AM, Jorgen Grahn wrote:
> [const on parameters and locals]
 
>>> Oddly, I'm with Alf here. Maybe not for tiny function bodies like this one,
>>> but not just for huge ones either.
Me too, in fact I have an habit of const-qualifying most locals per
default. Less than most for parameters, but still not that infrequently.
 
I may add that complexity of a code fragment is directly proportional to
the amount of data variables involved (which in fact constitute the
state of the machine 'fragment'), so constraining such data as const
helps managing its complexity.
 
>> matter, but in those cases I would rather see effort be applied
>> to dividing the function appropriately than to making the long
>> function easier to live with.
 
I would say it is about function complexity more than size.
 
>> of the reader. Overusing const is just as much of a negative as
>> underusing it.
 
> Different mindsets, then.
 
Different mindsets indeed.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 25 02:17PM

On Wed, 2018-01-24, Vir Campestris wrote:
> to tell us what's wrong. We too have some abort during delete - and they
> only happen every couple of months on any given system. One or two
> people do not want asserts in production code.
 
"Fail hard, fail early" is the norm around here, too.
 
Trends like microservice architecture point in that direction, too: if
you can just let a small component die and be replaced by a working
one, there's no point in trying to patch over problems and continue.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
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)