CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 18 of 19 FirstFirst ... 81516171819 LastLast
Results 256 to 270 of 280
  1. #256
    Join Date
    Sep 2002
    Posts
    1,747
    I didn't see your response, souldog, as I was busily typing mine, but I hope some of the issues have been answered. The main point which applies to your questions is that the system's way of mapping virtual addresses to physical addresses does not add any complexity issues directly involved with the distinction between vectors and lists. The only thing that is affected is the order of complexity of dereference, which does not vary according to any of the dimensions of the algorithms. It is a system environment dependent order of complexity, which can be abstracted out into the basic notion of a "dereference operation" when such is not under direct control. A vector iterator move still has far fewer dereference ops than a list iterator move, insertion still requires only two memory locations being changed (dereference-assigned) on a list, whereas a vector still requires all elements subsequent to the insert to be changed and possibly those prior when a new buffer must be allocated, etc. In other words, all of the generic algorithmics and complexity guarantees are not altered. Which is what explains the real, cold, hard timing calculations that demonstrate this.

    However, I doubt that you needed to hear any of this from me, so I'll let the other side explain the point they are trying to make.
    */*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/

    "It's hard to believe in something you don't understand." -- the sidhi X-files episode

    galathaea: prankster, fablist, magician, liar

  2. #257
    Join Date
    Jul 2002
    Posts
    107
    Hi galathaea,

    I'd like to say first, that I really don't feel that this is going anywhere. I generally don't like to read a 2 page post to weed out a few points. In my opinion, the major problem in this thread is that there are lots of statements and yet not a lot of backup. Everything that I have stated can simply be proved or disproved by opening your compiler and writing a few lines of code to see whether what I have said holds true. That is why I have asked repeatedly for anybody who doesn't believe anything I've said to just try it. Stating that I am wrong with nothing to back it up but 2 pages of opinion, I feel, just wastes time.

    But nonetheless,
    Actually, I really don't want to bring Darwen into this issue, because from the general quality of his posts, I have no doubts that he will eventually have to confront the standard containers head-on through some reason or another, and I think that after the first few test programs, he will finally have those epiphanies on why their structure is the way they are and not think twice about them
    This is what I was talking about in my last post. You are assuming that Darwin just doesn't understand STL. "He will eventually have to confront the standard containers". He has, and he has said no. "after the first few test programs" is the exact kind of statement that causes this to go on and on.
    He said, "I actually know both the STL and MFC very, very well having used both for a large number of years and prefer MFC.
    " at his 5th post and he has constructively dissected STL through out this thread and made many valid points. Are you calling him a liar? He gets the same "you are wrong" response repeatedly through out the thread. And example would be Paul's response of "Looks like your trolling. ".
    Or perhaps comments like this, "If you're going to talk about something, at least know the topic well enough to comment.".
    Or this, "No I don't see what you mean, you don't understand the CRT at all, so your lack of understand leads you to this"
    This is just a handful of comments the first dozen posts to Darwen.
    Darwen on the other hand, asks lots of questions in his posts, and the usual answer is, "you just don't understand", or comments as you have responded above.
    This is not the makings of an intelligent debate.
    In my opinion, when a response is one of a simple, "you are too stupid to understand", then the person who said it probably doesn't understand himself. No matter how complex he writes his reasoning.
    This is why the STL crowd hasn't proven or settled their argument. The only person who has actually done anything to support any thesis was Yves by writing some code and actually testing it. Granted his library was giving him some grief, but he actually attempted to prove his thesis with code. That is debate. When you say to someone, "try this and you will see for yourself", you are persuading someone, when you state, "you are wrong because you don't understand", then you prove nothing and show a lack of understanding yourself.
    So Darwin is key in this debate. To say he "just doesn't understand" is to show that the lack of understanding is on your part, not his, in my opinion.

    Actually, "ugly" is not a particular at all, and "difficult" equates to me to "i have yet to learn this"
    Various bits of STL have been posted and if you feel that someone's dislike of one letter variables means that they "have yet to learn this", then I think you have yet to learn about good design.
    No programmer worth anything would ever say that one line functions, and uninitialized variables, and one letter names are pretty coding. Any well written program should read as easy for another programmer as English. If another programmer has to walk around your code trying to figure out what is what, then you have written your code poorly and in most production environments you would be warned then fired for such poor produce.

    The same mistake was made with the entire misunderstanding between vectors and lists in this thread that prompted this entire diversion
    Something that I said at page 8 hardly qualifies as the reason for the STL division. I don't think you realize how long this thread is and when I got involved.

    You see, contiguous addressable memory refers to the fact that locations in the container can be referred to with pointer arithmetic without traversal
    Of coarse, that is the definition. But the one problem with your statement is relativity. While it may indeed appear to be "contiguous" to your program, it may not be to the system. Which again is why I have provided several links to help explain that. Which bothers me that you feel that I don't understand what the difference between a linked list and an array is. But the misunderstanding is on your part, because I'm talking about how the system is handling your "contiguous" memory and you are talking about C containers. Which is another misconception in this debate. There are no rules when it comes to containers. Nothing says that a linked list has to allocate memory at each insertion. You can do the work wherever you choose. You can allocate yourself, or let the system do it for you. The same goes for vector. However, you should understand what the system is doing before you choose to use a method. So I would recommend you read the documentation in my last post so you can understand a little better what I am talking about.

    suggest turning off exceptions and building a program that tests every allocation for NULL return errors and see what runs faster.
    I will indeed do this, when you have time, could you please show some code and statistics for what you believe is faster and slower so I and others can see what you have seen that makes you believe this?

    I know that when one feels they are being attacked, it is quite natural to jump back with proof that they really are special, even if it means changing the topic to something they know a bit better, but that is all that it was (topic changing).
    Talking about STL's performance is very much on topic. Talking about how the system functions in relation to difference access methods which relate to STL is right on topic. To suggest to write code and test its performance, is not only on topic but a good debate method. So I don't see why you feel a topic change was occurring.

    In other words, no matter what occurs during the dereference operation, the vector has the advantage in the move
    unless of coarse the list simply has to dereference a pointer to its element with out any calculation...or if the list managed its memory in succession in which case it could perform the same move as the vector...in which case it would be just as fast...I guess it all has to do with how the class was written. Which would go back to the design issue, can another programmer make more efficient class then the STL programmers, or are the STL programmer’s programming unsurpassable?

    What I think that discussion has shown, however, is that intelligent people can mistake the concepts embodied by the standard containers, attempt to hand-roll one type and mistakenly produce a different one with different complexity guarantees, without the abstractions built in, and that this example pretty much underlines the point I and others have been making all along.
    I feel the argument has shown that there are too many "die hard" STL users who believe that STL is a "holy-grail" and when confronted with this, its stated that all who oppose it, just doesn't understand it. Many of us old-timers have been writing container classes long before STL and those who have written them understand how they work, how they perform and how they are adaptable, they understand this because they themselves had to do the work, something I feel that those advocating STL haven't done. STL was designed to be a quick and dirty container solution for programmers who needed it, just like Visual Basic was designed to make quick and dirty windows programs. So because of this, I feel the points are moot.

  3. #258
    Join Date
    Nov 2002
    Location
    Foggy California
    Posts
    1,245
    Originally posted by oktronic
    STL was designed to be a quick and dirty container solution for programmers who needed it, just like Visual Basic was designed to make quick and dirty windows programs.
    I'd like to know where the designers of the STL and/or the C++ standards comittee say this! Anyone got a reference?

    And to think, all this time, I've just been a lazy programmer....

  4. #259
    Join Date
    Nov 2003
    Location
    Pasadena, CA
    Posts
    48
    I think you are all missing the one key advantage STL has over any home grown solution yet it has been conclusively demonstrated here in this thread. FAMILARITY.

    Both protractors and detractors here in the STL debate and have fiercly argued that they 'understand' STL. Both from a philosophical and design perspective as well as a semantic one. No home grown library can claim this. Not even MFC which is only applicable to the windows platform. This means that if you use STL within an application you can reasonabily expect that future developers will understand and be able to maintiain your code. Whether they like STL or not is of no consequence. The odds are that even if they disdain it they will understand it. You don't need to document its API or its semantics as you would for your own library. You don't need to teach it to your developers (assuming a professional staff). Full comprehension simply becomes a presumption.

    If you create you own containers you invalidate the assumption. You must now create all of these artifacts. And even then, you'll almost never reach great enough developer penatration for the library to out-live your (or your company's) mantainence of it. If you do reach this critical level of penatration, then inevidabily your library will be adopted as a standard and be incorporated into STL.

    All of that being said. STL represents the best algorithms and containers possible for the general case. The general case is not all cases. Like Kuth's seminal work on allocation strategies, there is often no apparent globally optimal approach. If you know somthing about your problem domain that is not invarent for the general case then you can possibly build a more efficent algorithm or container - but at the expense of significantly greater overhead in maintainence. But recognize that your library is applicable to a smaller problem domain than the STL general case and so therefor direct comparison may be invalid.

    Creating your own library for structural or style issues with STL is understandable but structure and style are like religions. Debate is mear retioric because the issues defy quantification. But monentum is everything. Developers will be familar with and acustomed to the STL structure and style not because it is the 'best' but because it is the most common. Fighting a language standard is like trying to swim an ocean. To quote Moby "I don't want to swim the ocean. I don't want to fight the tide. I don't want to swim forever..."
    The views expressed are those of the author and do not reflect any position taken by the Goverment of the United States of America, National Aeronautics and Space Administration (NASA), Jet Propulsion Laboratory (JPL), or California Institute of Technology (CalTech)

  5. #260
    Join Date
    Nov 2002
    Location
    Los Angeles, California
    Posts
    3,863
    McClark,
    I don't think that point was missed by everyone. It is what I meant
    by the one word response "standardization" and Galathaea and Paul have essentially said as much.
    However, your statement of that sentiment is certainly the clearest.
    Rest assured it will be ignored. (not by me)

    When I stated that oktronic was talking BS, what I was referring
    to was the statement that any company would absolutely not
    want STL used on any programs it contracted. BS. Probably the
    only person who benefits in a situation where oktronic uses his
    library in a contract is oktronic. Why would a company want to
    forever tie the product to the original programmer?

    oktronic
    Various bits of STL have been posted and if you feel that someone's dislike of one letter variables means that they "have yet to learn this", then I think you have yet to learn about good design.
    No programmer worth anything would ever say that one line functions, and uninitialized variables, and one letter names are pretty coding. Any well written program should read as easy for another programmer as English. If another programmer has to walk around your code trying to figure out what is what, then you have written your code poorly and in most production environments you would be warned then fired for such poor produce.
    You must be aware that this is NOT STL. this is an implementation
    of STL. Yes it looks to be badly written in terms of readability.
    What does that have to do with STL? It is not a surprise that
    microsoft would chose such an arcane implementation.


    Hey mick, I think I am winning
    Wakeup in the morning and kick the day in the teeth!! Or something like that.

    "i don't want to write leak free code or most efficient code, like others traditional (so called expert) coders do."

  6. #261
    Join Date
    Jul 2002
    Posts
    107
    Excellent points mclark.
    STL hasn't been around long. A drop in the bucket compared to the theories and applications of the containers it employs.
    Which begs the questions, why would a programmer who has been programming containers decades before STL was conceived, want to use it? Generic programming isn't new and the algorithms STL use aren't new either. Which wouldn't that really leave STL to be used by those who don't have their own generic classes, like new programmers to the field?

    For Kevin, here is an interview with Stepanov, the creator of STL.
    http://www.stlport.org/resources/StepanovUSA.html
    Just took a quick search to find out the information. Hope it helps you. I think you will find it useful to do a few more searches to get a complete picture. Note his views on object orientation. His ideas for generic programming aren't particularly new and much of what he proposed has been proposed by many others. Stroustrup's role in its development is interesting as well.
    Last edited by oktronic; December 1st, 2003 at 02:25 AM.

  7. #262
    Join Date
    Jul 2002
    Posts
    107
    You must be aware that this is NOT STL. this is an implementation
    of STL. Yes it looks to be badly written in terms of readability.
    What does that have to do with STL? It is not a surprise that
    microsoft would chose such an arcane implementation.


    Hey mick, I think I am winning
    when you design a program do you not think of its implementation?
    A what does microsoft have to do with STL? They were the first to offer it before it became a standard and the code provided was from HP, its not their fault that its unreadable. Not that I'm a microsoft fan or do I enjoy defending them, but this is a case where they tried to do the right thing and provide the latest technology to help stay on top.
    And what do you feel you are winning?

  8. #263
    Join Date
    Nov 2002
    Location
    Foggy California
    Posts
    1,245
    Originally posted by oktronic
    For Kevin, here is an interview with Stepanov, the creator of STL.
    http://www.stlport.org/resources/StepanovUSA.html
    Just took a quick search to find out the information. Hope it helps you. I think you will find it useful to do a few more searches to get a complete picture. Note his views on object orientation. His ideas for generic programming aren't particularly new and much of what he proposed has been proposed by many others. Stroustrup's role in its development is interesting as well.
    I think this article only bolsters the point that the STL is not just "containers for dummies".... Here's what Stepanov had to say in that interview:

    ANSWER:
    STL, at least for me, represents the only way programming is possible.
    Now I have read the interview (quickly albeit, but I did read it).... Where is there a statement similar to yours in that interview?

    Originally posted by oktronic
    STL was designed to be a quick and dirty container solution for programmers who needed it,
    Please quote (not just a reference some paper I have to search through) and (not or) where that quote that can be found where someone who helped design the STL and/or was on the standardization comittee actually says something similar to the STL being a "quick and dirty container solution"!

  9. #264
    Join Date
    Nov 2002
    Location
    Los Angeles, California
    Posts
    3,863
    the point being that it is not valid to point at the implementation
    of STL used by microsoft and make any statements about STL
    in general. If I were to take your library of containers and systematically replace all variables with single letter names,
    use stupid macros throughout it and release it to people, would
    this reflect anything on your original design?

    You keep complaining about the the code in the dinkumware implementation, but this has nothing to do with STL.

    My comments about Microsoft are probably unfair, but from
    what I have read and seen they seem to be the antithesis
    of standardization, that is if the standard was produced
    elsewhere.


    The winning statement is a private joke, ignore it.
    Wakeup in the morning and kick the day in the teeth!! Or something like that.

    "i don't want to write leak free code or most efficient code, like others traditional (so called expert) coders do."

  10. #265
    Join Date
    Nov 2002
    Location
    Foggy California
    Posts
    1,245
    Originally posted by oktronic
    when you design a program do you not think of its implementation?
    You are missing the point. Does the following code mean that C++ is a bad language?

    Code:
    #include <iostream>
    
    std::ostream llllll(std::cout.rdbuf());
    
    template <typename lllll1, typename llll1l>
    void llll11(lllll1 & lll1ll, llll1l const& lll1l1)
    {
      lll1ll << lll1l1;
    }
    
    char lll11l [] = "\n!dfloUHraWeKoqS(lP$ )bzJ%l";
    
    template <int lll111>
    void ll1lll()
    {
      llll11(llllll, lll11l[lll111]);
      ll1lll<!(lll111 % 2) ? (lll111 / 2) : ((3 * lll111 + 1) / 2)>();
    }
    
    template <>
    void ll1lll<1>()
    {
      llll11(llllll, lll11l[1]);
      llll11(llllll, lll11l[0]);
    }
    
    int main()
    {
      ll1lll<7>();
    }
    That code is Galathaea's (hope you don't mind) from this post... (http://www.codeguru.com/forum/showth...603#post754603)

    Someone can write:

    Code:
    typedef std::list<int> li;
    or

    Code:
    typedef std::list<int> int_list;
    One provides more information than the other. Just because one person is not clear does not mean the interface is bad. The same sort of thing could be done with any class you wrote. (If not, I'd really like to see how you make a compiler enforce some naming standards -- no, I'm not being sarcastic here -- really!!! If you have some way of enforcing clear naming standards, please share it. It would be really nice to use!)

  11. #266
    Join Date
    Jul 2002
    Posts
    107
    He also said this:
    I find OOP technically unsound
    It wasn't my intent to form an opinion for you, you didn't seem to know the history to STL so I pointed you in a direction.

    And considering your statement was:
    I'd like to know where the designers of the STL and/or the C++ standards comittee say this! Anyone got a reference?
    I think that answered it. Did you really think Stepanov would refer to 15 years of work as "quick and dirty"? lol
    I know you are looking for anything to help you argue your opinion, but perhaps you should spend a little time looking into the mind of the creator of STL and into those who came long before him. Even Stroustrup wasn't eager to support STL and made Stepanov modify it before he would offer it up as a standard, maybe you should look at why?. A little research can go along way.

  12. #267
    Join Date
    Nov 2003
    Location
    Pasadena, CA
    Posts
    48
    Originally posted by oktronic
    when you design a program do you not think of its implementation?
    A what does microsoft have to do with STL? They were the first to offer it before it became a standard and the code provided was from HP, its not their fault that its unreadable. Not that I'm a microsoft fan or do I enjoy defending them, but this is a case where they tried to do the right thing and provide the latest technology to help stay on top.
    And what do you feel you are winning?
    I studied under Musser and did a lot of banging around with the HP implementation. It was a mess. That couldn't be helped. You really do need a lot of the language support added to the C++ spec to make an STL-like library usable. To classic examples are constructor semantics to built-in types [ie T(x) -> int(x)] and the 'explicit' keyword to implicit conversion logic from going haywire. But this is all ancient history (or it should be). If Microsoft really hasn't moved far beyond the old HP code - well then that should tell you something about them.

    But the point is well taken. I've never come across a 'readable' STL implementation with STLPort being the closest. But this is nothing new, since what goes on behind the scenes of <vector> is all implementation-specific. The same 'readability' ***** is valid for malloc or any C library item. Its just normally you can't see what's going on there because you're only provided with a prototyping header and the standard lib functions in an obj. With STL, the vendors can't get away with that. The actual template code has to be there in source form. So really when you look at an STL implementation you're just glimpsing the 'uglyness' that permeates the whole standard library (C and C++ alike).

    This really shouldn't be an issue since just like the C library - you shouldn't need to know what's going on in there - just the API. And if your code does depend on what's going on in there - then it is not ANSI comforming and will be very brittle. And there are plenty of 1 character parameter names in the C library. I have source licenses to several major OSes and a few compiler-vendor standard C libraries. And if you can believe it - I've actually climbed through a lot of this code. The uglyness of most STL implementations is par for the course for this type code. From the vendor perspective - your not supposed to read it, your not supposed to want to read it, and by God were not gonna help you read it. Just buy it and use it and pay us to support it if you actually have a problem.
    The views expressed are those of the author and do not reflect any position taken by the Goverment of the United States of America, National Aeronautics and Space Administration (NASA), Jet Propulsion Laboratory (JPL), or California Institute of Technology (CalTech)

  13. #268
    Join Date
    Jul 2002
    Posts
    107
    you guys are posting a little to fast for me,

    Kevin there is a difference between bad design and bad "language" as you put it.
    If you are writing a program for just yourself, then you don't have to really care what it looks like, but when you are writing a program for a client then design is everything. It doesn't matter if its an entire program or just a SDK, your library wont be used it its difficult to understand or read. This is exactly what happened to STL. It surfaced in the early 90's to most of us "in the loop" programmers and mid 90's for the general public. It took several years for anybody to even pick a book up on it. Most programmers can read code better then english. So the usual first response when something new drops in their lap is to read the code, in STL this is the most common case since the code is practically all there. Second is to buy a book, most don't get this far, if they can't easily figure out what the code is doing, they can't trust it in their code so they drop it. If colleges didn't start to teach it as an example to templates, STL probably never would have been picked up.

    mclark, the asm for the c library is readable. The actual code has plenty of comments too.
    And yes, there were a lot of 1 letter variable names in the old days. It was due to having to deal with old style word processors and compilers, dealing with a long variable name took time, especially since you didn't have all the SDKs there are now and you had to write stuff yourself. A lot of the old coders stuck with it when they learnt new languages even with newer WPs coming out, but it is getting phased out.

    edit:
    If you have some way of enforcing clear naming standards, please share it
    There are plenty of books on standard conventions, most use Microsoft’s, but there are others. Hungarian, etc.
    The easiest way to enforce it at work is to fire anybody who gets doesn't use the companies proposed standard, that’s a motivator, lol. Many companies and contracts have a required notation they want used.
    Last edited by oktronic; December 1st, 2003 at 03:22 AM.

  14. #269
    Join Date
    Nov 2002
    Location
    Los Angeles, California
    Posts
    3,863
    Originally posted by mclark
    The only vector member function that I think might have a hard guarantee on reducing capacity (reserve obviously makes one on increasing it) is swap. But swap cannot be performed by iterator - and hence not with a normal array (where you control the size).
    Just as an aside. swap also does not have a hard guarantee
    on reducing size. According to Meyers the implementation is still
    allowed to ignore the request to trim all the excess capacity.
    Wakeup in the morning and kick the day in the teeth!! Or something like that.

    "i don't want to write leak free code or most efficient code, like others traditional (so called expert) coders do."

  15. #270
    Join Date
    Aug 2002
    Location
    Madrid
    Posts
    4,588
    oktronic
    Various bits of STL have been posted and if you feel that someone's dislike of one letter variables means that they "have yet to learn this", then I think you have yet to learn about good design.
    No programmer worth anything would ever say that one line functions, and uninitialized variables, and one letter names are pretty coding. Any well written program should read as easy for another programmer as English. If another programmer has to walk around your code trying to figure out what is what, then you have written your code poorly and in most production environments you would be warned then fired for such poor produce.
    I think STLPort is pretty readable. It does use variable names which are a bit ugly to the trained eye, but well, that's their choice. I have seen far worse in publicly available code. Plus, this doesn't prevent me from understanding the code.

    The problem is that each programmer has her own approach to things. This is alleviated by having a standard notation style, but there is not one standard, nor is there a general consensus what is good and what is bad.

    The essence of this point is, however, that it doesn't really provide an argument against using STL. If you want to look at MFC's code, you have to disassemble the MFC dll and step through assembler instructions. In my view, this is much worse than reading one-letter variable names. The source code for STL is there, if you want to use it fine, if you don't, just get a book or use the online documentation at www.sgi.com/tech/stlport.

    oktronic
    Which is another misconception in this debate. There are no rules when it comes to containers. Nothing says that a linked list has to allocate memory at each insertion. You can do the work wherever you choose. You can allocate yourself, or let the system do it for you. The same goes for vector.
    There are certain fundamental rules when it comes to ADTs (Abstract Data Types) and these are the naming conventions as used by people like Knuth. Of course, your own container can be a hybrid or an optimized version of one or two standard ADTs etc. If you call your container a linked list, then there are basic assumptions we can make:
    - insertion of an element anywhere is O(1)
    - deletion of an element anywhere is O(1).
    Usually this goes hand-in-hand with the assumption:
    - access to the Nth element is O(N).
    Since you can't post the source code for your own implementation, you can at least say whether these hold or not.

    A std::vector is a very different kind of beast:
    - insertion at the end is amortised constant time.
    - insertion anywhere else is O(N)
    - deletion at the end is amortised constant time.
    - deletion anywhere else is O(N)
    - access to the Nth element is O(1).

    Whether or not memory is physically, structurally, logically or OS-level contiguous doesn't matter in the discussion about algorithms. What matters is how we, as programmers, access the memory. If we do it in a single instruction (meaning assembler instruction), like a[10], then that is categorised as fast ( O (1) ). If we do
    for (int i = 0; i < 10; ++i) a = a->next;
    then this is slow access O(N). The reason the only valid measure is the complexity is because this is source code and can be:
    - compiled on different compilers, each producing a different optimisation
    - compiled on different computer types, like x86, motorola, etc.
    - run on different types of CPUs
    - run on different types of OSes

    Each of these have very real influences on how fast the code runs in absolute terms. However, these distinctions are irrelevant when you come to distinguish between the complexities of algorithms and operations on containers (provided basic assumptions about the machine hold).

    oktronic
    If you are writing a program for just yourself, then you don't have to really care what it looks like, but when you are writing a program for a client then design is everything. It doesn't matter if its an entire program or just a SDK, your library wont be used it its difficult to understand or read. This is exactly what happened to STL. It surfaced in the early 90's to most of us "in the loop" programmers and mid 90's for the general public. It took several years for anybody to even pick a book up on it.
    Of course. It also took many years from the initial support of templates to their widespread use, as it is still taking time until exceptions and namespaces are used by mainstream programmers. STL is not just a bunch of functions to call since it comes with its own paradigm, unfamiliar to most people, when STL was released. If you don't understand the ideas behind code, trying to figure them out by reading the source is *extremely* hard in many cases. This is of course made worse by the fact that the producers of the code had to make do with very limited compiler support and probably didn't intend people to really read the source anyways.
    Get this small utility to do basic syntax highlighting in vBulletin forums (like Codeguru) easily.
    Supports C++ and VB out of the box, but can be configured for other languages.

Page 18 of 19 FirstFirst ... 81516171819 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured