Cobra Forums

Hello,
My name is Dima Dimov, I am a student at SJSU CA.
Cobra caught my interest as a clean syntax language. As such,I checked your documentation several times, and aside of passing a pointer to a function using a ref keyword, I could not find anything about doing sumething as follows:

c as int=5
q as int*=&c

Yes, I have translated the C,C++, int c=5; int* q=&c;

So the question boils down to, is it possible with cobra, and How?

The second question is as follows:
Are there facilities for manual memory management, or does a programmer merely reassigns the reference to a new object.
The "old" object being pointed to gets destroyed by Garbage collection.

Also, Is it possible to clear(memory wise(deallocate)) an array?

Cobra is more like C#, Java, Python and Ruby, where the usual approach is to:
-- have references to objects
-- use collection classes like list, dictionary and set
-- rely on garbage collection
-- rely on managed code to detect bounds violations and null access immediately
-- get an exception with stack trace when something goes wrong

This combination has become an attractor point in high level languages because it's much more productive in application development than C.

See also: http://cobra-language.com/how-to/UseLists/

But having said that, C# does offer pointers as seen here:
http://msdn.microsoft.com/en-us/library/y31yhkeb(v=vs.80).aspx

Given that Cobra leverages C#, there is the possibility of supporting this, though it would not port to the Java back-end.

I've written plenty of C# professionally and never needed pointers, but I'm usually doing app dev instead of systems and/or embedded. Did you have something in mind?

Thank you for your reply.

I am studying C# at moment, and quiet frankly it seems bulky to me.
I have programmed in C++ for 6 years, Java 3, and have done a year or 2 of D programming.
I also know C basics.

C# like Java has a lot of functionality but what caught my eye, and has been catching my eye was simplicity.
C# is very powerful but its like "You do your act, and The .NET will make sure ALL will be fine" at least that is the vibe I got from the internet. Just like in the interview advertised online, you said that C#, D, Java, D and Ruby and some other languages give some set of features, but neglect another.

Why is everybody so afraid of pointers? They are great if approached properly.
By properly I mean, like D, assign nil or null the default pointer value.
So nil tracking will no be a problem.

I know that Object Oriented programming revolves around Garbage Collection, but Garbage Collection does not allow programmer to free memory when he/she wants to.
I guess I am asking what is the benefit of not incorporating simple ability to allow pointerName as SomeType*=&ObjectOfSomeType
and pass SomeType to function and allow freeing memory and allocating it.

Is it because Cobra does not trust the developer?

I was hoping you could shed some light.

Not bulky, "batteries included" as Python puts it.

I recently wrote a couple of programs where the user scans in a barcode, my program then does an Oracle database query based on that barcode, reads a web page, combines the information using regular expressions, outputs the result using simple HTML formatting to a GUI form with a print button and places selected information into the Windows clipboard.

With a "batteries included" NET language such as Cobra I don't have to find a third-party library or re-invent the wheel for any of these simple common tasks, and I can throw it together quickly (within a week or two, in time snatched between my normal tasks) and it will work on any computer with .NET - and as my workplace moves into a standard Windows 7 image, that's going to be all of them.

The database query may return one result or fifty, as a list of heterogenous lists which contain strings in widely variable lengths. In an object-oriented language I can easily iterate through the results without worrying about allocating or freeing memory, getting the maximum allocation right, making sure I'm pointing to the right data, worrying about when to stop iterating through the list, or making any slips with obscure syntax. Let the compiler and the OS do the stupid grunt-work, I can think in terms of meaningful manipulation of the data. People aren't afraid of pointers, they're fed up spending meaningless time doing the computer's work for it.

Code: Select all

queryResults = askDatabaseAbout(something)
for eachResult in queryResults
    doSomethingTo(eachResult)

And that's only a whisker off the real code, I don't still have a tedious task ahead of me converting pseudocode to compiler-readable syntax.

In addition to ObtuseAngle's excellent post, here are some further thoughts:

Pointers seem fine for small amounts of code. I enjoyed the K&R book as much as anyone. But over time I noticed the amount of extra labor that "unprotected code" required was seldom worth it and past the initial learn stage, not too interesting either.

Software development is a process performed by humans who make mistakes. The larger and more complex the project, the more mistakes will be made. "Protective languages" like Cobra, C#, Eiffel and Python, catch problems earlier which reduces the labor in fixing them.

Of course, there are solutions in the C world. Things like pointer instrumentation tools, defensive programming, etc. but you have to know about these in the first place and you have to apply them. Baking safety into the language is a better approach.

You mentioned:

Why is everybody so afraid of pointers? They are great if approached properly.
By properly I mean, like D, assign nil or null the default pointer value.

But the lack of an initial value is not the only problem with pointers. Things like "one-off errors" can cause memory corruption. In C, programming errors can lead to an allocated memory block being free()ed twice. etc.

Is it because Cobra does not trust the developer?

Essentially, yes. Not because I think developer's are stupid, but because I know for a fact that they make many mistakes in software development. For a high level language, its design, compiler and run-time environment should all assist with respect to that fact.