Cobra Forums

Does Cobra support non-zero based array indexes? It's not critical, but very useful. I suppose I could conceivably just wrap a zero-based array in a class, and use functions to access the (offset) index values stored in the array.

Nope, they are zero-based.

I found this interesting article about them in .NET and C#:
http://joymonscode.blogspot.com/2011/09 ... n-net.html

.NET supports them as a different type whose indexing is made slower by accounting for the index base. However, they are a pain to use from C# and would be from Cobra as well at this time. Also, some .NET profiles such as Silverlight do not support them. We could potentially address that, but it would seem odd that lists, which are generally higher level than arrays, would not support a non-zero base.

As you pointed out, you can always whip up a class to provide the kind of interface you want, so that's your current approach.

The joymonscode article you cite is exactly what I saw that got me thinking about the subject.

To me, since I'm used to non-zero based array indexes in Delphi, the idea of zero-only is as ill-conceived as curly braces -- these are things that compilers are very good at dealing with, so why are we troubling the programmers to convert indexes indexes to (often) meaningless zero-based? And to write redundant curly braces?

Yes, it would be great if lists were non-zero based, too.

Charles wrote:

As you pointed out, you can always whip up a class to provide the kind of interface you want, so that's your current approach.

OK, I'm in "whipping up a class" mode.

1) Is it possible to create an array of nilable ints or (nilable other variable types)? (Not a nilable array). Being able to elegantly track whether I've yet manually assigned a value to any given one of the array elements would be handy.

2) Same question regarding a list of nilable ints, etc.

Thanks.

1)

int?[]

2)

List<of int?>

Yes, thanks. Of course I'd already tried those, but they didn't compile because I'm still struggling through a fuzzy-thinking state about cobra/.net/"type definitions vs variables declarations". So I was getting myself (and the compiler!) confused with some self-created wacky Cobra syntax, one of which led to yet another Cobra internal error. Now I can't remember how to replicate it, but if I run across it I'll post it for you.

Yeah, I always want to see those internal errors.

But also, if you have things you tried that didn't work, that might be interesting to post because we might be able to improve the error messages to guide you in the correct direction.

Here's my first beginner attempt at wrapping a normal zero-based list inside of a non-zero based list class. You more experienced programmers would be amazed at how long this took me to write, but I'm slowly learning to be able to write Cobra/.net code that will at least compile. (Think in time units of entire geological eras.) Note to nerdzero: writing in MD is a fantastic upgrade from a command line and Notepad++, even if breakpoints are ignored still.

I didn't see any point in using inheritance, since the normal list members would have to be scrutinized for NZB (non zero-based) compliance before being exposed, and the normal "[ ]" index brackets had to be rejected in favor of method calls, anyway, since they presumably can't accept negative index numbers. (Yes, I need negative non-zero-based index numbers.) And they can't be intercepted by a property in order to offset them back to their zero-based equivalent for processing inside the class.

Any comments? I haven't fully checked or debugged the logic yet, but the entire thing is obviously very simple and it does compile last I checked.

Also, is there a way to make the class more generic? It's a pain to rewrite the class for every data type that the list might hold.

Thanks for any unvarnished comments. I'm trying to learn, so go for it.

Note to Charles: nil-tracking is incredibly handy, and replaces all types of kludgy devices that I used to create. I use it all the time. Same with the meaningful error messages.

Code: Select all

class NZBList           # NZB or nzb = non-zero based
   
      cue init( nzbBottomIndex as int, nzbTopIndex as int )
         base.init
         assert nzbBottomIndex <= nzbTopIndex
         _offset = nzbBottomIndex
         .populateList( nzbBottomIndex, nzbTopIndex )

      var _nzbList = List<of int?>()
      
      var _offset as int
         
      def populateList( nzbBottomIndex as int, nzbTopIndex as int )
         
         myCount = nzbTopIndex - nzbBottomIndex + 1
         while myCount > _nzbList.count
            _nzbList.add(nil)
         assert myCount == _nzbList.count
         
      def count as int
         return _nzbList.count
         
      def setValue(nzbIndex as int, value_ as int?)
         _nzbList[ nzbIndex + _offset ] = value_
      
      def getValue(nzbIndex as int) as int?
         return _nzbList[ nzbIndex + _offset ]


A couple quick notes before I head to lunch.

A generic class would be:

The indexers you define can in fact take negative values.

You will probably want your class to implement IList<of T>, but if not, at least IEnumerable<of T>.

Much of this is covered in the class I posted here from which you should be able to lift ideas: "Custom List Class" including the syntax for generics.

An alternative to generics is to use the type "dynamic" though you will lose compile-time error checking and run-time performance. But it's an option.

Awesome, man. Glad the MD addin is able to help you with your project.