Bug 1472

Summary: Small syntax problems, resulting in build failure using clang compiler
Product: ns-3 Reporter: Alex Afanasyev <alexander.afanasyev>
Component: lteAssignee: Nicola Baldo <nicola>
Status: RESOLVED FIXED    
Severity: normal CC: ns-bugs, vedran
Priority: P5    
Version: ns-3-dev   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 1345    
Attachments: patch

Description Alex Afanasyev 2012-07-11 16:31:21 UTC
Created attachment 1424 [details]
patch

1. Log-related
clang compiler does not allow cout << std::vector<..>(), so the usage was replaced by the address of the vector
    
2. clang does not allow non-POD (non plain-old-data) types to be
allocated on stack. Replaced with heap allocation and deallocation.


Also. The current version of LTE needs bindings rescan. I can supply a patch, but there is no point in it.
Comment 1 Nicola Baldo 2012-07-17 23:12:00 UTC
Hi Alex, 

thanks for the patch, please find my comments below.


(In reply to comment #0)
> Created attachment 1424 [details]
> patch
> 
> 1. Log-related
> clang compiler does not allow cout << std::vector<..>(), so the usage was
> replaced by the address of the vector

I'd just remove activeRbs from the NS_LOG_FUNCTION then, just logging its address does not say much.


> 
> 2. clang does not allow non-POD (non plain-old-data) types to be
> allocated on stack. Replaced with heap allocation and deallocation.
> 

I never used clang, but after a quick google search it seems to me that the issue is not with the fact that the arrays are on the stack, but rather with the fact that the arrays have variable length. 

See also a similar bug description https://www.nsnam.org/bugzilla/﷒0﷓

Would it suffice if you just change numOfPbs and numOfPkts to a const variable (or to a #define) to make the arrays have a constant length?


> 
> Also. The current version of LTE needs bindings rescan. I can supply a patch,
> but there is no point in it.

Tom rescanned the bindings with changeset a11fdda061ae, so this should be fixed now.
Comment 2 Vedran Miletić 2012-09-14 19:07:30 UTC
Fixed in changeset 9077 16e6f501eeef (in a bit different way). If there are pros to this approach compared to one I used I would be glad to hear them.
Comment 3 Nicola Baldo 2012-10-03 06:35:50 UTC
I looked at changeset 16e6f501eeef and I am fine with the changes. Thanks!