Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > GCC is re-implementing in C++ and C discarded

Reply
Thread Tools

GCC is re-implementing in C++ and C discarded

 
 
Rui Maciel
Guest
Posts: n/a
 
      08-29-2012
Kenny McCormack wrote:

> Q: What exactly do we mean when we say that language A is more "popular"
> than language B?


I'm not in the position to state what you believe, but I can speak for
myself and provide a definition for "popular" in this context which I
believe is appropriate.

As the word "popular" refers to something that is regarded with favour or
approval by people in general, then, as a programming language is supposed
to be a tool used by programmers to actually write software, a good
yardstick for the popularity of a programming language is how widespread is
its use to actually develop programs. A couple of ways which adequately
evaluate this are:
a) the number of programs which are developed, completely or in part, with
it
b) the demand for programmers who are skilled in it

A quick search in monster.com for ads listing Objective-C as a required
skill returns 417 results.[1] Meanwhile, there are 1000 ads looking for
C++[2] or C[3] programmers, and I suspect that the site caps search results
at 1000 hits. To me, this information is more meaningful than the number of
times a certain string is found in a random blog.


Rui Maciel

[1] http://jobsearch.monster.com/search/...C-Programming-
Language
[2] http://jobsearch.monster.com/search/...mming-Language
[3] http://jobsearch.monster.com/search/...mming-Language
 
Reply With Quote
 
 
 
 
Fritz Wuehler
Guest
Posts: n/a
 
      08-30-2012
"Steven G. Kargl" <(E-Mail Removed)> wrote:

> On Sat, 25 Aug 2012 21:35:29 +0000, Anonymous wrote:
>
> > "Steven G. Kargl" <(E-Mail Removed)> wrote:
> >
> >> On Fri, 24 Aug 2012 13:58:46 -0400, Kenneth Brody wrote:
> >>
> >> > On 8/24/2012 5:15 AM, Nick Keighley wrote:
> >> > [...]
> >> >> this whole conversation strikes me as bizzare. A kind of level
> >> >> confusion. It reminds of one of my collegues who came out with "C++ is
> >> >> upwards compatible with C because it is implemented in C" and couldn't
> >> >> see what was wrong with that statement.
> >> >
> >> > "Assembler must be upwards compatible with C, because 'as' is written in C."
> >> >
> >> > "FORTRAN must be upwards compatible with C, because gnu FORTRAN is written
> >> > in C." (I think.)
> >>
> >> The name of the language is "Fortran". It's been Fortran since
> >> the Fortran 1990 standard.

> >
> > So what? FORTRAN is no less FORTRAN now then it was then. Perhaps he was
> > talking about gnu's shitty F77 compiler.

>
> Except even your spelling in all caps is incorrect. If you take that time
> to look at the Fortran standards, you find that the 'ORTRAN' is written in
> a small cap font. After 25 years, is it asking to much to spell the
> name of the language correctly?


Many people have no respect for tradition and they seem to think everything
was created after they were born. In reality, FORTRAN was designed and
produced by IBM and came to the rest of the world around 1957. That language
and those implementations are still in regular use. The fact a new language
called Fortran that is a superset of FORTRAN was standardized does not
change the fact FORTRAN was and still is FORTRAN.

Consider a few references:

"The Origins of FORTRAN" presentation by Peter Crouch.
"American National Standard FORTRAN" USAS X3.9-1966
"American National Standard Programming Language FORTRAN" X3.9-1978

It's funny how you think 25 years is such a long time since FORTRAN has been
around for almost 56 years.

> GNU GCC does not have a shitty F77 compiler. g77 was deprecated years
> ago.


Ok, but doesn't gfortran support F77 and isn't F77 FORTRAN? I mean, even you
capitalized the name

> Since April 20, 2005, the Fortran compiler in GCC is gfortran, and for the
> last few years gfortran has been competitive with all commercial available
> Fortran compilers.


