On 2013-06-22 01:58, H. S. Teoh wrote:

> And where's the unittest block? ;-)  (OK OK, I know this wasn't written
> in D. But I had to ask. :-P)

DMC does support contracts, as an extension. That is, in and out contracts. I don't know about unit test blocks.

-- 
/Jacob Carlborg

On 2013-06-22 00:12, Nick Sabalausky wrote:

> - The nasty little details like pointer/memory problems, linker errors,
>    etc that real people have to deal with are neatly glossed over and
>    sidestepped.

They never teach you about that.

> - There was one CS101 teacher (I had to tutor her unfortunate students)
>    who constantly bragged about being from a real-world software
>    company...but she was a Java-addict (circa v1.2-v1.4) who kept trying
>    to teach OO *before* basic flow-of-execution. Consequently, none of
>    her unfortunate students had the slightest clue what was going on.
>
> - Many of the professors are terrible programmers themselves. For
>    example, I had one who openly admitted the only language he knew was
>    C, and yet at one point it became painfully obvious that he had
>    almost no comprehension of null-terminated strings.

What annoys me is that sometimes they teach flat out lies to the students.

I watch a couple of videos from a course from Standford, I think it was algorithms and data structures or similar. The teacher introduce the Map data structure by showing an interface for it and how it works. She tells the student that you cannot have any other type for the keys than strings. I think she even says it's impossible. I can understand that they don't want to make it too complicated when it's introduced for the first time. But she at least could have said something like, "for now, lets imagine only string types are possible".

-- 
/Jacob Carlborg

On 6/22/13, Walter Bright <newshound2@digitalmars.com> wrote:
> Can I play, too? Mine from the Digital Mars C library. Haven't looked at it
>
> #if 0 /* Smaller but slower under many circumstances. */
> char *strstr(const char *s1,const char *s2)
> {   size_t len2;
>      size_t len1;
>      char c2 = *s2;
>
>      len1 = strlen(s1);
>      len2 = strlen(s2);
>      if (!len2)
> 	return (char *) s1;
>      while (len2 <= len1)
>      {
> 	if (c2 == *s1)
> 	    if (memcmp(s2,s1,len2) == 0)
> 		return (char *) s1;
> 	s1++;
> 	len1--;
>      }
>      return NULL;
> }

Some things i've noticed about this implementation:

- c2 is assigned by pointer dereference, but then strlen is called on s2 and you may get an early exit, meaning c2 was not needed at this point. I'd move c2 below the strlen call.

- The memcp doesn't have to compare len2 amount of chars if you've already compared the first character, it can call memcmp(s2+1, s1+1, len2-1). Although I'm not sure whether it's faster to do it this way (maybe it is, if those variables are actually registers..).

And notes about both implementations:

- You're casting a const char * to a char * in the return, you should instead provide an overload of strstr taking char* and returning char*.

- You seem to have missed the most basic and most important check. You didn't attempt to compare the memory address of both pointers against each other before doing any other work. If they both point to the same memory, the strings are guaranteed to be equal.

On Saturday, 22 June 2013 at 11:01:53 UTC, Andrej Mitrovic wrote:
> - You're casting a const char * to a char * in the return, you should instead provide an overload of strstr taking char* and
> returning char*.

I'm pretty sure the C standard says to do it with the const arg but mutable return.

http://en.cppreference.com/w/c/string/byte/strstr

On 2013-06-21 21:11, Walter Bright wrote:

> I've been around long enough to have seen an endless parade of magic new
> techniques du jour, most of which purport to remove the necessity of
> thought about your programming problem.

One needs to be opened minded and be able to try new things.

> But there is one technique that stands head and shoulders above the
> others in improving code quality, sometimes dramatically so. That's unit
> testing coupled with a coverage analyzer.

I can imagine that these techniques have been new at some point in time as well. It's possible that a new technique comes a long that help you as much as these techniques do.

-- 
/Jacob Carlborg

On 2013-06-22 00:12, Nick Sabalausky wrote:

> - There was one CS101 teacher (I had to tutor her unfortunate students)
>    who constantly bragged about being from a real-world software
>    company...but she was a Java-addict (circa v1.2-v1.4) who kept trying
>    to teach OO *before* basic flow-of-execution. Consequently, none of
>    her unfortunate students had the slightest clue what was going on.

We learned OO before any programming. First we had a course about analyze and design of object oriented systems, or something like that. They thought the basic concepts of OO, UML diagrams and other stuff. After that course we learned programming and the practical side of OO, that is Java.

> - Many of the teachers don't even teach, they just collect the
>    thousands of dollars in tuition and give you a book recommendation
>    (really more of a "demand" than a recommendation). Now, I'm a strong
>    believer in being self-taught and learning from books, but all I need
>    for that is a library card, not a $100k debt and four years of elitist
>    attitudes from people who clearly don't know what they're doing
>    anyway.

During my years at the university I bought three books. One of the was really good, the rest wasn't worth it.

-- 
/Jacob Carlborg

On 6/22/13, Adam D. Ruppe <destructionator@gmail.com> wrote:
> On Saturday, 22 June 2013 at 11:01:53 UTC, Andrej Mitrovic wrote:
>> - You're casting a const char * to a char * in the return, you should instead provide an overload of strstr taking char* and returning char*.
>
> I'm pretty sure the C standard says to do it with the const arg but mutable return.
>
> http://en.cppreference.com/w/c/string/byte/strstr
>

