C is a better language than any language you care to name.

[jschell]

Any time anyone thinks that one technology is "better" than another then first they need to define what "better" means. And since the statement doesn't limit itself to which other language is compares itself to it is going to fail because for any measurable attribute there is going to be some language which is in fact better than C.

[jschell]

Joe Woodbury wrote:

The declaration does and thus the precompiler) and sizeof(), but not the array itself.

Rather certain that the precompiler is in fact part of the language since it is in fact part of the specification for the language. If you wish to another definition for "language" than the specification then you would need to provide one. And if one wants to be specific then at least in my edition of "C Programming Language 2nd Edition" the preprocessor is part of the main language definition (not an appendix) and the section specifically starts off with "C provides certain language facilities by mean of a processor". So if K&R thinks it is part of the language I am going to take their word for it. Or perhaps to put in in another perspective, limiting oneself to just the "language" then C is in fact useless, since one cannot in any practical way do anything useful with the "language". Thus it can't, again in a practical, real world way, be "better" than anything else.

[Joe Woodbury]

You are arguing against something I never said. Specifically, nowhere did I say that the precompiler isn't part of the language. More generally, my point is that the information about the size of the array is known only by the scope of the array declaration at compile time; it is not contained in the array itself and available at runtime. In C, an array and a pointer are, for all intents and purposes, synonymous (with the exception of this very narrow edge case.) So, the [partial] function declarations a(const char* p) and b(const char d[]) mean the same thing. Doing a sizeof(d) for the latter doesn't tell you anything meaningful about the original array. This also means that you can take an arbitrary pointer and use array syntax on it. i.e. p[3]. This gives C an enormous power and flexibility found in few other languages. Attaching any other information to a pointer (or array) changes the very nature of what a pointer is and adds overhead that is often not desired nor wanted (and if desired, you can easily create a struct (or class in C++) with that information contained in it. This very flexibility means that arguing that arrays are problematic in C is a strawman argument.)

[PIEBALDconsult]

Colborne_Greg wrote:

the "with" operator

...is useless filth. X|

You'll never get very far if all you do is follow instructions.

[PIEBALDconsult]

Kenneth Kasajian wrote:

Pascal

Aaaannnd... how do you work with very long strings? Very large structures*? * Maybe only a problem with Turbo Pascal with its 64K per structure limit.

You'll never get very far if all you do is follow instructions.

[PIEBALDconsult]

Bushwa! That is one of its greatest strengths! There were only three mistakes in C, and one was fixed in C89 (if I recall correctly). The other two continue to plague us.

You'll never get very far if all you do is follow instructions.

[PIEBALDconsult]

Michael Kingsford Gray wrote:

the monumentally bone-headed notion that CASE statements should cascade through without a BREAK

:thumbsup: Hear! Hear! That is (in my opinion) the very worst mistake in C.

You'll never get very far if all you do is follow instructions.

[PIEBALDconsult]

DaveX86 wrote:

Plus...no *.H files or #defines

The can have my # defines when they pry them from my cold, dead hands.

You'll never get very far if all you do is follow instructions.

[PIEBALDconsult]

jschell wrote:

Rather certain that the precompiler is in fact part of the language

Yes, and as he said in his response, he didn't say otherwise. Some points I'd like to make are: A language is defined by its compiler (not the other way around). DMR probably could have made C without a pre-processor; I see no reason that C has to have a pre-processor other than that it does have a pre-processor. The existence of D and C# may support this view. I have seen (I don't remember where) at least one argument that the C pre-processor acts on a different language than the C compiler does; and I am in about 90% agreement with that point of view. I like the C pre-processor; it's really just a text processing utility -- it can be used for purposes other than its primary usage. (I even use it with C# -- Implanting Common Code in Unrelated Classes[^]) Unfortunately, it also has some functions (e.g. sizeof) that are tightly bound to C. :sigh:

jschell wrote:

limiting oneself to just the "language" then C is in fact useless, since one cannot in any practical way do anything useful with the "language"

