Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Why is C++ so popular

Reply
Thread Tools

Why is C++ so popular

 
 
Agnos
Guest
Posts: n/a
 
      10-07-2012
Nick Keighley wrote:
> On Sep 30, 5:57 am, "Jan G" <(E-Mail Removed)> wrote:
>> Nick Keighley wrote:
>>> On Sep 28, 4:56 am, Brian <(E-Mail Removed)> wrote:

>
>>>> If I were to ask software companies what language the program they
>>>> are selling in written in then I have a feeling the answer would be
>>>> either C or C++.

>>
>>> yes but that's just a feeling.

>>
>> Prove it.

>
> I think it's up to the original claimant to backup his statement.


You seem to be keeping track, who's up to bat?

>
>> The poster you responded to "had a feeling" that, well what he
>> said, but you COUNTERED with "yes but that's just a feeling".

>
> it was hint that he should come up with something more than "just a
> feeling". Come up with some hard evidence. I've evidence that Ruby,
> Python and Perl are used in major applications.


Having known all of them, and not being with them anymore, I am bad?

>
>> YOU, Mr., are on THIN ice.

>
> I love it when people threaten me an the internet. What are you
> going to do?


Isn't that your only game: manipulating the facts, and the law is the enemy
of the people and the people are free and all other crap (refrained from
saying what it is) put forth by any regime. Very appropriate topic in "an
election year".

When you go to the polls this year.. ah (!), isn't therein the rub: you
don't have to vote. Or if you go, are you actually "voting for the vote".
Where are the scholars and scholarly works on the subject of this
new-fangled "voting" scheme? Hmm? Hey, don't you worry your ugly little
heads about all that: VOTE! It's just like Dancing with the Stars! Vote and
you will be, .. free? Don't you have the right to vote? Don't you just wake
up every morning, ready for the day, because you have "the right to vote"? A
show of hands please!




 
Reply With Quote
 
 
 
 
Lynn McGuire
Guest
Posts: n/a
 
      10-08-2012
On 10/7/2012 12:39 AM, Agnos wrote:
> Lynn McGuire wrote:
>> On 9/29/2012 11:54 PM, Jan G wrote:
>>> Lynn McGuire wrote:
>>>> On 9/27/2012 4:38 AM, BGB wrote:
>>>>> On 9/27/2012 3:44 AM, Brian wrote:
>>>>>> I have not found an answer to the question why C++ is the most
>>>>>> preferred language. I thought it would be a good question to ask
>>>>>> in this newsgroup that has programmers that have been using C++
>>>>>> for a while. I did read that its popular because it can be
>>>>>> transferred to other
>>>>>> platforms but not everyone has more than one platform.
>>>>>>
>>>>>
>>>>> because it sucks less than the other options?...
>>>>
>>>> +1
>>>>
>>>> Lynn
>>>
>>> Lynn, that you are a newbie to the spiel and that there should not be
>>> anymore newbies, is quite disconcerting.

>>
>> I have been writing software for about 40 years

>
> Can a woman say anything more unattractive?


What a sexist remark !

BTW, I am a 6'1" very bald male ...

Lynn


 
Reply With Quote
 
 
 
 
Mark
Guest
Posts: n/a
 
      10-10-2012
On Fri, 28 Sep 2012 03:56:20 GMT, Brian <(E-Mail Removed)> wrote:

>Nick Keighley <(E-Mail Removed)> wrote:
>> On Sep 27, 9:44 am, Brian <(E-Mail Removed)> wrote:
>>
>>> I have not found an answer to the question why C++ is the most preferred
>>> language. I thought it would be a good question to ask in this newsgroup
>>> that has programmers that have been using C++ for a while.
>>> I did read that its popular because it can be transferred to other
>>> platforms but not everyone has more than one platform.

>>
>> to some extent its momentum, it's popular because it's popular. It's
>> apparent similarity to C probably has some historical significance. As
>> others have noted efficiency and access to the underlying machine is
>> important.
>>
>> I'm curious, why do you care?

>
>I ask myself why should people program in C++ when Visual Basic is easier
>to understand?


I don't find VB easier to understand. It's very verbose and, to me,
the syntax is illogical. But then i've used C++ far more than VB.

>There must be a reason why C++ is chosen when there are many other
>languages to chose from.
>Maybe some people grow up with C and then moved on to C++ and its close to
>what they had used in the past.


True.
--
(\__/) M.
(='.'=) If a man stands in a forest and no woman is around
(")_(") is he still wrong?

 
Reply With Quote
 
Brian
Guest
Posts: n/a
 
      10-10-2012
Mark <(E-Mail Removed)> wrote:
> On Fri, 28 Sep 2012 03:56:20 GMT, Brian <(E-Mail Removed)> wrote:
>
>> Nick Keighley <(E-Mail Removed)> wrote:
>>> On Sep 27, 9:44 am, Brian <(E-Mail Removed)> wrote:
>>>
>>>> I have not found an answer to the question why C++ is the most preferred
>>>> language. I thought it would be a good question to ask in this newsgroup
>>>> that has programmers that have been using C++ for a while.
>>>> I did read that its popular because it can be transferred to other
>>>> platforms but not everyone has more than one platform.
>>>
>>> to some extent its momentum, it's popular because it's popular. It's
>>> apparent similarity to C probably has some historical significance. As
>>> others have noted efficiency and access to the underlying machine is
>>> important.
>>>
>>> I'm curious, why do you care?

>>
>> I ask myself why should people program in C++ when Visual Basic is easier
>> to understand?

>
> I don't find VB easier to understand. It's very verbose and, to me,
> the syntax is illogical. But then i've used C++ far more than VB.
>
>> There must be a reason why C++ is chosen when there are many other
>> languages to chose from.
>> Maybe some people grow up with C and then moved on to C++ and its close to
>> what they had used in the past.

>
> True.


Thanks Mark. Interesting comments.

--
Regards Brian
 
Reply With Quote
 
BGB
Guest
Posts: n/a
 
      10-10-2012
On 10/10/2012 4:54 AM, Mark wrote:
> On Fri, 28 Sep 2012 03:56:20 GMT, Brian <(E-Mail Removed)> wrote:
>
>> Nick Keighley <(E-Mail Removed)> wrote:
>>> On Sep 27, 9:44 am, Brian <(E-Mail Removed)> wrote:
>>>
>>>> I have not found an answer to the question why C++ is the most preferred
>>>> language. I thought it would be a good question to ask in this newsgroup
>>>> that has programmers that have been using C++ for a while.
>>>> I did read that its popular because it can be transferred to other
>>>> platforms but not everyone has more than one platform.
>>>
>>> to some extent its momentum, it's popular because it's popular. It's
>>> apparent similarity to C probably has some historical significance. As
>>> others have noted efficiency and access to the underlying machine is
>>> important.
>>>
>>> I'm curious, why do you care?

>>
>> I ask myself why should people program in C++ when Visual Basic is easier
>> to understand?

>
> I don't find VB easier to understand. It's very verbose and, to me,
> the syntax is illogical. But then i've used C++ far more than VB.
>


yes.

although both C and C++ syntax are still not perfect, they are much
better than VB syntax (which is basically a bit of an ad-hoc mess with
keywords everywhere).


the usual claims to "easier to understand" with very wordy languages has
more to do with the notion that people who are unfamiliar with
programming may assign more semantic meaning to English-like keywords
than to characters on the keyboard.

usually after a short while though, people get used to the characters,
and they no longer are a big issue.

most of the complaining then comes from anti-C-syntax language
designers, who have little better to do apparently than complain about
the braces, semicolons, and the construction of things like the "for()"
loop.


the main issues I have found personally (with C-like syntax) are more that:
the traditional declaration syntax is ambiguous;
the traditional C-cast syntax is ambiguous;
....

typically, the parser knows what it is looking at mostly by relying on
prior type declarations (both C and C++), and prior template
declarations (C++), which in-turn makes the issue that header inclusion
or some direct analogue is required for parsing to work correctly, which
is a hindrance to compiler performance (the major example of this is
that it often takes 500ms to 1000ms or more to compile something, and
much of this is parsing, mostly churning through the headers).


languages like C# have dealt some with this via a few strategies:
declarations are constrained such that modifiers always precede the
type-name, which is moderately fixed-form, which is followed by the
declaration name (this works, but some more advanced cases will still
introduce ambiguities);
the cast syntax takes precedence and the alternate possible
interpretations (such as applying a computed expression) simply can't be
expressed in the syntax (this means pretty much that any call involving
a delegate has to use a variable, which can then be called, among other
limitations).

for example, C# allows:
int *x;

but, at the syntactic level, this can't really be told apart from the
expression:
x*y;

their simple answer: disallow the expression case in this case (not a
big issue in C# as statement-level expressions can't produce a
meaningful value).

this does, however, allow a much faster parser, but at other costs.


ideally, we want the syntax to be entirely able to be parsed without any
reliance on prior declaration context, and with usually around 1-2 token
lookahead and no back-tracking (context adds need for things like
headers, longer lookahead makes the parser linearly slower, and
backtracking can introduce considerably worse and potentially
polynomial-time slowdowns...).

apart from a few edge cases, most of a C-like syntax can be parsed via a
2-token lookahead and without backtracking. (then we can have
parse-times for a typical-sized module in the microsecond range).


another route is to alter the syntax-design itself to eliminate these
ambiguous cases, for example, using more ECMAScript style declarations.
these have the advantage of being unambiguous at the cost of being longer.

for example:
int x, y;
vs:
var x:int, y:int;
or, potentially:
var:int x, y;

or:
MyObjectType *obj;
vs:
var obj:*MyObjectType;

(actually, moving '*' to precede the type was also related to avoiding a
certain number of ambiguities, some related to constructions which don't
have direct C-ish analogues).


as well as moving casts to an alternate syntax.
for example, in my case, I made it so that all casts use "as" or "as!".

say:
p=(void *)ba;
vs:
p=ba as *void;

this latter case, at least, does not significantly increase the length,
but makes it no longer an issue to be like:
i=(obj[name])(2, 3)(4);
without the parser being confused.

more C++ like casts were possible, but I decided against them mostly as
they are kind of longer and more ugly looking.


granted, yes, such a language isn't really C like.

but, yeah, in my case it was more all motivated by design tradeoffs than
by any dislike of C (and most other areas are much more intact).

many designers are more motivated by personal preferences and "style"
than by pragmatics though, so IMO this may be a large part of what leads
to some of the more bizarre syntax designs seen in some languages.

like "language more meant to be useful" rather than "language meant to
embody some set of ideals" or something like that...


>> There must be a reason why C++ is chosen when there are many other
>> languages to chose from.
>> Maybe some people grow up with C and then moved on to C++ and its close to
>> what they had used in the past.

>
> True.
>


 
Reply With Quote
 
Brian
Guest
Posts: n/a
 
      10-11-2012