On what basis do you claim gfortran is competitive? I'm not saying it isn't
(I certainly doubt that it is but I didn't say that until you said it
is). gcc gives very poor diagnostics and the code generation on platforms
other than Intel is known to be subpar. I'm sure Solaris Studio spanks
gfortran badly on SPARC but thankfully I haven't had to test it.

> >> The GNU Fortran frontend is written in C. Some of the GNU
> >> Fortran runtime is written in m4. The m4 files when processed
> >> generates Fortran code. The Fortran code is then compiled by
> >> GNU Fortran.

> >
> > OMG no. You didn't just write "Some of the GNU Fortran runtime is written in
> > m4."

>
> Yes, I did. But, you failed to read the next sentence. When you build
> GCC with gfortran support, the m4 files are processed to generated some
> Fortran code for the runtime library. That Fortran code is then compiled
> by the just built Fortran compiler.


I understood you the first time. I object to the complexity of using an
arcane scripting language in a compilation system and to gcc's general
approach of expediency uberalles instead of discipline. Total ad-hoc
"design" and complete absence of engineering, that's gcc.

> Your response is a classic example of someone who does not understand
> the principle of using the right tool to get a job done.


I don't agree, but I do say yours is a classic example of having no discipline
in design or coding. Anything goes, right buddy?

> > Goodbye to gcc's grotesque bloat and "i was drinking that night" design,
> > goodbye to Stallmanesque Marxism, hello clang/LLVM!

>
> Have you tried compiling any Fortran code with LLVM? LLVM does not have
> its own Fortran compiler. It actually uses gfortran.


Well no, I haven't. I use IBM FORTRAN IV and occasionally their VS FORTRAN,
and Solaris Studio. Thankfully I only hear about gcc from my disadvantaged
friends.

> http://llvm.org/Features.html
>
> "Front-ends for C, C++, Objective-C, Fortran, etc based on the GCC 4.2 parsers."
>
> I can assure you that GCC 4.2.x's Fortran parser is fairly bad compared to
> any of the newer versions.


I don't dispute that. I'm just happy llvm will be an alternative for people
currently forced to use the shitty gnu tools. Eventually I suspect gcc will
only exist on Linux since the FSF serfs want to eliminate the LGPL on the
runtime. Free, open source software (BSD or MIT licensed) will probably move
to clang/llvm. FreeBSD moving away from gcc to clang is a great milestone in
free software history and against the tyranny of the FSF and its lemmings.

 
Reply With Quote
 
 
 
 
eq mail
Guest
Posts: n/a
 
      08-31-2012
On 26.8, 00:19, Jens Gustedt wrote:
> Am 25.08.2012 21:23, schrieb James Kuyper:
> > On 08/25/2012 11:55 AM, Jens Gustedt wrote:
> >> Am 25.08.2012 15:35, schrieb James Kuyper:
> >>> However, that was basically just a trick (and it took me a long time to
> >>> perfect it). As far as I know, everything that can be done using
> >>> portable C code can also be done by using (possibly different) C code
> >>> that also compiles as C++ code, with the same exact meaning in both
> >>> languages (exception: code like that which I described above, whose sole
> >>> purpose is to detect which language it was compiled in - by definition
> >>> such code must behave differently in order to behave correctly). Could
> >>> you give a counter-example?

>
> >> The intersection of C and C++ has
> >> - no decent initializers, you'd need designated initializers on the C
> >> side and constructors for C++

>
> > ???
> > The claim was that use of C was a necessity, not just a convenience. C
> > doesn't have constructors, and designated initializers are only a
> > convenience feature that don't do anything that can't already be done
> > using ordinary initializers - they just make it more convenient.

>
> How would you do
>
> unsigned char errVector[] = { [EINVAL] = true, [ERANGE] = true, };
> enum { maxNeeded = sizeof(errVector), };
>
> in C++ ?


(I apologize for this bunch of C++ in a technically unrelated group,
for those offended.)

