Wednesday, January 14, 2015

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

Paavo Helde <myfirstname@osa.pri.ee>: Jan 13 10:55AM -0600


> myVect operator=(char s[])
> {
> trunc = (((string)s).length() + 1 > sizeof s_vector) ? false :
true;
> system("pause");
> return;
> }
 
What's this supposed to be? An example how to NOT write C++? Note that
this example illustrates very well the dangers of C-style programming,
the loop accesses the s[] array beyound the array end and causes UB.
 
In addition, operator= makes a copy of the object in the return
statement, this is not what it should do.
 
In C++ this would read (and note that you don't need to truncate
anything, so trunc member is not needed):
 
class myVect
{
private:
static std::string s_vector;
std::string us_vector;
 
public:
 
myVect& operator=(char s[])
{
s_vector = us_vector = s;
return *this;
}
 
// ...
 
hth
Paavo
jak <please@nospam.tnx>: Jan 13 06:45PM +0100

Il 13/01/2015 17:55, Paavo Helde ha scritto:
>> return;
>> }
 
> What's this supposed to be? An example how to NOT write C++?
 
Oi... un po' più di rispetto. Sei qui per dare supporto o per esibire la
tua cafonaggine?
 
Note that
> this example illustrates very well the dangers of C-style programming,
> the loop acceses the s[] array beyound the array end and causes UB.
 
--
> In addition, operator= makes a copy of the object in the return
> statement, this is not what it should do.
 
Grazie. Questo è interessante.
--
> In C++ this would read (and note that you don't need to truncate
> anything, so trunc member is not needed):
 
L'esempio è mio e se voglio non usare string, non lo uso.
 
 
> // ...
 
> hth
> Paavo
 
A parte ciò che ho ritenuto interessante il resto è opinione
e in quanto tale lascia il tempo che trova.
jak <please@nospam.tnx>: Jan 13 07:53PM +0100

Il 13/01/2015 19:01, Stefan Ram ha scritto:
> Quindi, vorrei spiegare:
 
> cafonaggine: l'essere cafone
 
> cafone: maleducato, volgare, di cattivo gusto.
 
I thank you, but the translation was not necessary. I have written in
Italian because I lost my appreciation for this discussion group. Here,
there are, by now, few people helping and discusses and too many people
ready to use his wand on the fingers of those who seek clarification
about this language.I address my questions elsewhere.
 
Best regards.
Paavo Helde <myfirstname@osa.pri.ee>: Jan 13 01:21PM -0600


>> What's this supposed to be? An example how to NOT write C++?
 
> Oi... un po' pi? di rispetto. Sei qui per dare supporto o per esibire la
> tua cafonaggine?
 
Sorry, I did not realize you are the same alessio211734 who posted the
original question. I thought you are trying to propose some kind of
solution to him instead.
 
> L'esempio ? mio e se voglio non usare string, non lo uso.
 
But you already did use it!
 
trunc = (((string)s).length() + 1 > sizeof s_vector) ? false :
^^^^^^
 
Cheers
Paavo
drew@furrfu.invalid (Drew Lawson): Jan 13 01:31PM

Discussing a bit of code with a coworker, there was talk about doing
a constructor of this form:
 
foo::foo(Params params)
{
if ( !SetupFromParamsWorks(params) )
{
*this = foo();
}
}
 
There are several obvious bad aspects to this, but the question
that I couldn't answer was whether
*this = foo();
is even legal in a constructor.
 
It feels like it should not be, but I cannot come up with a good
reason why.
 
--
Drew Lawson | Though it's just a memory,
| some memories last forever
Victor Bazarov <v.bazarov@comcast.invalid>: Jan 13 09:04AM -0500

On 1/13/2015 8:31 AM, Drew Lawson wrote:
> is even legal in a constructor.
 
> It feels like it should not be, but I cannot come up with a good
> reason why.
 
I see no reason why it would not be legal. While the object referred to
by (*this) is not fully constructed until the c-tor ends, calling the
assignment operator is legal, it's just a function. Constructing
another object (a temporary) is also legal. Unless some trickery is
attempted in the assignment operator, which is not indicated here, the
code is OK, methinks.
 
V
--
I do not respond to top-posted replies, please don't ask
Paavo Helde <myfirstname@osa.pri.ee>: Jan 13 11:28AM -0600

drew@furrfu.invalid (Drew Lawson) wrote in news:m936n7$8ca$1
> is even legal in a constructor.
 
> It feels like it should not be, but I cannot come up with a good
> reason why.
 
This is kosher, assuming SetupFromParamsWorks() leaves the object in a
state which the assignment operator can cope with. If the object remains
in some half-constructed state (uninitialized pointers, etc), but the
assignment operator assumes a valid state (as it normally does), then of
course problems may arise.
 
Cheers
Paavo
drew@furrfu.invalid (Drew Lawson): Jan 13 06:15PM

In article <XnsA421C6216E621myfirstnameosapriee@216.196.109.131>
 
>This is kosher, assuming SetupFromParamsWorks() leaves the object in a
>state which the assignment operator can cope with.
 
Thanks all. It struck me that I rarely deal with temps in a
constructor. (I go for a factory type method when that is a need.)
So I never got a feel for any extra restrictions that might apply.
 
 
--
Drew Lawson While they all shake hands
and draw their lines in the sand
and forget about the mess they've made
ram@zedat.fu-berlin.de (Stefan Ram): Jan 10 08:43PM

>in the rest of the exercise description. If you've never written a
>grammar, skip this exercise for now, it's probably not terribly important.
 
But then, I have sometimes encountered questions in the
newsgroup, where someone asks how to write a parser for some
input, but fails to specify the exact rules for the input.
 
My usual reply is: »Give me a grammar for the input, then I
can write a parser.« But every time the questioner can't
write a grammar, so he can't get a parser.
 
Often, people then resort to an example of the input. But an
example usually does not completely specifies the set of all
possible inputs and their structure, so one can't write a
parser for it that will also parse whatever other inputs the
questioner had in mind. When one writes a parser for the
example, the usual answer would be: »Yes, your parser parses
the example I gave, but I also want ...«.
 
At some point in his education, a programmer must learn how
to write a grammar and a parser, but it does not have to be
at during the first year.
 
In my teaching, I have indeed observed that EBNF is too
difficult for my students (usually beginners), so now I
use syntax diagrams, even simplified syntax diagrams.
bleachbot <bleachbot@httrack.com>: Jan 11 09:25PM +0100

ram@zedat.fu-berlin.de (Stefan Ram): Jan 06 05:16PM

>As a developer, it's frustrating. It's always more fun to use the
>latest and greatest tools. But the business world and reality often
>get in the way.
 
I teach C++ in adult evening classes, and I have reasons to
teach C++ (and not cancelled-and-replaced languages like
C++11 (?), C++03, C++98, C++ARM, C++preARM, or C with classes):
 
First, I deem to teach the students for the future, not the past.
 
Second, sometimes, student ask me about what's new in C++.
 
Third, IIRC Bjarne Stroustrup recommends to teach C++ (and
not the cancelled-and-replaced languages like C++11 (?),
C++03, C++98, C++ARM, C++preARM, or C with classes):
 
And I just was revising the lesson, where I explain what the
current norm for C++ is. It is this lesson (in German):
 
http://www.purl.org/stefan_ram/pub/c++_grundbegriffe
 
I do and did not know whether ISO/IEC 14882:2014(E) is
already in force, so how can I tell my students what the
currently valid norm is?
 
That was the reason I asked here.
ram@zedat.fu-berlin.de (Stefan Ram): Jan 06 05:27PM

>>First, I deem to teach the students for the future, not the past.
>That's useless. You should teach them so they can get jobs
>today, not next century.
 
Go to an 18 hour adult evening C++ course for beginners.
Get a job in C++ programming. I see.
ram@zedat.fu-berlin.de (Stefan Ram): Jan 13 06:01PM