BGB <(E-Mail Removed)> wrote:
> On 10/10/2012 4:54 AM, Mark wrote:
>> On Fri, 28 Sep 2012 03:56:20 GMT, Brian <(E-Mail Removed)> wrote:
>>
>>> Nick Keighley <(E-Mail Removed)> wrote:
>>>> On Sep 27, 9:44 am, Brian <(E-Mail Removed)> wrote:
>>>>
>>>>> I have not found an answer to the question why C++ is the most preferred
>>>>> language. I thought it would be a good question to ask in this newsgroup
>>>>> that has programmers that have been using C++ for a while.
>>>>> I did read that its popular because it can be transferred to other
>>>>> platforms but not everyone has more than one platform.
>>>>
>>>> to some extent its momentum, it's popular because it's popular. It's
>>>> apparent similarity to C probably has some historical significance. As
>>>> others have noted efficiency and access to the underlying machine is
>>>> important.
>>>>
>>>> I'm curious, why do you care?
>>>
>>> I ask myself why should people program in C++ when Visual Basic is easier
>>> to understand?

>>
>> I don't find VB easier to understand. It's very verbose and, to me,
>> the syntax is illogical. But then i've used C++ far more than VB.
>>

>
> yes.
>
> although both C and C++ syntax are still not perfect, they are much
> better than VB syntax (which is basically a bit of an ad-hoc mess with
> keywords everywhere).
>
>
> the usual claims to "easier to understand" with very wordy languages has
> more to do with the notion that people who are unfamiliar with
> programming may assign more semantic meaning to English-like keywords
> than to characters on the keyboard.
>
> usually after a short while though, people get used to the characters,
> and they no longer are a big issue.
>
> most of the complaining then comes from anti-C-syntax language designers,
> who have little better to do apparently than complain about the braces,
> semicolons, and the construction of things like the "for()" loop.
>
>
> the main issues I have found personally (with C-like syntax) are more that:
> the traditional declaration syntax is ambiguous;
> the traditional C-cast syntax is ambiguous;
> ...
>
> typically, the parser knows what it is looking at mostly by relying on
> prior type declarations (both C and C++), and prior template declarations
> (C++), which in-turn makes the issue that header inclusion or some direct
> analogue is required for parsing to work correctly, which is a hindrance
> to compiler performance (the major example of this is that it often takes
> 500ms to 1000ms or more to compile something, and much of this is
> parsing, mostly churning through the headers).
>
>
> languages like C# have dealt some with this via a few strategies:
> declarations are constrained such that modifiers always precede the
> type-name, which is moderately fixed-form, which is followed by the
> declaration name (this works, but some more advanced cases will still
> introduce ambiguities);
> the cast syntax takes precedence and the alternate possible
> interpretations (such as applying a computed expression) simply can't be
> expressed in the syntax (this means pretty much that any call involving a
> delegate has to use a variable, which can then be called, among other limitations).
>
> for example, C# allows:
> int *x;
>
> but, at the syntactic level, this can't really be told apart from the expression:
> x*y;
>
> their simple answer: disallow the expression case in this case (not a big
> issue in C# as statement-level expressions can't produce a meaningful value).
>
> this does, however, allow a much faster parser, but at other costs.
>
>
> ideally, we want the syntax to be entirely able to be parsed without any
> reliance on prior declaration context, and with usually around 1-2 token
> lookahead and no back-tracking (context adds need for things like
> headers, longer lookahead makes the parser linearly slower, and
> backtracking can introduce considerably worse and potentially
> polynomial-time slowdowns...).
>
> apart from a few edge cases, most of a C-like syntax can be parsed via a
> 2-token lookahead and without backtracking. (then we can have parse-times
> for a typical-sized module in the microsecond range).
>
>
> another route is to alter the syntax-design itself to eliminate these
> ambiguous cases, for example, using more ECMAScript style declarations.
> these have the advantage of being unambiguous at the cost of being longer.
>
> for example:
> int x, y;
> vs:
> var x:int, y:int;
> or, potentially:
> var:int x, y;
>
> or:
> MyObjectType *obj;
> vs:
> var obj:*MyObjectType;
>
> (actually, moving '*' to precede the type was also related to avoiding a
> certain number of ambiguities, some related to constructions which don't
> have direct C-ish analogues).
>
>
> as well as moving casts to an alternate syntax.
> for example, in my case, I made it so that all casts use "as" or "as!".
>
> say:
> p=(void *)ba;
> vs:
> p=ba as *void;
>
> this latter case, at least, does not significantly increase the length,
> but makes it no longer an issue to be like:
> i=(obj[name])(2, 3)(4);
> without the parser being confused.
>
> more C++ like casts were possible, but I decided against them mostly as
> they are kind of longer and more ugly looking.
>
>
> granted, yes, such a language isn't really C like.
>
> but, yeah, in my case it was more all motivated by design tradeoffs than
> by any dislike of C (and most other areas are much more intact).
>
> many designers are more motivated by personal preferences and "style"
> than by pragmatics though, so IMO this may be a large part of what leads
> to some of the more bizarre syntax designs seen in some languages.
>
> like "language more meant to be useful" rather than "language meant to
> embody some set of ideals" or something like that...
>
>
>>> There must be a reason why C++ is chosen when there are many other
>>> languages to chose from.
>>> Maybe some people grow up with C and then moved on to C++ and its close to
>>> what they had used in the past.

>>
>> True.
>>


You wrote about C++ C and C# of those languages which one do you use to
write programs?

The 'BASIC' language of the late 1970's was very messy and a nightmare to
try and follow the flow of the program unless you wrote very short
programs. VB is a more structured language and because of that it still had
many programmers. But you are right about it being messy as there are many
over sized keywords. So I am currently studying C++ as an alternative to
Visual Basic which I have mainly used in the pass.

Maybe in the future someone will create a programming language that
everyone's happy with.

--
Regards Brian
 
Reply With Quote
 
BGB
Guest
Posts: n/a
 
      10-11-2012
On 10/11/2012 10:36 AM, Brian wrote:
> BGB <(E-Mail Removed)> wrote:
>> On 10/10/2012 4:54 AM, Mark wrote:
>>> On Fri, 28 Sep 2012 03:56:20 GMT, Brian <(E-Mail Removed)> wrote:
>>>
>>>> Nick Keighley <(E-Mail Removed)> wrote:
>>>>> On Sep 27, 9:44 am, Brian <(E-Mail Removed)> wrote:
>>>>>
>>>>>> I have not found an answer to the question why C++ is the most preferred
>>>>>> language. I thought it would be a good question to ask in this newsgroup
>>>>>> that has programmers that have been using C++ for a while.
>>>>>> I did read that its popular because it can be transferred to other
>>>>>> platforms but not everyone has more than one platform.
>>>>>
>>>>> to some extent its momentum, it's popular because it's popular. It's
>>>>> apparent similarity to C probably has some historical significance. As
>>>>> others have noted efficiency and access to the underlying machine is
>>>>> important.
>>>>>
>>>>> I'm curious, why do you care?
>>>>
>>>> I ask myself why should people program in C++ when Visual Basic is easier
>>>> to understand?
>>>
>>> I don't find VB easier to understand. It's very verbose and, to me,
>>> the syntax is illogical. But then i've used C++ far more than VB.
>>>

>>
>> yes.
>>
>> although both C and C++ syntax are still not perfect, they are much
>> better than VB syntax (which is basically a bit of an ad-hoc mess with
>> keywords everywhere).
>>
>>
>> the usual claims to "easier to understand" with very wordy languages has
>> more to do with the notion that people who are unfamiliar with
>> programming may assign more semantic meaning to English-like keywords
>> than to characters on the keyboard.
>>
>> usually after a short while though, people get used to the characters,
>> and they no longer are a big issue.
>>
>> most of the complaining then comes from anti-C-syntax language designers,
>> who have little better to do apparently than complain about the braces,
>> semicolons, and the construction of things like the "for()" loop.
>>
>>
>> the main issues I have found personally (with C-like syntax) are more that:
>> the traditional declaration syntax is ambiguous;
>> the traditional C-cast syntax is ambiguous;
>> ...
>>
>> typically, the parser knows what it is looking at mostly by relying on
>> prior type declarations (both C and C++), and prior template declarations
>> (C++), which in-turn makes the issue that header inclusion or some direct
>> analogue is required for parsing to work correctly, which is a hindrance
>> to compiler performance (the major example of this is that it often takes
>> 500ms to 1000ms or more to compile something, and much of this is
>> parsing, mostly churning through the headers).
>>
>>
>> languages like C# have dealt some with this via a few strategies:
>> declarations are constrained such that modifiers always precede the
>> type-name, which is moderately fixed-form, which is followed by the
>> declaration name (this works, but some more advanced cases will still
>> introduce ambiguities);
>> the cast syntax takes precedence and the alternate possible
>> interpretations (such as applying a computed expression) simply can't be
>> expressed in the syntax (this means pretty much that any call involving a
>> delegate has to use a variable, which can then be called, among other limitations).
>>
>> for example, C# allows:
>> int *x;
>>
>> but, at the syntactic level, this can't really be told apart from the expression:
>> x*y;
>>
>> their simple answer: disallow the expression case in this case (not a big
>> issue in C# as statement-level expressions can't produce a meaningful value).
>>
>> this does, however, allow a much faster parser, but at other costs.
>>
>>
>> ideally, we want the syntax to be entirely able to be parsed without any
>> reliance on prior declaration context, and with usually around 1-2 token
>> lookahead and no back-tracking (context adds need for things like
>> headers, longer lookahead makes the parser linearly slower, and
>> backtracking can introduce considerably worse and potentially
>> polynomial-time slowdowns...).
>>
>> apart from a few edge cases, most of a C-like syntax can be parsed via a
>> 2-token lookahead and without backtracking. (then we can have parse-times
>> for a typical-sized module in the microsecond range).
>>
>>
>> another route is to alter the syntax-design itself to eliminate these
>> ambiguous cases, for example, using more ECMAScript style declarations.
>> these have the advantage of being unambiguous at the cost of being longer.
>>
>> for example:
>> int x, y;
>> vs:
>> var x:int, y:int;
>> or, potentially:
>> var:int x, y;
>>
>> or:
>> MyObjectType *obj;
>> vs:
>> var obj:*MyObjectType;
>>
>> (actually, moving '*' to precede the type was also related to avoiding a
>> certain number of ambiguities, some related to constructions which don't
>> have direct C-ish analogues).
>>
>>
>> as well as moving casts to an alternate syntax.
>> for example, in my case, I made it so that all casts use "as" or "as!".
>>
>> say:
>> p=(void *)ba;
>> vs:
>> p=ba as *void;
>>
>> this latter case, at least, does not significantly increase the length,
>> but makes it no longer an issue to be like:
>> i=(obj[name])(2, 3)(4);
>> without the parser being confused.
>>
>> more C++ like casts were possible, but I decided against them mostly as
>> they are kind of longer and more ugly looking.
>>
>>
>> granted, yes, such a language isn't really C like.
>>
>> but, yeah, in my case it was more all motivated by design tradeoffs than
>> by any dislike of C (and most other areas are much more intact).
>>
>> many designers are more motivated by personal preferences and "style"
>> than by pragmatics though, so IMO this may be a large part of what leads
>> to some of the more bizarre syntax designs seen in some languages.
>>
>> like "language more meant to be useful" rather than "language meant to
>> embody some set of ideals" or something like that...
>>
>>
>>>> There must be a reason why C++ is chosen when there are many other
>>>> languages to chose from.
>>>> Maybe some people grow up with C and then moved on to C++ and its close to
>>>> what they had used in the past.
>>>
>>> True.
>>>

>
> You wrote about C++ C and C# of those languages which one do you use to
> write programs?
>


most of my code is C, followed by C++, followed by the language I was
describing (essentially a custom designed script language).

different parts are written in different languages, and it seems fairly
important that they all be able to play along fairly well.


> The 'BASIC' language of the late 1970's was very messy and a nightmare to
> try and follow the flow of the program unless you wrote very short
> programs. VB is a more structured language and because of that it still had
> many programmers. But you are right about it being messy as there are many
> over sized keywords. So I am currently studying C++ as an alternative to
> Visual Basic which I have mainly used in the pass.
>


yep.

> Maybe in the future someone will create a programming language that
> everyone's happy with.
>


could be, but at least in the near-term, not very likely.


very possibly it would require a language which can operate in a number
of modes, for example:
1, a non-hosted C-like mode, where only functionality which can be
implemented directly on the underlying hardware is supported;
2, a hosted C like mode, mostly intended for systems software and libraries;
3, a full-featured natively compiled mode, basically serving a similar
role to C++;
4, a VM managed mode, where it compiles mostly to bytecode images and
these are run (more like the JVM and .NET), which gain CPU portability
at the cost of a much higher increase in the need for support
infrastructure;
5, a dynamically compiled mode, where things are loaded directly from
source and may be compiled from short code-fragments at runtime (more
like languages like JavaScript, Python, Lua, Ruby, PHP, ...).

as-is, there are no languages which effectively cover the entire domain.

C does best in modes 1 and 2 (it can be used in mode 3, but this is
where some people start complaining);
C++ does well in 2 and 3 (and C++/CLI can partly cover 4);
Java is pretty much solely usable in 4;
C# mostly covers 4, but partially covers 5.
mode 5 is mostly off by itself.

ActionScript was more of a mode 4 language. it had descended from
JavaScript, but had lost a lot of mode-5 capabilities (for example, its
"eval" was mostly limited to things like arithmetic expressions and
similar, ...).


C and C++ generally start to show nasty edges in mode 4, and trying to
use C in mode 5 is a bit of a mess (something more like JavaScript is
much more preferable here).

mode 5 benefits greatly from ability to handle fragmentary code and
having very fast compile times, neither of which are natural to C (in
contrast, for statically compiled code, how long the code takes to
compile is much less important, apart maybe from the annoyance of a
programmer waiting many minutes for their program to recompile). in
mode-5 usage, slow compile times can adversely effect application
performance (say, the program takes a big hit whenever anyone calls
"eval()" or similar, worse if they do it in a loop somewhere).


often the tradeoffs differ as well:
modes 1 and 2 generally leave a preference for a "try to handle
everything gracefully and keep things running" approach to error
handling (so, things like error codes are a more common strategy);
modes 3 and 4 generally leave a strong preference for a "die fast and
die hard" strategy for error handling (the assumption is that a critical
problem often represents something going wrong in the application, which
needs to be fixed);
mode 5 generally prefers a much "softer" approach to error handling,
typically giving debugging messages and trying to make things no-op
(consider just how annoying it would be, say, if FireFox died hard every
time there was a buggy piece of JS code on a website?...).

in my game project, the code breakdown is more like:
1: not used (usually we only see this in OS kernel/driver code and
things like the C runtime);
2: generally plain C;
3: generally tooled-up C, and some C++;
4&5: my script language (BGBScript), previously some Java was used, but
BS has largely replaced it (design-wise, BS is largely a mode-5
language, which has expanded some into mode-4 territory).

currently, I don't have a C compiler for the bytecode VM (would be mode
4), nor a native compiler for BS (to allow mode 3).

