INVALID_OPERATION with COLOR_INDEX texture

I have a weird problem with a texture, the weirdness is that it works only with some versions of OpenGL library (namely 1.3 and "some" 1.4), but not with the others (I tried 1.2 or 1.5)... I have a buffer of bytes and I want to have a color indexed texture, as you can see in the code below, I just try to use glTexImage2D and pass the GL_COLOR_INDEX flag to it (in the code there is the ********HERE********* tag), but glGetError shows that there has been some problem and return GL_INVALID_OPERATION... For what I can read in the documentation, GL_INVALID_OPERATION is given when I call glTexImage2D between a glBegin and a glEnd: this cannot be the case, also because in the other cases (i.e. RGB images), this code works! What happends? glBindTexture(GL_TEXTURE_2D, 1); if (rimg->getWidth() != lastImageWidth || rimg->getHeight() != lastImageHeight) { // the image has changed (or it has been resized) int e = 0; while ((1 << e) < rimg->getWidth()) e++; texWidth = (unsigned int) (1 << e); e = 0; while ((1 << e) < rimg->getHeight()) e++; texHeight = (unsigned int) (1 << e); if (texHeight > texWidth) texWidth = texHeight; else texHeight = texWidth; unsigned char* bytes = new unsigned char[texWidth * texHeight * rimg->getPixelSize()]; memset(bytes, 128, texWidth * texHeight * rimg->getPixelSize()); glGetError(); if (rimg->getType() == RImage::C8) glPixelTransferi(GL_MAP_COLOR, GL_TRUE); else glPixelTransferi(GL_MAP_COLOR, GL_FALSE); if (rimg->getType() == RImage::C8) { // *********HERE************ glTexImage2D(GL_TEXTURE_2D, 0, 3, texWidth, texHeight, 0, GL_COLOR_INDEX, GL_UNSIGNED_BYTE, bytes); } else if (rimg->getType() == RImage::GRAY8) { glTexImage2D(GL_TEXTURE_2D, 0, 1, texWidth, texHeight, 0, GL_LUMINANCE, GL_UNSIGNED_BYTE, bytes); } else if (rimg->getType() == RImage::RGB32) { glTexImage2D(GL_TEXTURE_2D, 0, 3, texWidth, texHeight, 0, GL_RGBA, GL_UNSIGNED_BYTE, bytes); } int er = glGetError(); if (er != GL_NO_ERROR) { if (er == GL_INVALID_OPERATION) { RDK_ERROR_PRINTF("It seems that your OpenGL implementation does" " not support COLOR_INDEX textures, the recommended (not always working)" " libGL.so version is 1.3 or 1.4." " The map will be not showed."); RDK_DEBUG_PRINTF("(Current OpenGL version: %s)", glGetString(GL_VERSION)); } else { RDK_ERROR_PRINTF("There is a OpenGL error showing the image (%d). The image won't be" " showed", er); } } delete bytes; lastImageWidth = rimg->getWidth(); lastImageHeight = rimg->getHeight(); } if (rimg->getType() == RImage::C8) { glPixelTransferi(GL_MAP_COLOR, GL_TRUE); glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, rimg->getWidth(), rimg->getHeight(), GL_COLOR_INDEX, GL_UNSIGNED_BYTE, rimg->getBuffer()); } else if (rimg->getType() == RImage::GRAY8) { glPixelTransferi(GL_MAP_COLOR, GL_FALSE); glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, rimg->getWidth(), rimg->getHeight(), GL_LUMINANCE, GL_UNSIGNED_BYTE, rimg->getBuffer()); } else { glPixelTransferi(GL_MAP_COLOR, GL_FALSE); glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, rimg->getWidth(), rimg->getHeight(), GL_RGBA, GL_UNSIGNED_BYTE, rimg->getBuffer()); } Ah... the texture are initialized as follows: glPixelTransferi(GL_MAP_COLOR, GL_TRUE); glPixelMapfv(GL_PIXEL_MAP_I_TO_R, 256, C8ToGlR); glPixelMapfv(GL_PIXEL_MAP_I_TO_G, 256, C8ToGlG); glPixelMapfv(GL_PIXEL_MAP_I_TO_B, 256, C8ToGlB); glDisable(GL_LIGHTING); glEnable(GL_TEXTURE_2D); glBindTexture(GL_TEXTURE_2D, 1); glPixelStorei(GL_UNPACK_ALIGNMENT, 1); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);

"MadMage" <daniele.calisi@gmail.com> wrote in message news:1144168776.041413.10220@g10g2000cwb.googlegroups.com... >I have a weird problem with a texture, the weirdness is that it works > only with some versions of OpenGL library (namely 1.3 and "some" 1.4), > but not with the others (I tried 1.2 or 1.5)... > > I have a buffer of bytes and I want to have a color indexed texture, as > you can see in the code below, I just try to use glTexImage2D and pass > the GL_COLOR_INDEX flag to it (in the code there is the > ********HERE********* tag), but glGetError shows that there has been > some problem and return GL_INVALID_OPERATION... > > For what I can read in the documentation, GL_INVALID_OPERATION is given > when I call glTexImage2D between a glBegin and a glEnd: this cannot be > the case, also because in the other cases (i.e. RGB images), this code > works! > > What happends? > > glBindTexture(GL_TEXTURE_2D, 1); > > if (rimg->getWidth() != lastImageWidth || rimg->getHeight() != > lastImageHeight) { > // the image has changed (or it has been resized) > int e = 0; > while ((1 << e) < rimg->getWidth()) e++; > texWidth = (unsigned int) (1 << e); > > e = 0; > while ((1 << e) < rimg->getHeight()) e++; > texHeight = (unsigned int) (1 << e); > > if (texHeight > texWidth) texWidth = texHeight; > else texHeight = texWidth; > > > unsigned char* bytes = new unsigned char[texWidth * texHeight * > rimg->getPixelSize()]; > memset(bytes, 128, texWidth * texHeight * rimg->getPixelSize()); > > glGetError(); > > if (rimg->getType() == RImage::C8) glPixelTransferi(GL_MAP_COLOR, > GL_TRUE); > else glPixelTransferi(GL_MAP_COLOR, GL_FALSE); > > if (rimg->getType() == RImage::C8) { > // *********HERE************ > glTexImage2D(GL_TEXTURE_2D, 0, 3, texWidth, texHeight, > 0, GL_COLOR_INDEX, GL_UNSIGNED_BYTE, bytes); > } > else if (rimg->getType() == RImage::GRAY8) { > glTexImage2D(GL_TEXTURE_2D, 0, 1, texWidth, texHeight, > 0, GL_LUMINANCE, GL_UNSIGNED_BYTE, bytes); > } > else if (rimg->getType() == RImage::RGB32) { > glTexImage2D(GL_TEXTURE_2D, 0, 3, texWidth, texHeight, > 0, GL_RGBA, GL_UNSIGNED_BYTE, bytes); > } > > int er = glGetError(); > if (er != GL_NO_ERROR) { > if (er == GL_INVALID_OPERATION) { > RDK_ERROR_PRINTF("It seems that your OpenGL implementation does" > " not support COLOR_INDEX textures, the recommended (not always > working)" > " libGL.so version is 1.3 or 1.4." > " The map will be not showed."); > RDK_DEBUG_PRINTF("(Current OpenGL version: %s)", > glGetString(GL_VERSION)); > > } > else { > RDK_ERROR_PRINTF("There is a OpenGL error showing the image (%d). > The image won't be" > " showed", er); > } > } > > delete bytes; > > lastImageWidth = rimg->getWidth(); > lastImageHeight = rimg->getHeight(); > } > > if (rimg->getType() == RImage::C8) { > glPixelTransferi(GL_MAP_COLOR, GL_TRUE); > glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, rimg->getWidth(), > rimg->getHeight(), > GL_COLOR_INDEX, GL_UNSIGNED_BYTE, rimg->getBuffer()); > } > else if (rimg->getType() == RImage::GRAY8) { > glPixelTransferi(GL_MAP_COLOR, GL_FALSE); > glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, rimg->getWidth(), > rimg->getHeight(), > GL_LUMINANCE, GL_UNSIGNED_BYTE, rimg->getBuffer()); > } > else { > glPixelTransferi(GL_MAP_COLOR, GL_FALSE); > glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, rimg->getWidth(), > rimg->getHeight(), > GL_RGBA, GL_UNSIGNED_BYTE, rimg->getBuffer()); > } > > > Ah... the texture are initialized as follows: > > glPixelTransferi(GL_MAP_COLOR, GL_TRUE); > glPixelMapfv(GL_PIXEL_MAP_I_TO_R, 256, C8ToGlR); > glPixelMapfv(GL_PIXEL_MAP_I_TO_G, 256, C8ToGlG); > glPixelMapfv(GL_PIXEL_MAP_I_TO_B, 256, C8ToGlB); > > glDisable(GL_LIGHTING); > > glEnable(GL_TEXTURE_2D); > glBindTexture(GL_TEXTURE_2D, 1); > glPixelStorei(GL_UNPACK_ALIGNMENT, 1); > glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); > glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); > glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST); > glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST); > Sorry, another pair of eyes and I don't see it either. My guesses include: Not sure what you mean by "versions of the OpenGL library" -- where are these coming from? I mean, how do you get an old version of OpenGL for a given hardware? Or does it also include different hardware along with the versions (clue #1). #2 -- related -- are width/height for sure power of 2, and for sure fit on the target hardware , always ? #3 -- any chance this code can find itself inside a display list ? (that won't work & will generate the error).

> "MadMage" <daniele.calisi@gmail.com> wrote in message > > unsigned char* bytes = new unsigned char[texWidth * texHeight * > rimg->getPixelSize()]; > memset(bytes, 128, texWidth * texHeight * rimg->getPixelSize()); > > > delete bytes; > I don't know what the problem is, but you do have a great big bug in your code which goes into undefined behavior territory. Yep, it's C++ arrays again. My advice is to never, ever use C++ arrays. Just don't do it. Ever. Try this: std::vector<unsigned char>bytes; bytes.resize(texWidth * texHeight * rimg->getPixelSize()); memset(&bytes[0], 128, bytes.size()); (or even) std::vector<unsigned char>bytes; bytes.resize(texWidth*texHeight*rimg->getPixelSize(),128); nb. no need to do a "delete" - bytes will be freed automatically when it goes out of scope... For more info, see the C++ FAQ: http://www.parashift.com/c++-faq-lite/containers.html#faq-34.1 -- <\___/> / O O \ \_____/ FTB. For email, remove my socks. In science it often happens that scientists say, 'You know that's a really good argument; my position is mistaken,' and then they actually change their minds and you never hear that old view from them again. They really do it. It doesn't happen as often as it should, because scientists are human and change is sometimes painful. But it happens every day. I cannot recall the last time something like that happened in politics or religion. - Carl Sagan, 1987 CSICOP keynote address

1) I'm using Linux Fedora Core 3, that comes with a libGL.so.1.2, it should be a Mesa implementation... I used a Mandrake distribution that had a libGL.so.1.4.something and so I searched in Internet for a 1.4 software version... found it, substituted it, and it works... the problem is not with mesa, because in other distributions with non-mesa openGl it works 2) obviously yes, as you can see from the code... for the hardware: hhmm I will try... of course with software versions this problem cannot arise 3) I do not use any display list thanks... I will try to use a smaller texture... and let you know

"fungus" <umailMY@SOCKSartlum.com> wrote in message news:SxGYf.192617$US.159904@news.ono.com... >> "MadMage" <daniele.calisi@gmail.com> wrote in message >> unsigned char* bytes = new unsigned char[texWidth * texHeight * >> rimg->getPixelSize()]; >> memset(bytes, 128, texWidth * texHeight * rimg->getPixelSize()); >> >> >> delete bytes; >> > > I don't know what the problem is, but you do have > a great big bug in your code which goes into > undefined behavior territory. > > Yep, it's C++ arrays again. My advice is to never, > ever use C++ arrays. Just don't do it. Ever. > > Try this: > > std::vector<unsigned char>bytes; > bytes.resize(texWidth * texHeight * rimg->getPixelSize()); > memset(&bytes[0], 128, bytes.size()); > > (or even) > > std::vector<unsigned char>bytes; > bytes.resize(texWidth*texHeight*rimg->getPixelSize(),128); > > nb. no need to do a "delete" - bytes will be freed > automatically when it goes out of scope... > > > For more info, see the C++ FAQ: > http://www.parashift.com/c++-faq-lite/containers.html#faq-34.1 > > > -- > <\___/> > / O O \ > \_____/ FTB. For email, remove my socks. > > In science it often happens that scientists say, 'You know > that's a really good argument; my position is mistaken,' > and then they actually change their minds and you never > hear that old view from them again. They really do it. > It doesn't happen as often as it should, because scientists > are human and change is sometimes painful. But it happens > every day. I cannot recall the last time something like > that happened in politics or religion. > > - Carl Sagan, 1987 CSICOP keynote address > ? I don't see what fungus is talking about. There's nothing wrong with "unsigned char * bytes". I don't klnow why the OP is setting the set of bytes to 128 and then filling the 1st texture with it. If it's just to "set up" the texture, use NULL instead of bytes to allocate the space. -jbw

"MadMage" <daniele.calisi@gmail.com> wrote in message news:1144234468.771382.164510@t31g2000cwb.googlegroups.com... > 1) I'm using Linux Fedora Core 3, that comes with a libGL.so.1.2, it > should be a Mesa implementation... I used a Mandrake distribution that > had a libGL.so.1.4.something and so I searched in Internet for a 1.4 > software version... found it, substituted it, and it works... the > problem is not with mesa, because in other distributions with non-mesa > openGl it works > > 2) obviously yes, as you can see from the code... for the hardware: > hhmm I will try... of course with software versions this problem cannot > arise > > 3) I do not use any display list > > thanks... I will try to use a smaller texture... and let you know > ? If you are saying that some Mesa's don't work, and some do ... I'd say that you answered your own question. You can't use a proprietary driver instead of Mesa ? I've never had any luck with MESA frankly -- I know it's supposed to work, but big apps that run on dozens of other OpenGL's don't work right on MESA for me. I gave up and wrote my own software renderer. -jbw

