cr88192
5/28/2011 9:48:00 AM
On 5/28/2011 12:08 AM, io_x wrote:
> are you sure your langages are better than some type of macro-assembly?
>
apologies in advance for taking what seems to be troll bait...
but, anyways...
the main advantages of C and C++ over macro-assembly is that these
languages are far more readily portable (between OS's and CPU
architectures), whereas most macro-assemblers are still often very
specific to a particular OS and/or architecture, and, most often, to a
specific macro-assembler.
so, in this sense, they are "better"...
now, as for C vs C++, or something being "universally better", I don't
personally believe any such "universal betterness" exists.
ASM has its uses, and C also has its own uses. neither is ideal for what
the other is strong at.
much like, the strength of C++ is that it has lots of features...
and the strength of C is that it does not have these features...
to clarify:
C++ has lots of features which make programming in C++ arguably somewhat
nicer than programming in C.
but, most of these same features being absent from C, give it a much
simpler syntax, meaning it is much easier to use tools with it (either
having tools which automatically generate special-purpose code, or which
effectively parse the source code to mine information for use for other
purposes, such as gluing against custom HLL's, implementing reflection
mechanisms, ...).
another area is that C generally has a more standardized ABI than C++,
meaning that mixing code from different compilers is a little less
liable to blow up in ones' face.
but, for example, one can do things like Class/Instance OO or generic
containers or similar in C++, and not have it look so much like an
awkward and nasty mess. whereas in C, it is more common to use raw
structs and function pointers to do OO style tasks, and typically any
"container" style tasks have the logic written clean for the specific
type of object being contained (typically there is no real clear
separation between the "container" and "the thing being contained").
that, or one resorts to using dynamic-type checking for implementing
their containers (this is its own matter, along with using a garbage
collector, ...).
so, where a C++ programmer may think "std::sort", a C programmer may
resort to memorizing the quicksort algorithm and typing it out
on-demand, or a C++ user using "std::hash_map" vs a C programmer
proceeding to write out the logic for hashing and fetching values, ...
but, what is "best" is rarely as clear-cut as people make it out to be.
much like many people think Java is one of the best languages around,
and some of us can't bring ourselves to try to choke it down... it has
some merits (fairly clean language design, and many interesting
VM-related capabilities) and some drawbacks (such as being awkward to
use and often needing far more code to accomplish the same task, as well
as being rather awkward to use in mixed-language projects with C and
C++...).
and, meanwhile, I have my own scripting HLL (BGBScript), which sort of
resembles a mix of JavaScript, ActionScript, Java and a few other
languages (some other influences have included Scheme, Self, and
Erlang), and tries to offer a fairly transparent FFI (its main feature
at present is that it is smart enough to largely interface directly with
C-based APIs with little or no special treatment).
my "general" goal has then been an FFI no more particularly difficult to
use than C++'s 'extern "C"' mechanism (take, for contrast, the piles of
nasty cruft needed to make things like JNI work).
a standing goal though is to get around to making it more symmetric, so
that the FFI transparently goes both ways (transparent C->BS calls, in
addition to transparent BS->C calls...).
yes... it also generally (mostly) works on raw pointers and C structs
and similar as well.
but, its drawbacks are that the implementation is notably far from being
"mature" (just how often do I have to debug things?...). and, as well, I
am probably the *only* person who uses it, so it doesn't have the same
sort of status or popularity as say, Java or Lua or Python or ...
(Python being IMO one of the few languages which would make me much
rather use Java instead...).
but, in this case, what is "best" likely depends more on personal
preferences and what one is doing with it, than any sort of empirical
measure.
or such...