You may be arguing that the language is pretty limited without libraries, and that is quite true, very little can be accomplished without at least printf -- I have written a simple program that calculates a value and returns it from main, simply to demonstrate that something, no matter how pointless, can be done without linking in any libraries. However, I think the article was also pointing out the ease with which a developer can leverage a multitude of libraries with C. Just the other week I was playing with ODBC, and linking in only the ODBC libraries and not the "standard C libraries". Of course, doing so still requires the pre-processor, as the Creator intended.

jschell wrote:

I am going to take their word for it

Soooo... if Microsoft says that VB is the World's Greatest Language.... ? :suss:

[DaveX86]

:)

[Colborne_Greg]

Which is more readable to everyone, and which uses less lines?

Public Shared Function RotateStream(stream As IsolatedStorageFileStream, angle As Int16) As WriteableBitmap
    stream.Position = 0

    Dim bitmap = New BitmapImage()

    bitmap.SetSource(stream)

    Dim WriteableBitmapSource = New WriteableBitmap(bitmap)
    Dim WriteableBitmapTarget As WriteableBitmap
    Dim Target As Int64

    With WriteableBitmapSource

        Select Case angle
            Case 360 : Return WriteableBitmapSource
            Case 180 : WriteableBitmapTarget = New WriteableBitmap(.PixelWidth, .PixelHeight)
            Case Else : WriteableBitmapTarget = New WriteableBitmap(.PixelHeight, .PixelWidth)
        End Select

        For xAxis = 0 To .PixelWidth
            For yAxis = 0 To .PixelHeight
                Select Case angle
                    Case 90
                        Target = (.PixelWidth - yAxis - 1) + (xAxis \* WriteableBitmapTarget.PixelHeight)
                        WriteableBitmapTarget.Pixels(Target) = .Pixels(xAxis + yAxis \* .PixelWidth)
                    Case 180
                        Target = (.PixelWidth - xAxis - 1) + (.PixelHeight - yAxis - 1) \* .PixelWidth
                        WriteableBitmapTarget.Pixels(Target) = .Pixels(xAxis + yAxis \* .PixelWidth)
                    Case 270
                        Target = yAxis + (.PixelWidth - xAxis - 1) \* WriteableBitmapTarget.PixelWidth
                        WriteableBitmapTarget.Pixels(Target) = .Pixels(xAxis + yAxis \* .PixelWidth)
                End Select
            Next
        Next

    End With

    Return WriteableBitmapTarget
End Function

versus without

public static WriteableBitmap RotateStream(IsolatedStorageFileStream stream, int angle)
{
stream.Position = 0;
if (angle % 90 != 0 || angle < 0) throw new ArgumentException();

        int target;
        BitmapImage bitmap = new BitmapImage();

        bitmap.SetSource(stream);

        WriteableBitmap wbSource = new WriteableBitmap(bitmap);

        if (angle % 360 == 0) return wbSource;
        WriteableBitmap wbTarget = null;

        if (angle % 180 == 0)
        {
            wbTarget = new WriteableBitmap(wbSource.PixelWidth, wbSource.PixelHeight);
        }

        else
        {

[Colborne_Greg]

With visual basic, actually most languages deal with strings better then C...

[PIEBALDconsult]

OK, now use with to copy values between two instances.

You'll never get very far if all you do is follow instructions.

[PIEBALDconsult]

Better than Pascal I think you meant.

You'll never get very far if all you do is follow instructions.

[Colborne_Greg]

No I mean it's a waste of time. When you look at home long at takes to get a result and maintain that result visual basic wins every time.

[Colborne_Greg]

You can't think outside the box can you. Usually I would do something like this to copy a class Public function copy(byval ojbectName as objectType) as objectType Return objectName end function There are many ways of getting values from one structure to another, not just with the use of methods. Lastly this points out that you should be utilizing different methods of programming to get a result instead of manually coding each line out.

[PIEBALDconsult]

Colborne_Greg wrote:

to copy a class

Not copying everything; just some values.

You'll never get very far if all you do is follow instructions.

[Colborne_Greg]

If you only want a few of the values use visual basic reflection.

[Stefan_Lang]

// No comment!

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]

[Stefan_Lang]

Funny, I thought the language to-go was Fortran?[^] :doh: Now I'm waiting on a corresponding article about COBOL ;P

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]