the C FFI is designed mostly to allow easy interfacing in these
configurations:
mode-3 C <-> mode-4 BS;
mode-5 BS -> mode-3 C.

(it is hard to effectively handle calls from statically-compiled C code
to BS code which was probably compiled via an "eval" call or similar, so
this generally isn't done, but it is much easier to allow easy calls
from C into statically-compiled VM images, since in this case both exist
with a discrete "compile time", it is possible to spit out some
trampolines and similar to bridge the languages).

BS will have a harder time with "plain C", mostly in the sense that C
code which isn't using a lot of the VM runtime facilities, will
generally be much less friendly to any non-C code, and will generally be
harder for script code to work with.


as-is, it is not clear how a single language can handle all of these
cases without introducing a number of ugly seams (code intended for one
use-domain potentially looking wildly different from code intended for
another use domain).

say, code written to run in an OS kernel being almost unrecognizably the
same language as the code intended to run in high-level scripts.


 
Reply With Quote
 
88888 Dihedral
Guest
Posts: n/a
 
      10-11-2012
Brian於 2012年10月6日星期*UTC+8下午6時07分58秒 寫道:
> BGB <(E-Mail Removed)> wrote:
>
> > On 10/5/2012 8:12 AM, Brian wrote:

>
> >> 88888 Dihedral <(E-Mail Removed)> wrote:

