SasQ said:
Dnia Sun, 18 Mar 2007 00:31:43 -0500, JohnQ napisa³(a):
What does "napisal(a)" mean?
"wrote" in Polish.
Yes. In the post from 2007-03-16 23:40.
How much easier would C++ be if it made that assumption.
I don't know, but I think if C++ assume that bytes are always 8-bit,
people coding for the platform where bytes are more than 8 bits
would protest or can't use C++ for those platforms.
Well what if "Small C++" would target only 8-bits/byte hardware?
Noone's stopping you
If you don't want to support platforms with
other-than-8-bit bytes, feel free. C++ creators have had other aims.
C++ wants to be "everywhere"
Yes. So does Internet
And maybe you could write your posts for
this group only because of that creators of Internet protocols
didn't made any platform-specific assumptions. Where they want
8-bit and no more no less, they require OCTET. Mail protocols
are designed to send 7-bit characters and 8-bit also, because
they don't assume how many bits the characters should have.
I heard there were suggestions to introduce new built-in data types
to C++0x for programmers who want presice bit sizes: byte, word,
dword, qword etc. but I don't know the further story of that ideas.
Some compilers offer an extensions like _int16, _int32, _int64 etc.
for the same reason, but they're non-standard, so the code would
compile only on those compilers supporting those extensions.
What did you just say? I'm all for non-nebulousness. If even
the bits and "bytes" haven't been standardized, we're in
loads-O-trouble!
[snip]
Is it anymore clrear now?
It didn't answer the question of how specifying that bytes have 8 bits can
simplify compiler implementation and to what degree. A few more simplifying
assumptions and maybe even _I_ would be able to implement a compiler.
It's good to know well the tools used. You can't say "I don't
have to be a welder to weld".
But I want to gas weld only and I'm sure I'll never want or need to arc
weld. If so, then the super duper weld-O-matic is overkill for my purposes.
Suck for who?
I appreciate that I can write code in C++ and compile it on
a platform where bytes are 9-bits
Sounds like a lot of effort for fringe cases.
Hard for you doesn't mean hard for everyone.
It wasn't hard for me. But surely for most people who can't sort out the
chaff from the wheat in the language, it must be nightmarish.
I don't like managers trying to stuff their hands into my code.
If they don't trust me, let they write that code by theirselves ;J
See, that's exactly the problem! I don't want a dozen cowboy coders doing
their own things all their own ways and then have to maintain that mess.
The more features language has, it always be the ones
who don't understand it well and use it a wrong way.
Like using a preprocessor to do obfuscating macros.
Using a type casting to fiddling bits inside objects.
Using inheritance for everything only to reuse code.
If you use a lighter without care, you can burn yourself.
Stroustrup said that in C you could shoot your foot if
you did something without care. C++ protects you from
aiming on your leg, but if you really want, it won't
stop you and you can shoot out all your leg then.
It's the "Trust the programmer" rule.
Yes, in some cases D's template syntax is better. But it's not
better in all the cases and there are cases where C++ wins.
C++ and D has simply a different set of features. Choose the
one you need for a particular job
Sign of what?
I knew at least five women who learned C++
with me on a university. And they understand it well
Signs that a C++ is an ultra gearhead type of which most women are not.
Though there probably would be a few more (maybe 10 instead of the 5 you saw
once) with a language more easily used at a higher level since women have
the potential to be better designers IMO, partly because they think more
abstractly (umm, I think they do... once I figure out C++, I'll tackle
figuring out the other thing
).
Strange, I spend more time in the problem space, on designing
and thinking about the program structure. Then it's easier to
sit down to the keyboard and code it in.
And once you begin doing that implementation, you mind quickly reverts to
thinking about all the corner cases and the like. The more features a
language has and the more of them you use, the more time your mind spends in
the solution space.
I use printf() (temporarily). Yep, I think C++ IO is obsolete
at the outset. C'mon now, it can't even decide on what a byte
is, and you want me to accept what it considers an input/output
to be. Surely you jest.
C'mon now, C lays on the same assumptions as C++
BTW try this one with printf:
class SomeClass {
//..some stuff
};
SomeClass someObject;
printf("what '%' code should be placed here?
", someObject);
C++ IO is object oriented. It HAVE TO be, because if you can
create new data types, you should also be able to use it with
IO the same way as built-in types. With printf you can't, because
it has '%' codes only for built-in types.
There's another reason behind using iostreams instead of printf:
iostream output operators are matched at compile time and in a
machine code there'll be only calls for the proper functions to
handle only proper data types, and nothing else. OTOH printf
have to parse format string at run-time every time it's called,
and choose the proper branch of execution for the particular type.
All that branches will be there in executable even if you print
only one type in a whole program. In a case of iostreams, there
could be only the ones used [code of the operator<<'s for the
used types only].
In this day of the GUI, how much do you need Std IO anyway.
No offence, I didn't mean anything bad. I've only said that you
might probably not understand that well the features of C++ you
found hard or unnecessary.
Thoroughly evaluated and trying to avoid based on that evaluation. It was a
lot easier at first to use C++ blindly, but after years of using it and
realizing what is required to get that funcitonality, it becomes easy to
reject.
It's nothing bad, I've been there too
and thought that C++ features unnecessary or strange. But if you
understand the reason why that features are where they are, and
what rationale directed C++ inventors, you start to see why that
features are good and are there for a reason.
If you haven't read Stroustrup's books yet, I encourage you
to do it. "The C++ Programming Language" is good for learning
C++ to understand it well and use it the proper way. "The C++
Design and Evolution" will show you the rationale behind every
language feature, how it evolved with time, what were the other
options and why the current ones had been choosed. And maybe it
will help you with making decissions and designing your
"Small C++" too
Surely they would if I was producing such a language. I started with D&E in
the early nineties. That and Coplien's book moved me from C to C++. I've
read at least part of most C++ texts (the parts that interest me). After a
decade and a half, some major parts of the standard are getting a bit long
in the tooth, along with the rationales for some of them. C++ is overly
general probably rather than "general purpose". It takes generality to the
extreme at the expense of being immediately useful in a lot of domains and
it's evolution is slow for the same reason. It's easy to say it is "a good
language" if you already know it and have used it for a decade, but
obviously that long training path is not a good goal if it can be avoided.
Again, there's probably things that could be done with a new language that
would make it greatly more accessible than C++ which is hampered with
backward compatibility. If there were such a new designed-to-be-accessible
language, maybe it would be chosen over C++ where C++ is and isn't now being
chosen.
At some point in a product's lifetime or a software company's evolution,
there may very well be desire to avoid building product on top of someone
else's technology. At one level one may say that programming with
technologies such as MS's COM or .net is banking too much on 3rd party
technology. At another level, one may decide that the decidedly
complex-to-implement features of C++ are too risky to buy into. I'm already
planning aversion to C++ complexity where and when it is practical in
preparation for the future. (I use templates, but not advanced templates and
not the STL, for example. If I can find a way out of them, I'll probably
take it).
John