This question caught my attention: can this be done? This certainly
falls into the "there's many a way to do this" basket in C++, and
perhaps (like mostly anything) with enough Boost magic and repetitive
overloads, it has always been possible; however, I sought for a
(relatively) expressive solution using the relatively powerful
variadic templates, and came up with this. (Someone better than me
might come up with something cleaner, as most would agree that this
*is* rather wieldy.)

#include <array>
#include <cstddef>
#include <type_traits>

template<std::size_t i, std::size_t... Rest>
struct indices {
typedef typename std::enable_if<sizeof...(Rest) != 0,
indices<Rest...>>::type next;
static constexpr std::size_t value = i,
max = (value + 1 > next::max)
? value + 1
: next::max;
};
template<std::size_t i>
struct indices<i> {
typedef void next;
static constexpr std::size_t value = i,
max = value + 1;
};

template<class U, std::size_t N, class T>
constexpr typename std::enable_if<std::is_void<T>::value, U>::type
get()
{
return U();
}
template<class U, std::size_t N, class T, class V, class... Rest>
constexpr typename std::enable_if<!std::is_void<T>::value, U>::type
get(V&& v, Rest&&... rest)
{
return (T::value == N)
? std::forward<V>(v)
: get<U, N, typename T::next>(std::forward<Rest>(rest)...);
}

template<class U, class Indices, std::size_t... Gen, class... Rest>
constexpr typename std::enable_if<sizeof...(Gen) == Indices::max,
std::array<U, Indices::max>>::type
make_(Rest&&... rest)
{
return {{get<U, Gen, Indices>(std::forward<Rest>(rest)...)...}};
}
template<class U, class Indices, std::size_t... Gen, class... Rest>
constexpr typename std::enable_if<sizeof...(Gen) != Indices::max,
std::array<U, Indices::max>>::type
make_(Rest&&... rest)
{
return make_<U, Indices, Gen..., sizeof...(Gen)>(
std::forward<Rest>(rest)...);
}
template<class U, std::size_t... Indices, class... Rest>
constexpr std::array<U, indices<Indices...>::max> make(Rest&&... rest)
{
return make_<U, indices<Indices...>>(std::forward<Rest>(rest)...);
}

.... and what does all of this accomplish? Not a whole lot; at least
not without something similar to the code below (this is a scenario
from a later reply, because the one above seemed too simplistic.)

auto errVector = make<const char*, EBADF, 0, ERANGE>(
"EBADF", "(success)", "ERANGE");
enum { maxNeeded = sizeof(errVector) };

'errVector' above is actually not an array, but rather a std::array
object. It's unavoidable, but luckily std::array is just a very simple
wrapper of one.