>
> >>> Lynn McGuire¼ 2012t105å”UTC+8

>
> >>> H2B2536ÒëS

>
> >>>> On 10/2/2012 10:30 PM, BGB wrote:

>
> >>>>

>
> >>>>> On 10/2/2012 7:50 PM, Brian wrote:

>
> >>>>

>
> >>>>>> BGB <(E-Mail Removed)> wrote:

>
> >>>>

>
> >>>>>>> On 10/2/2012 3:24 PM, ralph wrote:

>
> >>>>

>
> >>>>>>>> On Mon, 01 Oct 2012 12:33:24 -0500, Lynn McGuire <(E-Mail Removed)>

>
> >>>>

>
> >>>>>>>> wrote:

>
> >>>>

>
> >>>>>>>>

>
> >>>>

>
> >>>>>>>>> On 9/29/2012 11:54 PM, Jan G wrote:

>
> >>>>

>
> >>>>>>>>>> Lynn McGuire wrote:

>
> >>>>

>
> >>>>>>>>>>> On 9/27/2012 4:38 AM, BGB wrote:

>
> >>>>

>
> >>>>>>>>>>>> On 9/27/2012 3:44 AM, Brian wrote:

>
> >>>>

>
> >>>>>>>>>>>>> I have not found an answer to the question why C++ is the most

