Le 17.10.2013 21:57, Miles Fidelman a écrit :
berenger.morel@neutralite.org wrote:
Le 16.10.2013 17:51, Jerry Stuckle a écrit :
I only know few people who actually likes them :)
I liked them too, at a time, but since I can now use standard smart
pointers in C++, I tend to avoid them. I had so much troubles with
them,
so now I only use them for polymorphism and sometimes RTTI.
I hope that someday references will become usable in standard
containers... (I think they are not because of technical problems,
but I
do not know a lot about that. C++ is easy to learn, but hard to
master.)
Good design and code structure eliminates most pointer problems;
proper testing will get the rest. Smart pointers are nice, but in
real time processing they are an additional overhead (and an unknown
one at that since you don't know the underlying libraries).
Depends on the smart pointer. shared_ptr indeed have a runtime cost,
since it maintains additional data, but unique_ptr does not, afaik,
it is made from pure templates, so only compilation-time cost.
You guys should love LISP - it's pointers all the way down. :-)
I do not really like pointers anymore, and this is why I like smart
pointers ;)
So, what you name an OS is only drivers+kernel? If so, then ok. But
some people consider that it includes various other tools which does
not require hardware accesses. I spoke about graphical applications,
and you disagree. Matter of opinion, or maybe I did not used the good
ones, I do not know.
So, what about dpkg in debian? Is it a part of the OS? Is not it a
ring 3 program? As for tar or shell?
Boy do you like to raise issues that go into semantic grey areas :-)
Not specially, but, to say that C has been made to build OSes only, you
then have to determine what is an OS to make the previous statement
useful. For that, I simply searched 3 different sources on the web, and
all of them said that simple applications are part of the OS.
Applications like file browsers and terminal emulators.
Without using the same words for the same concepts, we can never
understand the other :)
No, but I do understand why comparing text is slower than integers on
x86 computers. Because I know that an int can be stored into one
word, which can be compared with only one instruction, while the text
will imply to compare more than one word, which is indeed slower. And
it can even become worse when the text is not an ascii one.
So I can use that understanding to know why I often avoid to use text
as keys. But it happens that sometimes the more problematic cost is
not the speed but the memory, and so sometimes I'll use text as keys
anyway.
Knowing what is the word's size of the SQL server is not needed to
make things work, but it is helps to make it working faster. Instead
of requiring to buy more hardware.
On the other hand, I could say that building SQL requests is not my
job, and to left it to specialists which will be experts of the
specific hardware + specific SQL engine used to build better
requests. They will indeed build better than I can actually, but it
have a time overhead and require to hire specialists, so higher price
which may or may not be possible.
Seems to me that you're more right on with your first statement. How
can one not consider building SQL requests as part of a programmer's
repertoire, in this day and age?
I agree, it is part of programmer's job. But building a bad SQL request
is easy, and it can make an application unusable in real conditions when
it worked fine while programming and testing.
Do you know how
the network works? Do you even know if you're using wired or wireless
networks.
I said, basic knowledge is used. Knowing what is a packet, that
depending on the protocol you'll use, they'll have more or less space
available, to send as few packets as possible and so, to improve
performances.
Indeed, it would not avoid things to work if you send 3 packets where
you could have sent only 2, but it will cost less, and so I think it
would be a better program.
Probably even more than that. For a lot of applications, there's a
choice of protocols available;
Ah, did not thought about that point, too. Technology choice, which is,
imo, part of programmer's job requires understanding of their strong and
weak points.
For now, I should say that knowing the basics of internals allow to
build more efficient softwares, but:
Floating numbers are another problem where understanding basics can
help understanding things. They are not precise (and, no, I do not
know exactly how they work. I have only basics), and this can give
you some bugs, if you do not know that their values should not be
considered as reliable than integer's one. (I only spoke about
floating numbers, not about fixed real numbers or whatever is the name).
But, again, it is not *needed*: you can always have someone who says
to do something and do it without understanding why. You'll probably
make the error anew, or use that trick he told you to use in a less
effective way the next time, but it will work.
And here, we are not in the simple efficiency, but to something which
can make an application completely unusable, with "random" errors.
As in the case when Intel shipped a few million chips that
mis-performed arithmatic operations under some very odd cases.
No need for a problem in the chip. Simply doing things like "0.1f ==
1.0f/10.0f" in a moment you do not take care can cause problems. I think
that compilers warn about that however.
But now, are most programmers paid by societies with hundreds of
programmers?
(and whether you actually mean "developer" vs. "programmer")
I do not see the difference between those words. Could you give me the
nuances please? I still have a lot to learn to understand English for
precise terms.
And, again, just a guess, but I'm guessing the huge percentage of
programmers these days are writing .NET code on vanilla Windows
machines (not that I like it, but it does seem to be a fact of life).
A lot of people also seem to be writing stored SQL procedures to run
on MS SQL.
Windows actually provides a stable environment, very good programming
tools ( visual studio is a really good IDE ), and when you write for it,
you know that most computers will be able to run your program.