One could perhaps achieve something to this end with structs, too,
although the syntax might be relatively even more awkward. (It's
certain that the members would have to be "listed" in some way as
there's no other way to get to know of them.) I'm not 100% certain
about this being doable, however.

....

Now that we've come this far, intuition begs the question: do the C++
folk actually believe they've got the superior tools when they refuse
to incorporate designated initializers into the language, when it's
obvious to anyone that they don't (have them).

I don't think the situation is that simple.

The way I see it, the co-operation of the committees will mostly
revolve around and result in not introducing subtle incompabilities
(the ones that won't show up when compiling) into the languages; and
not in extending the usable common subset of them. Static
initialization, I think, is often simply seen as less important within
C++ circles, because with complex objects you have lots to do at
runtime anyway.

By the way, with only a few values far between, one might want to use
an associative container instead of a mostly-wasted array. C++ has
relatively expressive syntax for those (shown below), but I don't
think C is getting anything similar anytime soon, tricks or not.

std::unordered_map<int, const char*> errMap = { { ERANGE, "ERANGE" },
{ 0, "(success)" }
/* ... */
};
 
Reply With Quote
 
lawrence.jones@siemens.com
Guest
Posts: n/a
 
      08-31-2012
Jens Gustedt <(E-Mail Removed)> wrote:
>
> But it says so implicitly. Prototypes are defined semantically
> (6.2.1p2), not through syntax: a declaration of a function that
> declares the types of its parameters. "void foo() { }" perfectly fits
> in here, it is a definition and it specifies the number and type of
> its parameters, namely none.


It's always been understood that a declaration of a function has to use
a parameter-type-list to declare the types of its parameters; being part
of an old-style definition that uses an (optional) identifier-list is
not sufficient, even though the definition does go on to declare them.
There are lots of tidbits scattered through the rest of the standard
that make it obvious that that was the committee's intent, but it could
have been stated more explicitly.
--
Larry Jones

I think football is a sport the way ducks think hunting is a sport. -- Calvin
 
Reply With Quote
 
Jens Gustedt
Guest
Posts: n/a
 
      09-01-2012
Am 31.08.2012 23:40, schrieb http://www.velocityreviews.com/forums/(E-Mail Removed):
> Jens Gustedt <(E-Mail Removed)> wrote:
>>
>> But it says so implicitly. Prototypes are defined semantically
>> (6.2.1p2), not through syntax: a declaration of a function that
>> declares the types of its parameters. "void foo() { }" perfectly fits
>> in here, it is a definition and it specifies the number and type of
>> its parameters, namely none.

>
> It's always been understood that a declaration of a function has to use
> a parameter-type-list to declare the types of its parameters;


Out of curiosity, why did the term prototype then never make it to a
syntactical definition? Do you agree with me that if we stick together
the current text as it stands we have that

- "void foo() { }" is a defintion of "foo"
- it is also a declaration
- it declares that "foo" has no parameters
- so it also declares the types of these parameters (namely none)
- so it is a declaration of "foo" that declares the type of its parameters
- according to 6.2.1p2 it is a prototype

> being part of an old-style definition that uses an (optional)
> identifier-list is not sufficient, even though the definition does
> go on to declare them. There are lots of tidbits scattered through
> the rest of the standard that make it obvious that that was the
> committee's intent, but it could have been stated more explicitly.


Honestly I didn't find much information that would really suggest
that. If I haves seen correctly, there are two examples in the
standard of "int main() { ... }". Doesn't suggest much that the
committee really wants everybody to move to the "int main(void) { ... }"
form.

I don't even think that is very productive to stick to that idea. Old
style function declarations with empty list that are not prototypes
should have disappeared since long. What is left is just a gratuitous
discrepancy to C++.

In any case, this deserves a DR and a clarification.

Jens
 
Reply With Quote
 
Szabolcs Nagy
Guest
Posts: n/a
 
      09-03-2012
Jens Gustedt <(E-Mail Removed)> wrote:
> Out of curiosity, why did the term prototype then never make it to a
> syntactical definition? Do you agree with me that if we stick together
> the current text as it stands we have that
>
> - "void foo() { }" is a defintion of "foo"
> - it is also a declaration
> - it declares that "foo" has no parameters
> - so it also declares the types of these parameters (namely none)
> - so it is a declaration of "foo" that declares the type of its parameters
> - according to 6.2.1p2 it is a prototype
>


the type is not declared

> In any case, this deserves a DR and a clarification.
>


what about

http://www.open-std.org/JTC1/SC22/wg...ocs/dr_317.htm

so foo has no prototype, but i don't think this
contradicts the statement that

void foo() {}

and

void foo(void) {}

are equivalent function definitions
 
Reply With Quote
 
Jens Gustedt
Guest
Posts: n/a
 
      09-03-2012
Am 03.09.2012 02:31, schrieb Szabolcs Nagy:
> Jens Gustedt <(E-Mail Removed)> wrote:
>> Out of curiosity, why did the term prototype then never make it to a
>> syntactical definition? Do you agree with me that if we stick together
>> the current text as it stands we have that
>>
>> - "void foo() { }" is a defintion of "foo"
>> - it is also a declaration
>> - it declares that "foo" has no parameters
>> - so it also declares the types of these parameters (namely none)
>> - so it is a declaration of "foo" that declares the type of its parameters
>> - according to 6.2.1p2 it is a prototype
>>

>
> the type is not declared


I think that it is not easily apparent how an empty list could declare
the type of parameters that don't exist.

>> In any case, this deserves a DR and a clarification.
>>

>
> what about
>
> http://www.open-std.org/JTC1/SC22/wg...ocs/dr_317.htm


That is not what I meant by clarification. Do we want to have a state
where the standard can only be understood if you know about a body of
"judgements" by the committee that makes this or that interpretation
valid or not?

What I mean with clarification is to add something to the standard
that makes this situation clearer, the same way as it had been done
for the type-punning via unions, e.g.

What I even would prefer is to abandon all non-prototype declarations
and definitions. They have been declared obsolete since long. A first
step could be to exactly allow for the empty-list definition to be a
prototype. This would put C in accordance with C++ on that point, with
not much cost.

Jens
 
Reply With Quote
 
Jens Gustedt
Guest
Posts: n/a
 
      09-03-2012
Am 03.09.2012 08:31, schrieb Jens Gustedt:
> Am 03.09.2012 02:31, schrieb Szabolcs Nagy:
>> Jens Gustedt <(E-Mail Removed)> wrote:
>>> Out of curiosity, why did the term prototype then never make it to a
>>> syntactical definition? Do you agree with me that if we stick together
>>> the current text as it stands we have that
>>>
>>> - "void foo() { }" is a defintion of "foo"
>>> - it is also a declaration
>>> - it declares that "foo" has no parameters
>>> - so it also declares the types of these parameters (namely none)
>>> - so it is a declaration of "foo" that declares the type of its parameters
>>> - according to 6.2.1p2 it is a prototype
>>>

>>
>> the type is not declared

>
> I think that it is not easily apparent how an empty list could declare
> the type of parameters that don't exist.


And syntactically the only way to parse the parameter list of "void
foo(void);" according to the BNF of the standard is "D(
identifier-listopt )", too. So saying that the syntax distinguishes
the forms of specifying an empty list, is simply not true.

Jens
 
Reply With Quote
 
Ike Naar
Guest
Posts: n/a
 
      09-03-2012
On 2012-09-03, Jens Gustedt <(E-Mail Removed)> wrote:
> And syntactically the only way to parse the parameter list of "void
> foo(void);" according to the BNF of the standard is "D(
> identifier-listopt )", too. So saying that the syntax distinguishes
> the forms of specifying an empty list, is simply not true.


(identifier-listopt) cannot expand to (void)
because void is not an identifier (it's a keyword).
 
Reply With Quote
 
Chicken McNuggets
Guest
Posts: n/a
 
      09-03-2012
On 24/08/2012 00:54, Robert Wessel wrote:

> In the case of Objective-C, approximately everyone and their idiot
> brother is developing iOS apps. So there's lots of talk about the
> relatively new platform. By contrast, C (and C++) is much better
> understood, and I'd guess that the relative amount of chatter is lower
> compared to the amount of actual work being done.


This argument would make sense if C was lower on the Tiobe index than
Objective-C but it is not. So the metrics that the Tiobe index uses show
that C is still widely discussed (and by extension) widely used.

In fact as the link I posted above shows C is the most discussed
language on the web, ahead of Java, Objective-C and C++ (and everything
else besides).

 
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
Re: GCC is re-implementing in C++ and C discarded Nomen Nescio C Programming 0 08-26-2012 10:34 AM
Re: GCC is re-implementing in C++ and C discarded Anonymous C Programming 10 08-26-2012 08:04 AM
Cisco VPN client, packets beeing discarded and bypassed seansan Cisco 3 09-24-2006 10:50 AM
discarded iterator.next() at interactive global scope doesn't bump interator?? Bengt Richter Python 2 09-04-2005 12:17 PM
Linker Message: "discarded section" Hartmut Sbosny C++ 2 05-29-2005 12:20 AM



Advertisments