>
> >>>>

>
> >>>>>>>>>>>>> preferred language. I thought it would be a good question to ask in

>
> >>>>

>
> >>>>>>>>>>>>> this newsgroup that has programmers that have been using C++ for a

>
> >>>>

>
> >>>>>>>>>>>>> while. I did read that its popular because it can be transferred to

>
> >>>>

>
> >>>>>>>>>>>>> other

>
> >>>>

>
> >>>>>>>>>>>>> platforms but not everyone has more than one platform.

>
> >>>>

>
> >>>>>>>>>>>>>

>
> >>>>

>
> >>>>>>>>>>>>

>
> >>>>

>
> >>>>>>>>>>>> because it sucks less than the other options?...

>
> >>>>

>
> >>>>>>>>>>>

>
> >>>>

>
> >>>>>>>>>>> +1

>
> >>>>

>
> >>>>>>>>>>>

>
> >>>>

>
> >>>>>>>>>>> Lynn

>
> >>>>

>
> >>>>>>>>>>

>
> >>>>

>
> >>>>>>>>>> Lynn, that you are a newbie to the spiel and that there shouldnot be

>
> >>>>

>
> >>>>>>>>>> anymore newbies, is quite disconcerting.

>
> >>>>

>
> >>>>>>>>>

>
> >>>>

>
> >>>>>>>>> I have been writing software for about 40 years

>
> >>>>

>
> >>>>>>>>> now and have used about 10 software languages.

>
> >>>>

>
> >>>>>>>>> All software languages suck but C++ sucks less

>
> >>>>

>
> >>>>>>>>> really describes my feelings well.

>
> >>>>

>
> >>>>>>>>>

>
> >>>>

>
> >>>>>>>>> Don't even get me started on user interface APIs.

>
> >>>>

>
> >>>>>>>>>

>
> >>>>

>
> >>>>>>>>

>
> >>>>

>
> >>>>>>>> LOL

>
> >>>>

>
> >>>>>>>>

>
> >>>>

>
> >>>>>>>> My sentiments exactly.

>
> >>>>

>
> >>>>>>>>

>
> >>>>

>
> >>>>>>>> I started writing C in 1977 ("before they wrote the book" was mybrag.

>
> >>>>

>
> >>>>>>>> <g>). As an early adopter of OO, cfront shortly after. LanguagesI

>
> >>>>

>
> >>>>>>>> have dabbled with have come and gone, yet c\c++ remains.

>
> >>>>

>
> >>>>>>>>

>
> >>>>

>
> >>>>>>>

>
> >>>>

>
> >>>>>>> admittedly, I haven't been around nearly so long...

>
> >>>>

>
> >>>>>>> (at that time, I didn't exist yet).

>
> >>>>

>
> >>>>>>>

>
> >>>>

>
> >>>>>>> around 20 years later (mid/late 90s), I was in elementary and middle

>
> >>>>

>
> >>>>>>> school and mostly still learning the basics of programming (a lotof this

>
> >>>>

>
> >>>>>>> by hacking around on/around the Quake source and similar...).

>
> >>>>

>
> >>>>>>>

>
> >>>>

>
> >>>>>>> I got mostly into interpreters during high-school, back in the early

>
> >>>>

>
> >>>>>>> 2000s. this was partly due to curiosity, and partly because at one point

>
> >>>>

>
> >>>>>>> I tried using and then got frustrated with GNU Guile.

>
> >>>>

>
> >>>>>>>

>
> >>>>

>
> >>>>>>>

>
> >>>>

>
> >>>>>>>> Whenever a particular platform, language, script, API came up short -

>
> >>>>

>
> >>>>>>>> out came a trusty C++ compiler. I firmly believe there is no

>
> >>>>

>
> >>>>>>>> programming problem that can't be resolved with another layer of

>
> >>>>

>
> >>>>>>>> indirection.

>
> >>>>

>
> >>>>>>>>

>
> >>>>

>
> >>>>>>>> When asked why C++ is popular, useful, "better", "advisable" ...I

>
> >>>>

>
> >>>>>>>> often tried to provide glorious prose and profound 'proofs'. I owe BGB

>
> >>>>

>
> >>>>>>>> a debt - from now on I can simply say "It sucks less". <g>

>
> >>>>

>
> >>>>>>>>

>
> >>>>

>
> >>>>>>>

>
> >>>>

>
> >>>>>>> yeah.

>
> >>>>

>
> >>>>>>>

>
> >>>>

>
> >>>>>>> this has mostly been my experience.

>
> >>>>

>
> >>>>>>>

>
> >>>>

>
> >>>>>>>

>
> >>>>

>
> >>>>>>> there are a few areas where C and C++ come out a little weaker (vs a

>
> >>>>

>
> >>>>>>> scripting language or similar), but the scripting language I use for

>
> >>>>

>
> >>>>>>> these cases would fall on its face if it tried to do what C and C++ are

>
> >>>>

>
> >>>>>>> typically used for doing (a scripting language would make a poor choice

>
> >>>>

>
> >>>>>>> for an implementation language).

>
> >>>>

>
> >>>>>>

>
> >>>>

>
> >>>>>> And C++ is got to be better than programming in assembly language.

>
> >>>>

>
> >>>>>> I started programming when I brought a TRS 80 computer 30 years ago. When

>
> >>>>

>
> >>>>>> you switched it on you got a BASIC language editor so the first language I

>
> >>>>

>
> >>>>>> learnt was BASIC.

>
> >>>>

>
> >>>>>> To find out how programs worked I took them apart using a disassembler and

>
> >>>>

>
> >>>>>> stepped through the raw machine language code. I wasn't a hacker like some

>
> >>>>

>
> >>>>>> people that added a jump statement to by pass the programs protection but

>
> >>>>

>
> >>>>>> just liked to find out how commercial programs such as games worked.

>
> >>>>

>
> >>>>>>

>
> >>>>

>
> >>>>>>

>
> >>>>

>
> >>>>>

>
> >>>>

>
> >>>>> early on, when I started messing with computers (elementary school

>
> >>>>> years), my dad had a 486, and I used it mostly to play Wolfenstein

>
> >>>>

>
> >>>>> 3D and Doom. Quake ran, but slowly, on a 486DX2.

>
> >>>>

>
> >>>>>

>
> >>>>

>
> >>>>> back in these days, the internet was also really slow, and most games

>
> >>>>> ran in DOS (so it was common to need to boot into DOS mode), ...

>
> >>>>

>
> >>>>>

>
> >>>>

>
> >>>>>

>
> >>>>

>
> >>>>> I don't really have many clear memories from much before this point

>
> >>>>> (back this far, memories are a bit fragmentary). I generally

>
> >>>>

>
> >>>>> classify these as my early years.

>
> >>>>

>
> >>>>>

>
> >>>>

>
> >>>>> this is, as opposed to now, where I am facing against advancing ageand

>
> >>>>> similar (my 20s will soon be gone... this is worrying...),

>
> >>>>

>
> >>>>> and also not having a job.

>
> >>>>

>
> >>>>>

>
> >>>>

>
> >>>>> I have noted occasionally that code of mine from closer to my early

>
> >>>>> years generally sucked (like, some of my code from around 2004 or

>
> >>>>

>
> >>>>> so was pretty horrid).

>
> >>>>

>
> >>>>>

>
> >>>>

>
> >>>>>

>
> >>>>

>
> >>>>>

>
> >>>>

>
> >>>>> now, as for C++ vs ASM:

>
> >>>>

>
> >>>>>

>
> >>>>

>
> >>>>> well, C++ offers a few clear advantages at least over ASM:

>
> >>>>

>
> >>>>> can get a lot more done in fewer statements;

>
> >>>>

>
> >>>>> is portable to a wide variety of systems (vs assembly which has to be

>
> >>>>> largely rewritten for each type of CPU, OS, ...), and where it

>
> >>>>

>
> >>>>> isn't usually possible to move code between one assembler and another

>
> >>>>> (MASM, NASM, GAS, ... are incompatible), ...

>
> >>>>

>
> >>>>>

>
> >>>>

>
> >>>>> though, there are still a few edge-case things which can only really be

>
> >>>>> done (effectively, or at all) in ASM.

>
> >>>>

>
> >>>>>

>
> >>>>

>
> >>>>> this results in programs where typically the vast majority is written

>
> >>>>> in C or C++, but some small parts will exist which are written

>
> >>>>

>
> >>>>> in ASM (which may have little or nothing to do with performance).

>
> >>>>

>
> >>>>

>
> >>>>

>
> >>>> I would not write anything in ASM nowadays. You

>
> >>>>

>
> >>>> never know when you are going to port to another

>
> >>>>

>
> >>>> platform.

>
> >>>>

>
> >>>>

>
> >>>>

>
> >>>> Plus the number of ASM compilers on the pc platform

>
> >>>>

>
> >>>> is simply amazing.

>
> >>>>

>
> >>>>

>
> >>>>

>
> >>>> Lynn

>
> >>>

>
> >>> In the job market one got rare talents could get higher paid, if the demands

>
> >>> are not satisfied.

>
> >>>

>
> >>> I think in a few years it would be hard to find good assembly programmers.

>
> >>

>
> >> Good programmer are the ones that had to fit code into a small space in the

>
> >> 1980's as computers did not have a lot of memory. But these days with lots

>
> >> of memory programmers are likely to be more relaxed.

>
> >>

>
> >

>
> > pretty much, and also computers are much faster, and (usually) compiledC

>
> > or C++ code can be performance-competitive with hand-written ASM (cases

>
> > where it isn't often have to do with newer SIMD features and similar, but

>
> > generally these are made available via compiler intrinsics).

>
> >

>
> >

>
> > but, ASM still isn't useless, as there are things which can't really be

>
> > done effectively within C or C++:

>
> > dynamically generating code that runs *at the same speed* as C or C++

>
> > code (such as in a VM);

>
> > effectively implementing dynamic-dispatch to function pointers

>
> > (basically, where the argument list is only known at run-time, though

>
> > this can be sort-of faked poorly via a giant switch with a case for

>
> > pretty much every possible argument list);

>
> > implementing lexical closures (absent compiler support);

>
> > ...

>
> >

>
> > a big limiting factor of C and C++ is that the code is itself largely

>
> > static at runtime (yes, function-pointers and virtual methods and similar

>
> > allow things to be a lot more free-form, but you can't really build "new" functions).

>
> >

>
> > consider a person asks: "how long until C++ has eval?" (which doesn't

>
> > itself use machine code, IOW: no LLVM or similar).

>
> >

>
> > but, a little bit of ASM can actually go a long ways here...

>
> >

>
> >

>
> > the vast majority of the code can still be C or C++, but little globs of

>
> > ASM (and runtime generated machine code), can do some rather nifty stuff.

>
> >

>
> > but, most people, and most code, can largely ignore said ASM (much like,

>
> > not everyone needs to implement a scripting VM, but at least some people

>
> > need to do so, as otherwise there are no scripting VMs...).

>
> >

>
> >

>
> > side note:

>
> > in my current project, pretty much all of the ASM is itself generated

>
> > and/or assembled at runtime (my project includes its own assembler).

>
> >

>
> > this is partly as this is generally actually more convenient than

>
> > statically-linked ASM modules.

>
> >

>
> > it was originally written mostly just for my original JIT back-end, but

>
> > ended up being more often used for other stuff.

>
> >

>
> >

>
> > actually, for the most part, my scripting language has ended up being

>
> > similar. its main use is mostly as a "C surrogate" when it comes to

>
> > things like "eval" and similar (it isn't C, but is close enough for the

>
> > differences to be glossed over).

>
> >

>
> > the main issues mostly have to deal with occasional syntactic

>
> > differences. though, it can accept more C-like declarations in many

>
> > cases, but some things (such as casts) had to be changed. absent the

>
> > ability to determine types at parse-time, the C-style cast syntax is

>
> > ambiguous, so in my case, it uses instead "expr as type" and "expr as!

>
> > type", with minor semantic differences (if the latter cast is dynamic and

>
> > fails, it will throw an exception).

>
> >

>
> > another issue, is that the way standard C syntax works, makes efficient

>
> > (unambiguous) parsing non-trivial (close alternatives, like C# style

>
> > syntax, work by imposing restrictions).

>
> >

>
> >

>
> > but, it all works well enough IMO...

>
>
>
> So in a way you are writing your own engine much like game programmers have
>
> a game engine that is specifically for creating games, especially 3D maze
>
> type games.
>
>
>
> Many year ago some programmers were programming in different languages eg
>
> asm, visual basic and maybe pascal then after compiling each programming
>
> language they were able to link the languages together to form one program.
>
> I can't remember how it was done as its so long ago...maybe there was a
>
> linking program.
>
>
>
> I use to love stepping thru programs to see how they work using a
>
> disassembler. It was easy to do in the programs written for the Z80
>
> processor. Do you know of a disassembler?
>
>
>
> --
>
> Regards Brian


Acctually I am more intrested in high speed computing designs that could be
implemeted in FPGA or ASIC.

 
Reply With Quote
 
BGB
Guest
Posts: n/a
 
      10-12-2012
On 10/11/2012 2:44 PM, Paavo Helde wrote:
> Brian <(E-Mail Removed)> wrote in
> news:(E-Mail Removed):
>>
>> Maybe in the future someone will create a programming language that
>> everyone's happy with.

>
> That's not really possible as there are different programming needs, and
> also different people doing the programming. For digging earth there are
> still both shovels and excavators, and everything in between.
>


you could always "unify" them by having a shovel as a subset, and an
excavator "extension" which will then attach to the shovel (or the other
way around).

person looks at excavator, sees slotted hole, slides a shovel in there
handle-first, excavator comes to life and starts digging.

if a bigger one is needed, then it will drive up and merge with the
smaller excavator like some kind of combining mecha...

then the user is lifted into the cockpit via a sliding chair-lift, and
the handle of the original shovel pops out of the control panel, to
serve as the main control stick for operating is new larger excavator
(the user does digging-like motions with the shovel, which is used in
combination with the user yelling out command names).

maybe it also comes with thresher and grain-storage attachments as well
(cause, who knows, a person might be digging a large hole and then just
randomly need to harvest some grain while they are at it).


 
Reply With Quote
 
Stuart
Guest
Posts: n/a
 
      10-12-2012
On 9/28/12 Lynn McGuire wrote:
> Try a large project in Visual Basic. Our software
> products have about 800,000 lines of C++ and 600,000
> lines of F77. The C++ is the most maintainable and
> reliable code.


The largest VB project I have ever worked on was about 15K lines of
code. However, it was completely object-oriented (yes, you can use OO
under plain old VB, not VB.NET) and thus much more maintainable than the
previous implementation of the project under a programming language
called IDL.

However, VB has some serious drawbacks:
(1) a private member is private to the object (and not private to the
class),
(2) if you want to use the Strategy pattern, your base class method
needs to be passed the pointer to the most derived class or else
polymorphism won't kick in (it only works properly if you call a virtual
method of an object from outside of the object, once you are inside the
method of an base class VB won't invoke methods that have been
overridden in derived classes),
(3) using RAII is not directly supported under VB and must be emulated
through code that cannot be written with VB (I had to write a C++
component that acts as a resource guard),
(4) if you inherit from a class, you have to provide an implementation
for every f***ing method of the base class, even if the derived class
won't do anything differnt (so you end up with lots of forward-to-base
methods).

Unfortunately, MS decided to abandon VB and push VB.NET instead of
fixing VB. That is sad, but not particularly surprising.

Regards,
Stuart

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Why is OO popular? Ian Roberts C++ 5 04-20-2004 05:30 AM
Are Dvd-R more popular then the +? Why? lbbs DVD Video 29 01-11-2004 02:14 PM
Are Dvd-R more popular then the +? Why? lbbs Computer Support 9 01-08-2004 12:24 AM



Advertisments