Ah, I momentarily forgot C doesn't have overloading, which is probably where Walter's function was implemented in. In C++ there are overloads of this function:

http://www.cplusplus.com/reference/cstring/strstr/

Adam D. Ruppe wrote:
> On Friday, 21 June 2013 at 22:35:55 UTC, Andrei Alexandrescu wrote:
>> Post it and I'll destroy it.
> 
> 
> inout(char)* mystrstr(inout(char)* haystack, const(char*) needle)
> {
>      assert(haystack !is null);
> 
>      if(needle is null)
>          return haystack;
> 
>      const(char)* where = needle;
>      inout(char)* gotit;
> 
>      while(*haystack) {
>          if(*haystack == *where) {
>              if(gotit is null)
>                  gotit = haystack; // store where the match started
>              where++;
>              haystack++;
>              if(*where == 0)
>                  return gotit;
>          } else {
>              // if we were in the middle of a match, we'll want to
>              // check the current character again so only advance
> if
>              // we're at the beginning
>              if(gotit is null)
>                  haystack++;
>              else {
>                  // partial match, but not complete so no good
>                  // start over, including the current *haystack
>                  where = needle;
>                  gotit = null;
>              }
>          }
>      }
> 
>      return null;
> }
> 
	I haven't tried running it, but this looks to me like it won't find
"ababc" in "abababc"...

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

On Saturday, 22 June 2013 at 13:55:26 UTC, Jérôme M. Berger wrote:
> 	I haven't tried running it, but this looks to me like it won't find "ababc" in "abababc"...


You're right. I should have went backwards all the way, not just in the one case.

This passes all the tests:

inout(char)* mystrstr(inout(char)* haystack, const(char*) needle) {
        assert(haystack !is null);

        if(needle is null)
                return haystack;

        const(char)* where = needle;
        inout(char)* gotit;

        while(*haystack) {
                if(*haystack == *where) {
                        if(gotit is null)
                                gotit = haystack;
                        where++;
                        if(*where == 0)
                                return gotit;
                } else {
                        haystack -= where - needle;
                        where = needle;
                        gotit = null;
                }

                haystack++;
        }

        return null;
}

On Friday, 21 June 2013 at 16:49:26 UTC, H. S. Teoh wrote:
> On Fri, Jun 21, 2013 at 05:48:25PM +0200, Jacob Carlborg wrote:
>> On 2013-06-21 16:56, H. S. Teoh wrote:
>> 
>> >+1, me too! I can say that 85-90% of what I do at work today, I
>> >learned from my personal coding projects, not from the CS courses I
>> >took in university. (That's why I like to joke about CS grads knowing
>> >more about uncomputable problems than computable ones...)
>> 
>> It feels like there's something wrong with the world here :)
> [...]
>
> Only "something" wrong? ;-)
>
> To be fair, though, I can understand why university programs are that
> way: their goal is to produce more researchers and professors who may
> join the faculty and produce more research. So they focus more on the
> theoretical aspects of computer science in order to produce such
> candidates, whereas focusing on more practical aspects is something for
> technical colleges whose goal is to produce industry workers.
>
> Unfortunately, in North America at least, the technical colleges lean
> more toward stuff like "how to use MS Word", "how to organize your
> company data in MS SQL", rather than _real_ programming, and
> universities that actually *teach* real programming are more interested
> in finding solutions to uncomputable problems than teaching students how
> to solve computable ones, so there's a gap in the area of producing
> qualified industry coders who can write functional software. There *are*
> pockets of competent programming education here and there, of course,
> but this is the impression I get from the general situation.
>
>
> T

Yay, a uni bashing thread. I'm a student and I like it, so here's some subjective opinion.

I don't know how it's in USA, but where i live we have 2 possibilities of getting CS education at uni level: a course at "pure" university and a course at something we call "university of technology". Basically the former focuses much more on academic problems, the latter grants you with "engineer" title with all that implies - you learn how computers work from electrical level up to the high abstractions of disciplines like AI or image processing.

I've been interested in programming long before I went to the "university of technology". I went there to expand my knowledge on the topic. It worked out great for me, because unlike in our "highschool" I didn't have to learn stuff unrelated to my interests. I've learned a lot and met some very skillful people. Many of them bash unis just like you guys, yet they still gained many skills there - but that's typical - I've heard a lot of whining during my entire education.

I want to point out that having a CS course alone doesn't make you a good coder. First - because CS is not only about coding, that's a wide discipline. Second - your attitude is what really matters. Noone's going to make you a (very)good C programmer in 90h course - you just get enough to grasp important concepts to be able to easily expand on your own in areas you like. If you don't like CS, yet you finish the course, you've lost X years of life for getting a sheet of paper and some opportunity to get a job which you probably won't like or won't be good at. Third - unis are really not about producing enterprise workers, you don't need much knowledge to write apps which throw around data between crud app and db. Instead they give you ability to use common scientific methodology, a complete overview of CS, means to study (or even push forward) the discipline you're interested in and most important, they teach how stupid everyone (especially you - that's a painfull lesson) really is.

I'm not saying that you can't get all of this on your own, yet it's easier that way. I was a self taught programmer, but I feel that my knowledge is more complete now (and some of the knowledge is very important for a systems programmer). It's obviously the same other way around - you can pass all the exams and get nothing from that. It's up to you what you're going to do with free time. Important note: public unis are free in my country, I probably wouldn't study otherwise.