MadMage wrote: > I do not think that using c arrays is a BUG > It is if you do it wrong. You typed "new[]" to allocate the memory and "delete" to free it (you need to use "delete[]"). -- <\___/> / O O \ \_____/ FTB. For email, remove my socks. In science it often happens that scientists say, 'You know that's a really good argument; my position is mistaken,' and then they actually change their minds and you never hear that old view from them again. They really do it. It doesn't happen as often as it should, because scientists are human and change is sometimes painful. But it happens every day. I cannot recall the last time something like that happened in politics or religion. - Carl Sagan, 1987 CSICOP keynote address

"fungus" <umailMY@SOCKSartlum.com> wrote in message news:7oYYf.55$un5.11@news.ono.com... > MadMage wrote: >> I do not think that using c arrays is a BUG >> > > It is if you do it wrong. > > You typed "new[]" to allocate the memory and > "delete" to free it (you need to use "delete[]"). > > > > > -- > <\___/> > / O O \ > \_____/ FTB. For email, remove my socks. > > In science it often happens that scientists say, 'You know > that's a really good argument; my position is mistaken,' > and then they actually change their minds and you never > hear that old view from them again. They really do it. > It doesn't happen as often as it should, because scientists > are human and change is sometimes painful. But it happens > every day. I cannot recall the last time something like > that happened in politics or religion. > > - Carl Sagan, 1987 CSICOP keynote address > arggh! Quite so. (And completely unnecessary in the OP's case anyway). I'm reminded again why I hate C++. jbw

jbwest wrote: > "fungus" <umailMY@SOCKSartlum.com> wrote in message >> >> You typed "new[]" to allocate the memory and >> "delete" to free it (you need to use "delete[]"). >> > arggh! Quite so. (And completely unnecessary in the OP's case anyway). I'm > reminded again why I hate C++. > The trick is to figure out which are the good features and which are the evil ones. new[]/delete[] is definitely in the "evil" category. It might have been useful before STL came along but now it's just a menace. -- <\___/> / O O \ \_____/ FTB. For email, remove my socks. In science it often happens that scientists say, 'You know that's a really good argument; my position is mistaken,' and then they actually change their minds and you never hear that old view from them again. They really do it. It doesn't happen as often as it should, because scientists are human and change is sometimes painful. But it happens every day. I cannot recall the last time something like that happened in politics or religion. - Carl Sagan, 1987 CSICOP keynote address

"fungus" <umailMY@SOCKSartlum.com> wrote in message news:HAlZf.141$un5.73@news.ono.com... > The trick is to figure out which are the good > features and which are the evil ones. > > new[]/delete[] is definitely in the "evil" > category. It might have been useful before STL > came along but now it's just a menace. Why not switch to Java and be done with it? STL itself uses new and delete. So I guess that makes STL evil. Some of us have no problems with C++. Or new or delete. We are careful programmers. The only thing "evil" is a programmer who is careless and not paying attention to the details and doesn't bother with tools like Purify or DevPartner studio (BoundsChecker) just to be sure... BTW, last time I checked, a mismatched new[] and delete for a native type like "char", "float", and so on, is not a problem. It's not like the compiler can delete the first "char" in an array and not the others. The mismatch is only a problem when the type is a class, where the first object in the array is destroyed but not the others. This is a semantic issue, not a syntax issue. [I certainly match my new/delete calls and wrote an enhanced memory manage to trap mismatches, but I do not recommend being sloppy and mismatching for native type.] -- Dave Eberly http://www.geometrictools.com

Dave Eberly wrote: > > STL itself uses new and delete. So I guess that makes > STL evil. > Here's the definition of "evil": http://www.parashift.com/c++-faq-lite/big-picture.html#faq-6.15 (Also, please make a distinction between "new" and "new[]" - they're not the same thing at all). > BTW, last time I checked, a mismatched new[] and > delete for a native type like "char", "float", and so on, > is not a problem. Again, the FAQ has the answer: http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.13 > [I certainly match my new/delete calls and wrote an > enhanced memory manage to trap mismatches, but I > do not recommend being sloppy and mismatching > for native type.] > Even if you're a perfect programmer who never makes mistakes STL is *still* better because: a) It's easier to get right (less code). b) It's exception safe (stack unwinding prevents memory leaks). Exceptions can really simplify your code in things like file readers. c) Your code will be simpler because you won't have to write so many destructors. d) Your code will be simpler because you won't have to store the sizes of dynamic arrays and pass "size" as a parameter to all the functions which use the arrays. e) You'll suddenly get access to all the tried and tested STL algorithms for sorting/searching/ manipulating arrays (less code for you to write). ....and a bunch of other stuff. -- <\___/> / O O \ \_____/ FTB. For email, remove my socks. In science it often happens that scientists say, 'You know that's a really good argument; my position is mistaken,' and then they actually change their minds and you never hear that old view from them again. They really do it. It doesn't happen as often as it should, because scientists are human and change is sometimes painful. But it happens every day. I cannot recall the last time something like that happened in politics or religion. - Carl Sagan, 1987 CSICOP keynote address

Dave Eberly wrote: > The only thing > "evil" is a programmer who is careless and not paying > attention to the details and doesn't bother with tools > like Purify or DevPartner studio (BoundsChecker) just > to be sure... > <talk about ad-hominem...> Don't you see that it's the C style of memory management which makes those things necessary? When you use C memory management then a whole lot of safety is lost and all the burden for correctness is placed on the programmer (who is usually imperfect). When you use STL for memory management then you start leaking less (the compiler writes the "delete" for you automatically so you *can't* forget) and going out of bounds less (you have less pointers in your program and iterators don't go out of bounds). You go on and on about good engineering but you seem to be ignoring the single best engineering practice in C++ - use std::vector instead of arrays. Worse, you actively attack people who advocate std::vector or say that "arrays are evil". This isn't even the first time you've done it. If this was just some weird/obscure thing I was advocating then I could understand it but it isn't, it's in the C++ FAQ and no sensible C++ programmer should be using new[]/delete[] unless he's using an ancient compiler with no STL (or has some other very good reason for using them). Your attitude is incomprehensible to me. -- <\___/> / O O \ \_____/ FTB. For email, remove my socks. In science it often happens that scientists say, 'You know that's a really good argument; my position is mistaken,' and then they actually change their minds and you never hear that old view from them again. They really do it. It doesn't happen as often as it should, because scientists are human and change is sometimes painful. But it happens every day. I cannot recall the last time something like that happened in politics or religion. - Carl Sagan, 1987 CSICOP keynote address

"Dave Eberly" <dNOSPAMeberly@usemydomain.com> wrote in message news:pLlZf.1498$Es3.775@newsread3.news.atl.earthlink.net... > > "fungus" <umailMY@SOCKSartlum.com> wrote in message > news:HAlZf.141$un5.73@news.ono.com... >> The trick is to figure out which are the good >> features and which are the evil ones. >> >> new[]/delete[] is definitely in the "evil" >> category. It might have been useful before STL >> came along but now it's just a menace. > > Why not switch to Java and be done with it? STL > itself uses new and delete. So I guess that makes > STL evil. > [snip] > Dave Eberly > http://www.geometrictools.com > > re: Why not switch to Java and be done with it? Great idea! I in fact do, exclusively, and I think many graphics folks should think about it, especially with JOGL and XITH3D, and the ensuing religious war over C++ "features" is exactly why I avoid C++. I've seen too much "evil", really evil, C++, to ever want to see any more again. jbw

"fungus" <umailMY@SOCKSartlum.com> wrote in message news:n3vZf.170$un5.20@news.ono.com... > Dave Eberly wrote: >> The only thing >> "evil" is a programmer who is careless and not paying >> attention to the details and doesn't bother with tools >> like Purify or DevPartner studio (BoundsChecker) just >> to be sure... >> > > <talk about ad-hominem...> Nothing in my post indicates I was making a personal attack on you. I have managed engineers in software development environments for many years. Many of them do not pay attention to the details. My statement is a summary of what I have seen. But I can see why you would read this incorrectly. When a strong "belief" is attacked, the person holding that "belief" automatically assumes that *he* is being attacked. > When you use STL for memory management then you > start leaking less (the compiler writes the "delete" > for you automatically so you *can't* forget) and > going out of bounds less (you have less pointers > in your program and iterators don't go out of bounds). You appear to be missing the case when the STL containers are for pointers themselves, where you have to allocate what the pointers point to. You are also missing the case when you have to dynamically allocate STL containers themselves. You can take a religious stance and believe as much as you want that STL solves the problems of the world, but the bottom line is that no programming language is going to guarantee that you will write bug-free code. In the end, you--the programmer--are responsible for verifying the correctness of your code. I am not against STL. I use STL heavily in my Foundation library. When having to micromanage the resources in my Graphics library, STL is not usually the solution. Like any tool, I use it when it is appropriate. I do not use it when it is not. > You go on and on about good engineering but you > seem to be ignoring the single best engineering > practice in C++ - use std::vector instead of > arrays. Worse, you actively attack people who > advocate std::vector or say that "arrays are evil". > This isn't even the first time you've done it. This is not the first time you've stated your stance. I advocate that people should be careful in their programming and think about what they are doing. You advocate blind faith in a paradigm. > If this was just some weird/obscure thing I was > advocating then I could understand it but it isn't, > it's in the C++ FAQ and no sensible C++ programmer > should be using new[]/delete[] unless he's using > an ancient compiler with no STL (or has some other > very good reason for using them). The links you provide for a "FAQ" are one person's view of the world. I found them to be a bit too cavalier. And once again, you are advocating blind faith--that no one should be using new[] or delete[]. Well, programmers develop STL, so I suppose you are criticizing them, too. STL is code like any other, having the potential to be buggy, although you would hope these are fixed just as with any other library. In case you are unaware of the potential problems, Microsoft Visual C++ 6 shipped with STL from Dinkumware. The _xtree template class contained a *static* member to represent the "nil" object. This was a serious bug when you used STL in a DLL and in the application code; you would wind up with two "nil" objects, one in the DLL and one in the EXE, and the application code would access the incorrect one. For legal reasons (associated with Dinkumware), Microsoft could not ship a patch--you had to download it from Dinkumware's site. Another issue with STL that proponents tend not to debate is the insistence that certain algorithms be required to have a specified asymptotic order. This ignores the practical issue of the constant in the asymptotic analysis, a quantity that when large enough can cause the algorithms of better asymptotic order to take longer than those with a "worse" asymptotic order when running on "medium sized" data sets. So you have to do a lot of experimenting to make sure you choose an algorithm for your application's needs. A prime example was posted in c.g.a. some time ago. Someone wanted to create the set of unique colors in a 1024-by-768 image. For large images, you would think that a hash_map or some structure with an O(1) lookup would be the right choice. In this case, you have n pixels to examine, thus leading to an O(n) algorithm. It turns out that sorting was better, leading to an O(n log n) algorithm. It was faster on these images because of its cache coherency (the hash maps jump around memory too much). That coherency led to smaller constant in the asymptotic behavior. The conclusion to be drawn is that it is not enough just to say "I am using STL, so I have no worries". You still have to think about what you are doing, experiment and test and debug and use tools to help you out. > Your attitude is incomprehensible to me. Your religious stance on the topic is incomprehensible to me. -- Dave Eberly http://www.geometrictools.com

Dave Eberly wrote: > > But I can see why you would read this incorrectly. When > a strong "belief" is attacked, the person holding that > "belief" automatically assumes that *he* is being attacked. > There's only one person in this group who has discussed Purify and BoundsChecker in living memory. > You appear to be missing the case when the STL > containers are for pointers themselves, where you > have to allocate what the pointers point to. You > are also missing the case when you have to > dynamically allocate STL containers themselves. > The answer is to never, ever use a raw pointer to manage a resource. All pointers which control a resource should be magic pointers (auto_ptr, referencecouted, etc). > You can take a religious stance and believe as much > as you want that STL solves the problems of the world, > but the bottom line is that no programming language > is going to guarantee that you will write bug-free code. Of course not, but I do seriously believe in telling people to use std::vector instead of new[]/delete[]. This would solve a lot of problems. > You advocate blind faith in a paradigm. > I know that this paradigm would solve (eg.) all the "buffer overflow" vulnerabilities in the world. > The links you provide for a "FAQ" are one person's view of > the world. I found them to be a bit too cavalier. > Excuse me? The official C++ FAQ isn't one person's opinion, it's the consensus opinion of some of the most knowledgeable C++ people in the world, the people who created C++. > Another issue with STL that proponents tend not to debate is > the insistence that certain algorithms be required to have a > specified asymptotic order. This ignores the practical issue > of the constant in the asymptotic analysis, a quantity that > when large enough can cause the algorithms of better > asymptotic order to take longer than those with a "worse" > asymptotic order when running on "medium sized" data sets. > So you have to do a lot of experimenting to make sure you > choose an algorithm for your application's needs. > Yes, and one of the keys to this "experimenting" is flexible code. STL goes a long way towards providing that felxibility. eg. Recently I noticed that std::vector was slowing down my program because vector::resize() insists on filling the array with a value when this isn't really necessary (I'm about to fill it with data). No problem. I wrote a replacement container, changed a typedef, and that was it. STL isn't the ultimate tool but it's tried and tested and allows you to get the code running. > Your religious stance on the topic is incomprehensible to me. > I'm not religious about STL, I'm religious about handing as much responsibility for resource management as possible over to the compiler. Use of new[] and delete[] requires the programmer to be both well experienced and alert. They complicate your code - you need extra destructors, they make exceptions mostly useless) and all sorts of other things. But I don't believe and experienced/alert C++ programmer would be using new[]/delete[]. I'll go further, since the advent of templates/STL I can't think of a single reason why new[]/delete[] shouldn't be removed from the C++ language. If you know of one, please enlighten me. (apart from backwards compatibility of course...) -- <\___/> / O O \ \_____/ FTB. For email, remove my socks. In science it often happens that scientists say, 'You know that's a really good argument; my position is mistaken,' and then they actually change their minds and you never hear that old view from them again. They really do it. It doesn't happen as often as it should, because scientists are human and change is sometimes painful. But it happens every day. I cannot recall the last time something like that happened in politics or religion. - Carl Sagan, 1987 CSICOP keynote address

Even if you use STL there are times when you might want to take the memory allocation in your own hands. In these situation the design of STL allows for writing of your own customized allocators. These would surely require new/delete(or their variants). So to think that the presence of STL makes new/delete redundant is not correct. I agree with the viewpoint that STL is useful in terms that its design allows for very optimized data structure/algorithm implementation but to assume that STL is optimized for every case at hand is just too naive. -valins

psvalins@yahoo.com wrote: > Even if you use STL there are times when you might > want to take the memory allocation in your own hands. In these > situation the design of STL allows for writing of your own customized > allocators. These would surely require new/delete(or their variants). > So to think that the presence of STL makes new/delete redundant is > not correct. > For raw memory allocation I use malloc() and free(). PS: Please distnguish between "new" and "new[]", they're not the same thing at all. > I agree with the viewpoint that STL is useful in terms that its design > allows > for very optimized data structure/algorithm implementation but to > assume that > STL is optimized for every case at hand is just too naive. > The disagreement is with resource management, not optimization. I believe that *all* resources (eg. memory) should be managed via objects and container classes, not raw pointers. To me this seems like a no-brainer. Summing up: "Anybody still doing C style memory management needs a poke with the clue stick." -- <\___/> / O O \ \_____/ FTB. For email, remove my socks. In science it often happens that scientists say, 'You know that's a really good argument; my position is mistaken,' and then they actually change their minds and you never hear that old view from them again. They really do it. It doesn't happen as often as it should, because scientists are human and change is sometimes painful. But it happens every day. I cannot recall the last time something like that happened in politics or religion. - Carl Sagan, 1987 CSICOP keynote address