-1

This is my structure :

struct HashTable{
      int tsize;
      int count;    //No. of elements in table
      struct HashTableNode **Table;
};

And this is what I am trying to do : 

struct HashTable *h=(struct HashTable *)malloc(sizeof(struct HashTable));
if(!h) return NULL;
h->tsize=size/LOAD_FACTOR;
h->count=0;
h->Table=(struct HashTableNode**)malloc(sizeof(HashTableNode *)*h->tsize);//this line

I am unable to convert the last line into its equivalent C++ version using new operator

Solved it

i changed the code to this :

h->Table=new HashTableNode*[h->tsize];
for(int i=0;i<h->tsize;i++)
    h->Table[i]=new HashTableNode;

and did a little debugging on my own and voila. It is solved.

Thanks, everyone.

Varun Thakur
  • 9
  • 2
  • 3
    First of all in C++ you should avoid pointers. You can live very happily and make very nice programs without pointers. Secondly, if you want to create an array at runtime then you should be using `std::vector` instead. – Some programmer dude Oct 05 '16 at 14:32
  • @LPs He's converting C to C++, this is a rare case where both tags are valid. – Borgleader Oct 05 '16 at 14:32
  • @Borgleader Meanwhile deleted ;) – LPs Oct 05 '16 at 14:32
  • If you still insists on using pointers, please show us what you have tried, and tell us how it worked or not worked. – Some programmer dude Oct 05 '16 at 14:32
  • i tried this `h->Table=new HashTableNode*[h->tsize];` but it doesnot work and program crashes. – Varun Thakur Oct 05 '16 at 14:41
  • That is the correct way to allocate an array of pointers using `new[]`. The problem is something else you do. You need to run in a debugger to find out more about the crash, like when and where it happens, what the values of involved variables are, etc. Please read [How to debug small programs](https://ericlippert.com/2014/03/05/how-to-debug-small-programs/) – Some programmer dude Oct 05 '16 at 14:50
  • Where does it crash? Can you produce a [MCVE]? – Yakk - Adam Nevraumont Oct 05 '16 at 14:51
  • Writing your own hash table using pointers is a very interesting learning exercise. Just ignore the comments regarding pointers being evil. – vz0 Oct 05 '16 at 14:55
  • This is an awful idea. If you are in Rome behave like a Roman! If you write C++ code, use C++ features. I.e. use a class and the standard library. – too honest for this site Oct 05 '16 at 15:15
  • 2
    @Olaf thats a horrible Philosophy. C++ does not force you to use any or all of its' features. It's a plague in the C++ community where "Oh you're using C++, just use C++ features". C++ is largely capable of doing anything C can using C code, and it is still going to be C++(It's not going to be "idiomatic" C++, but It is C++). It's okay to use pointers, it's okay to use memcpy, it's okay to realloc and malloc and free. You better know what you are doing and be able to answer to others, but it's okay to use these tools. – Dmytro Oct 05 '16 at 15:33
  • C++ is plagued with the problem of familiarity = simplicity, and a large amount of this community is terrified of sharp tools, even if they are warranted. Hence we must try our best to promote better alternatives that do the same thing with zero overhead with predictable behavior that can be checked to be universal across platforms. However telling people to "never do this" is downright evil. At an extreme we just become Idiomatic Java programmers using C++, which begs the question why do we even have pointers in the language? – Dmytro Oct 05 '16 at 15:35
  • That said, please indent your code. – Dmytro Oct 05 '16 at 15:40
  • @Dmitry: Your comment amuses me as a dedicated **C** programmer! But the approach is well correct. If you want to write C-style, **use C**! Your approach rfeminds me of "If you only know how to use a hammer, ever problem looks like a nail." – too honest for this site Oct 05 '16 at 15:51
  • @Olaf that's my point; we must teach people what kinds of hammers exist; but we can't tell people to never use a hammer, or else they will just find it easier to hit us with that hammer or hit it with a hammer harder. It's very hard to stop using a hammer, and worse, often a hammer is indeed better than any tool we can provide but we are blinded by our familiarity. You can write C++ in C, it takes disceplined use of structs and proper care of your code, and care to make sure you carefully document it, but it can be done. C with PHP preprocessor could be nicer than C++ id argue but i degress. – Dmytro Oct 05 '16 at 15:53
  • @Olaf the biggest things C++ offers over C is (1) ability to automatically match constructors with destructors(In C you need a preprocessor to do this for you and the current preprocessor cannot be programmed to do this for you). (2) ability to do templating(which can be done via setting flags before including a header, do work, then set "cleanup macro" and include the header again which after it is done "unsets cleanup macro", but nobody ever does this, a better preprocessor would make this process less disgusting, but C++ preprocessor is no better, but they put the stuff into the language. – Dmytro Oct 05 '16 at 15:57
  • There are other tools than hammers ... (this is neither the place nor the time for a duscussion. Feel free to stick with your collection of hammers, I'll stick with my whole toolbox). – too honest for this site Oct 05 '16 at 16:10
  • Regarding how you solved your problem... When you allocate memory, that memory will not be initialized unless there's a constructor doing it. When you allocate an "array" of pointers (like in `h->Table=new HashTableNode*[h->tsize]`) then those pointers will not be initialized. The contents of the array will be *indeterminate* and using them without initialization will lead to *undefined behavior* and likely crashes. What the loop does is to initialize the pointers, and make them point to valid objects. – Some programmer dude Oct 06 '16 at 06:55

1 Answers1

0

Obviously I agree most of the comments under your question, but if you REALLY need pointers in your code the solution for your problem may look like below.

Use typedef specifier to define a type:

typedef HashTableNode* PHashTableNode;

And then:

h->Table=new PHashTableNode[h->tsize];
nosbor
  • 2,826
  • 3
  • 39
  • 63
  • 1
    *Never ever* tell C++ programmers to *Never ever* do something, as they will do it just to spite you. See how you suddenly have an urge to tell me to *Never ever* tell C++ programmers to *Never ever* tell other C++ programmers to tell other C++ programmers to *Never ever* do something? That's how confusion breeds. – Dmytro Oct 05 '16 at 15:46
  • @Olaf : Why is that bad typedefing a pointer type ? Have a link to a documentation giving detail about why this should not be done ? – shrike Oct 05 '16 at 21:34
  • @shrike: Did you search for that topic? This has been explained here dozens of times already. Some reasons: it results in confusion for usage, as it hides the specific semantics of a pointer. And you cannot apply qualifiers to the object it points to (what do you think `const PHashTableNode p` is actually? Hint: it is very different from `const HashTableNode *p`), defying const-correctness. – too honest for this site Oct 06 '16 at 00:01
  • @shrike: ... It also clutters global namespace. What good odes it? Nothing: you have to remember two names, more if you want to be const-correct or have `volatile` or atomic objects. You don't even safe typing. `*MyStruct` vs. `pMyStruct`. Things become even more complicated if you need pointer to pointer. If you ever have to maintain such code (be it your own after 1-2years), you bang your hand against the wall. – too honest for this site Oct 06 '16 at 00:05
  • @Olaf : _"Did you search for that topic?"_ Actually I did (quickly though) and found [this](http://stackoverflow.com/questions/750178/is-it-a-good-idea-to-typedef-pointers) where the accepted answer seams to legitimate such practice, or [this](http://stackoverflow.com/questions/3781932/is-typedefing-a-pointer-type-considered-bad-practice) which links as duplicate to the previous one. (One more example where a duplicate flag tends to strengthen a wrong answer.) Anyway your arguments against this practice make sense. I will think about it twice in the future before doing so. Thanks. – shrike Oct 06 '16 at 08:06
  • @shrike: Not all highly voted answers are good answers. Some ppl think you need to `typedef` a pointer to a `struct` to make that `struct` opaque. But that is not necessary as you can very well have a forward declaration of that `struct` (but no `typedef`) and use it for pointers. Note that there are quite some coding styles which disallow `typedef`ing a pointer (and only few of them have been written by me ;-). – too honest for this site Oct 06 '16 at 12:04
  • @shrike: Also have a look at this answer to your first linked question http://stackoverflow.com/a/750183/4774918 . Although it does not even try to justify the position, it has also a lot of upvotes. My assumption is that it got these upvotes from ppl who understand the reasons already, The first answer only lists a very special case and does not mention the alternative I gave, I think is it reasonable to assume it got UVs from less experienced coders who only noticed the given aspects. Additionally considering an accepted answer typically gets more upvotes this is a clear statement. – too honest for this site Oct 06 '16 at 12:11