>Oi... un po' più di rispetto. Sei qui per dare supporto o per esibire la
>tua cafonaggine?
 
Gli altri lettori di questo gruppo forse non capiscono questo!
Quindi, vorrei spiegare:
 
cafonaggine: l'essere cafone
 
cafone: maleducato, volgare, di cattivo gusto.
scott@slp53.sl.home (Scott Lurndal): Jan 13 02:43PM

> X[N] stuff;
> public:
> static size_t const StuffSize =3D sizeof(stuff);
 
Technically, this requires a corresponding declaration
in a compilation unit. Most optimizing compilers will
never generate a reference to the declaration, thus you'll
not get a linker error. Try compiling without -O, however
and the results may differ.
Puppet_Sock <puppet_sock@hotmail.com>: Jan 13 06:26AM -0800

On Wednesday, December 24, 2014 at 7:41:20 AM UTC-5, Qu0ll wrote:
[snips]
> Definitely not required. You will *never* understand C++ no matter how many
> other languages you study first!
[snips]
 
Usually I don't have to explain to my cubicle mates why I'm laughing at my desk.
 
Usually, but not always.
scott@slp53.sl.home (Scott Lurndal): Jan 06 05:19PM

> teach C++ (and not cancelled-and-replaced languages like
> C++11 (?), C++03, C++98, C++ARM, C++preARM, or C with classes):
 
> First, I deem to teach the students for the future, not the past.
 
That's useless. You should teach them so they can get jobs
today, not next century.
 
tschuss
Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Jan 06 10:47AM -0700

On Mon, 5 Jan 2015 23:11:04 -0800 (PST), 嘱 Tiib <ootiib@hot.ee>
wrote:
 
>sometimes. If there are no development going on then it is frozen product.
>You can milk money for decade and half from frozen product but one day
>the milking itself becomes too expensive.
 
"Conservative" doesn't necessarily mean stagnant. Things get
upgraded, but not as fast as some might like.
 
>or try to achieve successes? Sure way to not fail is to do nothing,
>doing anything may bring failures. Sure way to not succeed is to do
>nothing, doing anything may bring successes. ;)
 
Businesses have an annoying habit of being risk-averse. And it's
possible to avoid failure and try to succeed at the same time. Most
successful businesses have been doing it for years.
 
 
>Business world pays best money to successful engineers who follow
>progress and shitty money to frustrated engineers who fear to
>fail. The problems can be of your own making. ;)
 
Not necessarily. If you haven't read _The Difference Between God and
Larry Ellison_, you really should. It talks about how Ingres had a
better query language ("Quel") than Oracle's SQL, but Oracle ran on
more platforms and had better marketing, so Oracle became #1 in the
database market. And then there's MS-DOS. Did Microsoft take over
the world because it had the best operating system?
 
I have to ask: How long have you been a programmer?
 
My guess is that once you've been at this for 20 or 30 years, you'll
have seen some of what I'm talking about. If you can spend all of
those 20 or 30 years on the cutting edge, using the latest tools, then
you're exceptionally good. The world needs a new word processor,
among other things, and you might just be the person to do it...
 
Louis
Ian Collins <ian-news@hotmail.com>: Jan 07 07:58AM +1300

Scott Lurndal wrote:
 
> The third party libraries we link with aren't qualified by their
> vendor for anything other than certain versions of GCC that don't
> include any with full C++11 support, much less C++14.
 
Whether to upgrade tools really comes down to two things: how well the
tool vendor supports the process and how much you trust your release
process. Some vendors (such as Sun/oracle) go out of their way to
provide compatibility modes which support compiling existing code with
the newer compiler. This decouples the compiler upgrade from code
changes. If your release process is up to the task, the costs of a
compiler upgrade can be minimised.
 
--
Ian Collins
scott@slp53.sl.home (Scott Lurndal): Jan 06 02:28PM

>used for some time (like gcc 4.7 or clang 3.4) can give valuable
>hints what is wrong with your code. Clang even comes bundled with some
>great tools.
 
from a typical project makefile:
 
PHONY: cppcheck
cppcheck:
${CPPCHECK} *.cpp
scott@slp53.sl.home (Scott Lurndal): Jan 07 02:54PM


>> 39 years, in my case.
 
>39 years? That explains your intransigent stubbornness then. Old dog
>new tricks innit.
 
Actually, "old dog" and "experience" are probably closer. I've no
problem using learning new tricks when necessary. Change for the
sake of change isn't a new trick, just a waste of time.
 
(started programming at 14 on a B5500, so not so old, either :-).
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 06 08:19PM

On Tue, 2015-01-06, 嘱 Tiib wrote:
> On Tuesday, January 6, 2015 8:27:16 AM UTC+2, Louis Krupp wrote:
...
> or try to achieve successes? Sure way to not fail is to do nothing,
> doing anything may bring failures. Sure way to not succeed is to do
> nothing, doing anything may bring successes. ;)
 
Well said.
 
In my experience (or opinion) that's a pretty common disease in
organizations. And as a programmer, it seems to be easy to get
sucked into it, overestimating the risks and the effects of a
potential bug, and eventually getting to the stage where you take
pride in how carefully you can get very little work done ...
 
Disclaimer: I also hate it when people create artificial problems
and risks for themselves, as if excitement is more important than
getting things done. That's the other extreme, and it's not what
I'm advocating.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Jan 06 01:21PM -0700

On Tue, 06 Jan 2015 17:19:27 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:
 
 
>> First, I deem to teach the students for the future, not the past.
 
>That's useless. You should teach them so they can get jobs
>today, not next century.
 
The two aren't mutually exclusive.
 
A C++ course that *didn't* teach the latest and greatest would be
missing something; it's the difference between training and
education. On the other hand, since the language is evolving, an
instructor would be remiss in not telling students that not all
features are supported by all compilers, and that they can expect to
have to work within some of those constraints -- at least for a while.
 
As more and more people who understand the newer features move into
the profession and into technical leadership positions, institutions
adopt newer standards as well.
 
Things might not change as rapidly as everyone might like, and there's
always a gap between what's new and what's commonly accepted, but if
nobody pushed for change, it wouldn't happen at all.
 
Louis
me <noone@all.net>: Jan 11 11:54PM

On Sun, 11 Jan 2015 12:25:52 -0800, BV BV wrote:
 
> http://www.islamhouse.com/401719/en/en/articles/
Muhammad_Peace_be_Upon_Him:_A_Role_Model_for_a_New_Millennium
 
 
The world will be a much safer place once islam is wiped from the face of
the planet. The idea that islam is a religion of peace and love is
insulting to people of real intelligence. The lack of action on the part
of muslems who tolerate, and I fear (endorse) radicalism, speaks for
itself.
"Öö Tiib" <ootiib@hot.ee>: Jan 11 04:20PM -0800

> insulting to people of real intelligence. The lack of action on the part
> of muslems who tolerate, and I fear (endorse) radicalism, speaks for
> itself.
 
Isn't radicalism the thing when someone calls to wipe something that he
dislikes from the face of planet? First characteristic of any fundamentalist
view is that it is impossible to distinguish it from parody of itself. :P
yakup.1907.730@gmail.com: Jan 10 02:32PM -0800

c++ programlama kitapları 0 dan baslangıs seviyesin itibaren 75 den fazla kitap arsivi
arsiv1
http://bc.vc/HTmutu
veya
http://bc.vc/Ox8uMu
arsiv 2
http://bc.vc/io0GSG
veya
http://bc.vc/f5dgmg
arsıv3
http://bc.vc/OQdXgX
veya
http://bc.vc/skCSFS
arsiv 4
http://bc.vc/JbCIKI
veya
http://bc.vc/F6uHKH
her hersivde birbirinde farklı c++ proglama ilgili kaynaklar mevcutur
kulanmaıcı tafsiye ederim
ücretsiz bu kaynaklardan memlun kalacagınıcı garanti ediyorum
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)